Original text:
4.  In this example, mDNS candidates are exchanged between peers and resolved to obtain the corresponding IP addresses. mDNS resolution for name N2 does not complete until after the STUN checks are received. <del> 5. </del>  The goal of this mechanism is to keep knowledge of private host IP addresses within the ICE agent while continuing to allow the to prevent these IP addresses from being exposed to web applications through other means. <del> 5.1. </del>  Statistics related to ICE candidates that are accessible to the web application MUST NOT contain the IP address of a local or remote mDNS where the signaled candidate is discarded as redundant according to Section 5.1.3 of RFC8445. <del> 5.2. </del>  When sending data to a TURN RFC5766 server, the sending client tells the server the destination IP and port for the data.  This means that they will be unreachable from the TURN server, and as noted above, the reverse path will continue to work normally. <del> 5.3. </del>  It is important that use of registered mDNS hostnames is limited in time and/or scope.  Indefinitely reusing the same mDNS hostname designed to hide.  The use of registered mDNS hostnames SHOULD be scoped by origin, and SHOULD have the lifetime of the page. <del> 5.4. </del>  As noted in IPHandling, privacy may be breached if a web application running in two browsing contexts can determine whether it is running a context that has a different origin than the top-level browsing context), or a private browsing context. <del> 6. </del>  <del> 6.1. </del>  The implementation of this proposal requires the mDNS querying capability of the browser for registering mDNS names or adding remote queries, announcement responses, resolution queries, and goodbye responses associated with mDNS. <del> 6.2. </del>  If the optional probing queries are implemented for the name registration, a malicious endpoint in the local network, which is generic threat, and requires dedicated protocol suites to mitigate, which is beyond the scope of this proposal. <del> 6.3. </del>  A malicious endpoint in the local network may also record other endpoints who are registering, unregistering, and resolving mDNS As above, mitigation of this threat is beyond the scope of this proposal. <del> 7. </del>  This document requires no actions from IANA. <del> 8. </del>  The proposal relies on identifying and resolving any mDNS-based ICE candidates as part of adding/processing a remote candidate.  ICESDP

Reviewer comments:
Added new section on latency, as requested by NAME PTAL - will plan to merge at EOD if there are no outstanding comments.
Include experimental results, if we have them
LGTM

Revised text:
4. <ins> 4.1. With typical ICE, endpoints on the same network will usually be able to establish a direct connection between their local IP addresses. When using the mDNS technique, a direct connection is still possible, but only if at least one side can properly resolve the provided mDNS candidates.  This may not be possible in all scenarios. First, some networks may entirely disable mDNS.  Second, mDNS queries have limited scope.  On large networks, this may mean that an mDNS name cannot be resolved if the remote endpoint is too many segments away. When mDNS fails, ICE will attempt to fall back to either NAT hairpin, if supported, or TURN relay, if not.  As noted in IPHandling, this may result in increased media latency and reduced connectivity/ increased cost (depending on whether the application chooses to use TURN). The exact impact of this technique is being researched experimentally and will be provided before publication of this document. 4.2. As noted in {#principle}, ICE agents using the mDNS technique are responsible for registering and resolving mDNS names as part of the ICE process.  These steps may delay establishment of a direct peer- to-peer connection, compared to when raw local IP addresses are used. Given that these mDNS registrations and queries are typically occurring on a local network, any associated delays should be small. Also, as noted in {#gathering}, pre-registration can be employed to eliminate gathering delays entirely. 4.3. Note that backward compatibility does not present a significant issue for the mDNS technique.  When an endpoint that supports mDNS communicates with an endpoint that does not, the legacy endpoint will still provide its local IP addresses, and accordingly a direct connection can still be attempted, even though the legacy endpoint cannot resolve the mDNS names provided by the new endpoint.  In the event the legacy endpoint attempts to resolve mDNS names using Unicast DNS, this may cause ICE to take somewhat longer to fully complete, but should not have any effect on connectivity or connection setup time. 5. </ins> In this example, mDNS candidates are exchanged between peers and resolved to obtain the corresponding IP addresses. mDNS resolution for name N2 does not complete until after the STUN checks are received.  <ins> 6. </ins> The goal of this mechanism is to keep knowledge of private host IP addresses within the ICE agent while continuing to allow the to prevent these IP addresses from being exposed to web applications through other means.  <ins> 6.1. </ins> Statistics related to ICE candidates that are accessible to the web application MUST NOT contain the IP address of a local or remote mDNS where the signaled candidate is discarded as redundant according to Section 5.1.3 of RFC8445.  <ins> 6.2. </ins> When sending data to a TURN RFC5766 server, the sending client tells the server the destination IP and port for the data.  This means that they will be unreachable from the TURN server, and as noted above, the reverse path will continue to work normally.  <ins> 6.3. </ins> It is important that use of registered mDNS hostnames is limited in time and/or scope.  Indefinitely reusing the same mDNS hostname designed to hide.  The use of registered mDNS hostnames SHOULD be scoped by origin, and SHOULD have the lifetime of the page.  <ins> 6.4. </ins> As noted in IPHandling, privacy may be breached if a web application running in two browsing contexts can determine whether it is running a context that has a different origin than the top-level browsing context), or a private browsing context.  <ins> 7. </ins>  <ins> 7.1. </ins> The implementation of this proposal requires the mDNS querying capability of the browser for registering mDNS names or adding remote queries, announcement responses, resolution queries, and goodbye responses associated with mDNS.  <ins> 7.2. </ins> If the optional probing queries are implemented for the name registration, a malicious endpoint in the local network, which is generic threat, and requires dedicated protocol suites to mitigate, which is beyond the scope of this proposal.  <ins> 7.3. </ins> A malicious endpoint in the local network may also record other endpoints who are registering, unregistering, and resolving mDNS As above, mitigation of this threat is beyond the scope of this proposal.  <ins> 8. </ins> This document requires no actions from IANA.  <ins> 9. </ins> The proposal relies on identifying and resolving any mDNS-based ICE candidates as part of adding/processing a remote candidate.  ICESDP