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

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.