Original text:
4.2.  It is important that use of registered mDNS hostnames is limited in time and/or scope.  Indefinitely reusing the same mDNS hostname candidate would provide applications an even more reliable tracking designed to hide.  The use of registered mDNS hostnames SHOULD be scoped by origin, and SHOULD have the lifetime of the page. <del> 4.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

Reviewer comments:
LGTM too, will resolve conflicts
If we resolve a name N1 to 1.1.1.1, should we pair it with relay candidates? If we do so, 1.1.1.1 will be sent to the TURN server, which seems like a leak (could be under the control of the web app). Probably need to add a section in the privacy considerations saying any remote mdns candidates MUST NOT be paired with local relay candidates (although the reverse should be OK).
I am thinking about the impact on the connectivity, and if we can ever resolve the remote mdns candidate, the chance of selecting relaymdns even if this is allowed could probably be low if the local side also gathers a host candidate. The MUST level lgtm.
yeah, and keep in mind that usually these host IPs will be things like 192.168.1.3 that are not even reachable by the outside world.
Well thought! Agreed, I always thought TURN and STUN were intertwined (TURN server is probably also a STUN server or at least hosted in the same network) so that we can use server reflexive candidates for TURN without losing much.
yeah - we already throw away private IPs for TURN to avoid creating connections that won't work, so the actual impact here is negligible.
LGTM

Revised text:
4.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 if the client uses TURN to send to an IP that was obtained by mDNS resolution, the TURN server will learn the underlying host IP and port, and this information can then be relayed to the web application, defeating the value of the mDNS wrapping. To prevent disclosure of the host IP address to a TURN server, the ICE agent MUST NOT form candidate pairs between its own relay candidates and remote mDNS candidates.  Note that the converse is not an issue; the ICE agent MAY form candidate pairs between its own mDNS candidates and remote relay candidates, as in this situation host IPs will not be sent directly to the TURN server. This restriction has no effect on connectivity; in the cases where host IP addresses are private and need to be wrapped with mDNS names, they will be unreachable from the TURN server, and as noted above, the reverse path will continue to work normally. 4.3. </ins> It is important that use of registered mDNS hostnames is limited in time and/or scope.  Indefinitely reusing the same mDNS hostname candidate would provide applications an even more reliable tracking designed to hide.  The use of registered mDNS hostnames SHOULD be scoped by origin, and SHOULD have the lifetime of the page.  <ins> 4.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