Original text:
A peer-reflexive remote candidate could be learned and constructed from the source transport address of the STUN Binding request as an ICE connectivity check.  The peer-reflexive candidate could share the <del> same address as a remote mDNS ICE candidate whose name is in the process of being resolved.  In addition to the elimination procedure of redundant candidates defined in Section 5.1.3 of RFC8445, which could remove constructed peer-reflexive remote candidates, the address of any existing peer-reflexive remote candidate should not be exposed to Web applications by ICE agents that implement this proposal, as detailed in Section #guidelines. </del>  3. <del> 3.1. </del>  When there is no user consent, the following filtering should be done to prevent private IP address leakage: learned through other means, e.g., receiving it in a separate server-reflexive remote candidate. <del> 3.2. </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> 3.3. </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> 4. </del>  <del> 4.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> 4.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> 4.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> 5. </del>  The proposal relies on identifying and resolving any mDNS-based ICE candidates as part of adding/processing a remote candidate.  ICESDP

Reviewer comments:
PR of
Added a 'good' example as well, and put them all in an examples section. PTAL.
Will merge once I get a second approval.
Some of this stuff is complicated, example diagrams can help.
Great to have examples. Regenerating the html, the examples do not show up in full on the html version, probably not a big deal, the txt version is fine.
LGTM

Revised text:
A peer-reflexive remote candidate could be learned and constructed from the source transport address of the STUN Binding request as an ICE connectivity check.  The peer-reflexive candidate could share the  <ins> same address as a remote mDNS candidate that is in the process of being signaled or name resolution. In addition to the elimination procedure of redundant candidates defined in Section 5.1.3 of RFC8445, which could remove constructed peer-reflexive remote candidates, the address of any existing peer- reflexive remote candidate should not be exposed to Web applications by ICE agents that implement this proposal, as detailed in Section #guidelines. </ins> 3.  <ins> In this example, mDNS candidates are exchanged between peers and resolved to obtain the corresponding IP addresses. The following two examples indicate how peer-reflexive candidates for host IP addresses can be created due to timing differences. In this example, a peer-reflexive candidate is generated because the mDNS candidate is signaled after the STUN checks begin. In this example, a peer-reflexive candidate is generated because the mDNS resolution for name N2 does not complete until after the STUN checks are received. 4. 4.1. </ins> When there is no user consent, the following filtering should be done to prevent private IP address leakage: learned through other means, e.g., receiving it in a separate server-reflexive remote candidate.  <ins> 4.2. </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> 4.3. </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> 5. </ins>  <ins> 5.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> 5.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> 5.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> 6. </ins> The proposal relies on identifying and resolving any mDNS-based ICE candidates as part of adding/processing a remote candidate.  ICESDP