Change:
S 3. That said, I could get behind switching 'will' to 'can', as is used in S3, category . S 6.2. This seems like a good addition.

Discussion:
the client can be learned.  In particular, if the client tries to hide its physical location through a Virtual Private Network (VPN), and the VPN and local OS support routing over multiple <del> interfaces (a "split-tunnel" VPN), WebRTC will discover not only </del> <ins> interfaces (a "split-tunnel" VPN), WebRTC can discover not only </ins> the public address for the VPN, but also the ISP public address over which the VPN is running.

If an enterprise TURN server is present, the preferred route MUST be through this TURN server.  Once an interface has been chosen, the private IPv4 and IPv6 addresses associated with this interface <del> MUST be discovered and provided to the application.  This ensures that direct connections can still be established in this mode. </del> <ins> MUST be discovered and provided to the application as host candidates.  This ensures that direct connections can still be established in this mode. </ins> Default route only: This is the the same as Mode 2, except that the associated private addresses MUST NOT be provided; the only IP

6.1. <del> When trying to follow typical IP routing, the simplest approach is to bind() the sockets used for peer-to-peer connections to the wildcard addresses (0.0.0.0 for IPv4, :: for IPv6), which allows the OS to route WebRTC traffic the same way as it would HTTP traffic.  STUN and TURN will work as usual, and host candidates can still be determined as mentioned below. </del> <ins> When trying to follow typical IP routing, as required by Modes 2 and 3, the simplest approach is to bind() the sockets used for peer-to- peer connections to the wildcard addresses (0.0.0.0 for IPv4, :: for IPv6), which allows the OS to route WebRTC traffic the same way as it would HTTP traffic.  STUN and TURN will work as usual, and host candidates can still be determined as mentioned below. </ins> 6.2. When binding to a wildcard address, some extra work is needed to <del> determine a suitable host candidate, which we define as the source address that would be used for any packets sent to the web application host (assuming that UDP and TCP get the same routing). Use of the web application host as a destination ensures the right source address is selected, regardless of where the application resides (e.g., on an intranet). </del> <ins> determine the associated local address required by Mode 2, which we define as the source address that would be used for any packets sent to the web application host (assuming that UDP and TCP get the same routing).  Use of the web application host as a destination ensures the right source address is selected, regardless of where the application resides (e.g., on an intranet). </ins> First, the appropriate remote IPv4/IPv6 address is obtained by resolving the host component of the web application URI RFC3986.  If

table, without sending any packets over the network. Finally, the socket can be queried using getsockname() or the <del> equivalent to determine the appropriate host candidate. </del> <ins> equivalent to determine the appropriate local address. </ins> 7.