Original text:
2.1. For any host candidate gathered by an ICE agent as part of RFC8445 <del> section 5.1.1, obfuscation of the candidate is done as follows: </del>  Check whether the ICE agent has a usable registered mDNS hostname resolving to the ICE host candidate's IP address.  If one exists, skip ahead to Step 6. <del> If there is a registered hostname, replace the IP address of the ICE host candidate with the hostname.  Expose the candidate and abort these steps. </del> Generate a unique mDNS hostname.  The unique name MUST consist of a version 4 UUID as defined in RFC4122, followed by ".local". agent for future reuse. Replace the IP address of the ICE host candidate with its mDNS <del> hostname.  Expose the candidate. </del>  An ICE agent can implement this procedure in any way so long as it produces equivalent results to this procedure. An implementation may for instance pre-register mDNS hostnames by executing steps 3 to 5 and prepopulate an ICE agent accordingly.  By <del> doing so, only steps 1 and 2 of the above procedure will be executed at the time of gathering candidates. </del>  An implementation may also detect that mDNS is not supported by the <del> available network interfaces.  The ICE agent may skip step 3 and 4 </del>  and directly decide to not expose the host candidate. This procedure ensures that a mDNS name is used to replace only one <del> IP address.  Specifically an ICE agent using an interface with both </del>  IPv4 and IPv6 addresses MUST expose a different mDNS name for each address. candidate would provide applications an even more reliable tracking mechanism than the private IP addresses that this specification is designed to hide.  The use of registered mDNS hostnames SHOULD be <del> scoped by origin, and have the lifetime of the page. If the generated mDNS hostname candidate does not follow the pattern described, the exposed candidate might be used for fingerprinting. If there are multiple host candidates with different IP addresses, IPv4 and/or IPv6, each results in a separate mDNS hostname candidate. The number of mDNS hostname candidates can provide a fingerprinting dimension.  If so desired an ICE agent MAY expose additional mDNS hostname candidates that are not registered. </del>  3.3.

Reviewer comments:
Fingerprinting question will be tracked in a new issue.
Merging this one with Jeroen's approval.
LGTM

Revised text:
2.1. For any host candidate gathered by an ICE agent as part of RFC8445  <ins> section 5.1.1, the candidate is processed as follows: </ins> Check whether the ICE agent has a usable registered mDNS hostname resolving to the ICE host candidate's IP address.  If one exists, skip ahead to Step 6.  Generate a unique mDNS hostname.  The unique name MUST consist of a version 4 UUID as defined in RFC4122, followed by ".local". agent for future reuse. Replace the IP address of the ICE host candidate with its mDNS  <ins> hostname, and expose the candidate as usual. </ins> An ICE agent can implement this procedure in any way so long as it produces equivalent results to this procedure. An implementation may for instance pre-register mDNS hostnames by executing steps 3 to 5 and prepopulate an ICE agent accordingly.  By  <ins> doing so, only step 6 of the above procedure will be executed at the time of gathering candidates. </ins> An implementation may also detect that mDNS is not supported by the  <ins> available network interfaces.  The ICE agent may skip steps 2 and 3 </ins> and directly decide to not expose the host candidate. This procedure ensures that a mDNS name is used to replace only one  <ins> IP address.  Specifically, an ICE agent using an interface with both </ins> IPv4 and IPv6 addresses MUST expose a different mDNS name for each address. candidate would provide applications an even more reliable tracking mechanism than the private IP addresses that this specification is designed to hide.  The use of registered mDNS hostnames SHOULD be  <ins> scoped by origin, and SHOULD have the lifetime of the page. </ins> 3.3.