Original text:
addresses has privacy implications.  This document describes a way to share local IP addresses with other clients while preserving client privacy.  This is achieved by obfuscating IP addresses with <del> dynamically generated Multicast DNS RFC6763 names. </del>  1. Replace the IP address of the ICE host candidate with the name with ".local" appended to it.  Expose the candidate.  2.2. For any remote host ICE candidate received by the ICE agent, the Otherwise, ignore the candidate. <del> Multicast DNS resolution might end up retrieving both an IPv4 and IPv6 address.  In that case, the IPv6 address may be used preferably to the IPv4 address. </del>  3.

Reviewer comments:
Some additional comments may be needed in the prflx section?
NAME I went ahead and added a commit for my proposed changes. Let me know if the proposed changes are fine with you.
NAME Did you only commit the html changes? Can you include the markdown?
Oh, I probably messed up with the commit. I was expecting to commit only the markdown. I'll fix it.
It is conceivable that a server would implement ICE with mDNS candidates. There should be nothing in the ICE candidate processing that prevents this from working. Therefore we should call out what should happen when an mDNS query returns multiple IP addresses. E.g. use the 'best' on (where IPv6 is better than IPv4)?
This is a complex area. A simpler option could be that we mandate 1:1 for mDNS, and/or pick the first address of the expected type.
Mandating 1:1 for mDNS in the context of WebRTC is probably the straightforward approach. We should probably also define the behavior in the case of multiple responses, picking the first record makes sense to me. This requirement causes a potential issue when using MDNS for non default route though: it creates a fingerprinting vector by counting the number of different MDNS names for a given peer connection. I am not sure what reliable means we have to know the expected type of the address and whether this is a requirement at all. The easy solution would be to include this information in the MDNS name.
Good point about type not being known a priori, and we could put a hint in the name. Another option could be to resolve the name before forming pairs, take the first record found, and then only pair the resolved address with local candidates of the appropriate family.
Fixed by
LGTM with one comment

Revised text:
addresses has privacy implications.  This document describes a way to share local IP addresses with other clients while preserving client privacy.  This is achieved by obfuscating IP addresses with  <ins> dynamically generated Multicast DNS RFC6762 names. </ins> 1. Replace the IP address of the ICE host candidate with the name with ".local" appended to it.  Expose the candidate. <ins> This procedure ensures that a mDNS name is used to replace only one IP address.  Specifically an ICE agent using an interface with both IPv4 and IPv6 addresses MUST expose a different mDNS name for each address. </ins> 2.2. For any remote host ICE candidate received by the ICE agent, the Otherwise, ignore the candidate.  <ins> An ICE agent may use a hostname resolver that transparently supports both Multicast and Unicast DNS.  In this case the resolution of a ".local" name may happen through Unicast DNS, see RFC6762 section 3. An ICE agent that supports mDNS candidates MUST support the situation where the hostname resolution results in more than one IP address. In this case, the ICE agent MUST take exactly one of the resolved IP addresses and ignore the others.  The ICE agent SHOULD, if available, use the first IPv6 address resolved, otherwise the first IPv4 address. </ins> 3.