Original text:
want to conceal its IPs, e.g., if it has a priori knowledge that its addresses are in fact public, this processing is unnecessary. <del> For any host candidate gathered by an ICE agent as part of RFC8445, Section 5.1.1, the candidate is handled as follows: </del>  Check whether the ICE agent has a usable registered mDNS hostname resolving to the ICE candidate's IP address.  If one exists, skip

Reviewer comments:
I think this is good to go, will plan to land at EOD.
Does it obfuscate, conceal, or obscure local IP addresses? My vote is for conceal.
Conceal/concealment sgtm.
As noted in , we don't need to use the same term in every case, but the terms should have the same meaning. conceal and hide are fairly synonymous, but conceal and obfuscate have slightly different meanings.
This section is largely normative, so it might make more sense to put some parts from it immediately after Principle, namely the various adjustments to the technique that need to be considered (TURN, IPv6, stats) Things where we merely provide discussion (e.g., session monitoring) rather than normative guidance could remain in the privacy section.
Due to their different sensitivity and lifetime.
If we add this indication, do we also need to clarify the use case for lite ICE agents?
What did you have in mind?
{{#gathering}} starts with "For any host candidate gathered by an ICE agent as part of {{RFC8445}} section 5.1.1," it seems the place we need to revise to resolve this issue. I was thinking of allowing ICE lite implementation to skip the mDNS wrapping, since lite agents only use host candidates (8445, section 2.5). The lite implementation is however not required restricted to ICE agents that always have public IPs from my reading of that section, but rather an alternative to simplify the implementation when possible. So I am still not sure if it makes sense to say lite ICE can be exempted from wrapping; or instead indicating mDNS wrapping can be skipped if host candidates are equivalent to srflx candidates, and automatically the intended use of lite ICE satisfies this condition.
Right, the public IPs exception probably covers this. also indicates that this is really for web browsers, which are not allowed to implement ICE Lite.
Started writing this up today, but realized it's not totally clear how this should work. The idea would be to use STUN to figure out if an IP is public or not, but... Should we wait to hand out the mDNS candidate until we determine if the IP is private (i.e., STUN finishes)? Should we not hand out the mDNS candidate if we get a srflx candidate that shows the IP is not private? If we hand out the mDNS candidate and then get a srflx candidate that matches the local IP, should we make that a host candidate? Once we learn an IP is not public, should we cache that for future ICE gathering sessions (i.e., not give out mDNS candidates?) The easiest thing would probably be to recommend handing out the mDNS and srflx candidates as usual, but allow implementations to skip mDNS for IPs it has learned are public. (Except for RFC1918 addresses, which would always be treated as private.)
Partially addressed in , will probably include some additional clarifying text once it lands
The rest LGTM

Revised text:
want to conceal its IPs, e.g., if it has a priori knowledge that its addresses are in fact public, this processing is unnecessary.  <ins> This section outlines how mDNS should be used by ICE agents to conceal local IP addresses. For each host candidate gathered by an ICE agent as part of the gathering process described in RFC8445, Section 5.1.1, the candidate is handled as described below. Check whether this IP address satisfies the ICE agent's policy regarding whether an address is safe to expose.  If so, expose the candidate and abort this process. </ins> Check whether the ICE agent has a usable registered mDNS hostname resolving to the ICE candidate's IP address.  If one exists, skip