Change:
For the most part, backward compatibility does not present a significant issue for the mDNS technique.  When an endpoint that <del> supports mDNS communicates with an endpoint that does not, the legacy endpoint will still provide its local IP addresses, and accordingly a direct connection can still be attempted, even though the legacy endpoint cannot resolve the mDNS names provided by the new endpoint. In the event the legacy endpoint attempts to resolve mDNS names using Unicast DNS, this may cause ICE to take somewhat longer to fully complete, but should not have any effect on connectivity or connection setup time. </del> <ins> supports mDNS communicates with a legacy endpoint that does not, the legacy endpoint will still provide its local IP addresses, allowing the new endpoint to attempt direct connections to those addresses. Through the process of learning peer-reflexive candidates described in RFC8445, the legacy endpoint will also learn the IP addresses of the mDNS-aware endpoint, allowing ICE to succeed even though the legacy endpoint cannot resolve the mDNS names.  In the event the legacy endpoint attempts to resolve the mDNS names using Unicast DNS, this may cause ICE to take somewhat longer to fully complete, but should not have any effect on connectivity or connection setup time. </ins> However, some legacy endpoints are not fully spec-compliant and can behave unpredictably in the presence of ICE candidates that contain a <del> hostname, potentially leading to ICE failure.  Some endpoints may also fail to handle a connectivity check from an address that they have not received in signaling.  During the aforementioned experimental testing, the connection rate when interacting with endpoints that provided raw IP addresses (and therefore should be unaffected) decreased by 3% (relative), presumably for these reasons. </del> <ins> hostname, potentially leading to ICE failure.  Specifically, the SDP parsers in these endpoints may raise a fatal error when receiving such candidates, rather than simply ignoring them. Some endpoints may also fail to handle a connectivity check from an address that they have not received in signaling (i.e., they do not support learning peer-reflexive candidates as described above), leading to ICE failure.  During the aforementioned experimental testing, the connection rate when interacting with endpoints that provided raw IP addresses (and therefore should be unaffected) decreased by 3% (relative), presumably for these reasons. </ins> 6.

Discussion:
Legacy parsers may not be able to parse non-IP-addresses. It might be worth mentioning this issue in that section. Also: Section 5.3 says: "When an endpoint that supports mDNS communicates with an endpoint that does not, the legacy endpoint will still provide its local IP addresses, and accordingly a direct connection can still be attempted, even though the legacy endpoint cannot resolve the mDNS names provided by the new endpoint." Please make it more clear that the legacy endpoint is the one that does not support mDNS. Something like: "When an endpoint that supports mDNS communicates with a legacy endpoint that does not, the..." Taken from Christer review at URL
Seems reasonable, I think just inserting that one additional word is sufficient.
made one other comment: "We have seen one issue with a particular endpoint that did not implement ICE prflx candidates and could not follow the guidance in the text. This is already alluded to in S 4.3, but we may want to explicitly use the phrase "peer-reflexive" to make clear what behavior is needed from the legacy ICE agent." It seems like I added some of the Q4 text to Q3. Here is a corrected version of my question: Q1: I think it needs to be more clear that mDNS domain names (.local) can only be resolved by remote peers within the same local network. Section 5.1 does talk about this, and it may be an implicit assumption, but I think it should be pointed out in the beginning of the document. Q2: Related to Q1, think it needs to be more clear that the mechanism prevents IP address leaking to peers outside the local network. Inside the local network I assume that web apps can still find out about the local address simply by performing an mDNS lookup on the mDNS domain name. Q3: The draft makes an assumption that the mDNS domain names are unique. Why making that assumption? If the local network supports multicast, there may even be non-WebRTC applications using mDNS, which increases the risk for collision. Q4: Section 3.1.1 says that an ICE agent, when it gathers candidates, generates a UNIQUE mDNS domain name. I assume that means that the mDNS domain name will only be valid for the duration of the ICE session.

Doesn't that mean that there is no need for other ICE agents to cache the mDNS domain name:IP address mapping for "future use", because the mDNS domain name won't be used in future anyway? Also, I am not sure whether ICE implementations should cache mappings to begin with. That's the task of the mDNS client of the host. Q5: Section 5.3 says: "When an endpoint that supports mDNS communicates with an endpoint that does not, the legacy endpoint will still provide its local IP addresses, and accordingly a direct connection can still be attempted, even though the legacy endpoint cannot resolve the mDNS names provided by the new endpoint." Please make it more clear that the legacy endpoint is the one that does not support mDNS. Something like: "When an endpoint that supports mDNS communicates with a legacy endpoint that does not, the..." Q6: If I remember correctly, people have raised issues with legacy parsers not being able to parse non-IP-addresses. If so, shouldn't that be mentioned in Section 5.3? (NOTE: Eventhough the draft updates RFC 8839, to support mDNS domain names, it does not solve the issue for legacy parsers.) Q7: The draft does not give any guidance regarding how long an ICE agent can safely cache an mDNS Regards, Christer