Change:
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.

Discussion:
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.

following procedure is used: If the connection-address field value of the ICE candidate does <del> not finish by ".local", process the candidate as defined in RFC8445. </del> <ins> not end with ".local" or if the value contains more than one ".", then process the candidate as defined in RFC8445. </ins> <del> Otherwise, remove the ".local" suffix to the value and resolve it using Multicast DNS. </del> <ins> Otherwise, use the value and resolve it using Multicast DNS. </ins> If it resolves to an IP address, replace the value of the ICE host candidate by the resolved IP address and continue processing of

4.2. <del> Dynamically generated names can be used to track users if used too often.  Conversely, registering too many names will also generate useless processing.  The proposed rule is to create and register a new generated name for a given IP address on a per execution context. </del> <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 mechanism than the private IP addresses that this specification is designed to hide.  The use of registered mDNS hostnames SHOULD be 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. </ins> 4.3.