Change:
3.1. <del> For any host ICE candidate gathered by a browsing context as part of RFC8445 section 5.1.1, obfuscation of the candidate is done as follows: </del> <ins> For any host candidate gathered by an ICE agent as part of RFC8445 section 5.1.1, obfuscation of the candidate is done as follows: </ins> <del> Check whether the context ICE agent registered a name resolving to the ICE host candidate IP address. </del> <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. </ins> <del> If the ICE agent registered the name, replace the IP address of the ICE host candidate with the name with ".local" appended to it. Expose the candidate and abort these steps. </del> <ins> 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. </ins> <del> Generate a random unique name, typically a version 4 UUID as defined in RFC4122. </del> <ins> Generate a unique mDNS hostname.  The unique name MUST consist of a version 4 UUID as defined in RFC4122, followed by ".local". </ins> <del> Register the unique name using Multicast DNS. </del> <ins> Register the candidate's mDNS hostname using Multicast DNS. </ins> <del> If registering of the unique name fails, abort these steps.  The </del> <ins> If registering of the mDNS hostname fails, abort these steps.  The </ins> candidate is not exposed. <del> Store the name and its related IP address in the ICE agent for future reuse. </del> <ins> Store the mDNS hostname and its related IP address in the ICE agent for future reuse. </ins> <del> Replace the IP address of the ICE host candidate with the name with ".local" appended to it.  Expose the candidate. </del> <ins> Replace the IP address of the ICE host candidate with its mDNS hostname.  Expose the candidate. 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 doing so, only steps 1 and 2 of the above procedure will be executed at the time of gathering candidates. An implementation may also detect that mDNS is not supported by the available network interfaces.  The ICE agent may skip step 3 and 4 and directly decide to not expose the host candidate. </ins> 3.2.

Discussion:
NAME I tried to address your comments without splitting the procedure. Splitting the procedure makes a bit awkward to handle the error case and the mDNS registration is then only two steps really. Let me know what you think.
We found Microsoft recommended using “.local.” as a pseudo-TLD for small private networks with internal DNS servers (here is an article that is still accessible, URL(v=ws.10), and the Wiki page URL covers some legacy recommendations made by Microsoft, though some I think have been removed). We also note that Apple provided guidance on how to configure OS X to look up “.local” hostnames using both mDNS and DNS (URL, I am not sure if this is still the case for newer OS X). Hostnames containing only one level (label) in addition to “.local” are resolved using mDNS by default. Names containing two or more labels in addition to local will be resolved using DNS by default. For this reason, our current implementation only generates names containing one additional label (also recommended by RFC 6762 I think). I understand this section is more about the principle, but I am wondering how we/or if we should define failure here. Since we use the random UUID for hostnames, name conflicts are likely avoided with minimum retries.
I agree the exposed unique name should end with '.local' which is what step 7 is doing. It is fine to append '.local' in step 4 if that makes things clearer. As of 5, if registering the unique name fails to name conflicts, the issue is that we might detect that conflict after exposing the candidate. An implementation is probably free to decide to wait so as to ensure that there is no name conflict but there is no such guarantee.
NAME do you think we should have a stronger statement about UUIDs requirements. Would something like the following fix the first part of the issue: Step 3 of section 3.1: Generate a random unique name. The unique name SHOULD be a version 4 UUID as defined in [RFC4122].
As of the second issue about the error case, there might be cases where there will be an error case right away. Maybe no interface with simulcast support for instance.
The "should"-level requirement of "URL" sounds good to me.

Do you think if it would be helpful to also refer to Section 3 in RFC6762? The second last paragraph there has a related discussion, and the above requirement conforms to that.
The blocking issue in the security consideration section may also be an example of failure here. I feel we may need to clarify the handling of failure (with limit of retries, for example).
This LGTM with the changes noted below.