Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: 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 , ( v = ws.10 ) , and the Wiki page 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 ( , 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 . 
 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 " " 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 .
Paragraph (version A):
Check whether the context ICE agent registered a name resolving to
the ICE host candidate IP address.
Paragraph (version A):
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.
Paragraph (version A):
Generate a random unique name, typically a version 4 UUID as
defined in RFC4122.
Paragraph (version A):
Register the unique name using Multicast DNS.
Paragraph (version A):
If registering of the unique name fails, abort these steps.  The
candidate is not exposed.
Paragraph (version A):
Store the name and its related IP address in the ICE agent for
future reuse.
Paragraph (version A):
Replace the IP address of the ICE host candidate with the name
with ".local" appended to it.  Expose the candidate.
Paragraph (version B):
Generate a unique mDNS hostname.  The unique name MUST consist of
a version 4 UUID as defined in RFC4122, followed by ".local".
Paragraph (version B):
Register the candidate's mDNS hostname using Multicast DNS.
Paragraph (version B):
Store the mDNS hostname and its related IP address in the ICE
agent for future reuse.
Paragraph (version A):
Otherwise, remove the ".local" suffix to the value and resolve it
using Multicast DNS.
Paragraph (version B):
If the connection-address field value of the ICE candidate does
not end with ".local" or if the value contains more than one ".",
then process the candidate as defined in RFC8445.
Paragraph (version B):
Otherwise, use the value and resolve it using Multicast DNS.
Paragraph (version A):
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.