Change:
Addresses part of .
Nils reviewed the document at URL There are a number of clarification points that could be made from the draft Makes sense to me. Right, I would tend to go with private IP addresses given RFC1918. We could refer to section 3.1.2.2 and refer to IP handling modes as well. We might want to further clarify that generating mDNS candidates ahead of time is an optimization. Makes sense to me.
Section 5.1 assumes that devices are on the same network. It might be good to be more explicit (maybe in the introduction) that local candidates are mostly useful when two devices are on the same network, which is where mDNS is actually useful.
Taken from Christer review at URL
Agree, this seems worth of its own paragraph in the intro, and probably also a brief mention at the start of Section 5. Hello, I was asked to review URL Here are my comment and questions: Abstract: “To maximize the probability of a direct peer-to-peer connection, client private IP addresses are included in this candidate collection.” I think it would make sense to replace “client” with ICE agent here, as client and server in the pure ICE context doesn’t make too much sense. I would suggest to change it to “..., private IP addresses of the ICE agent are included…”. In the abstract the terms “private IP addresses” and “local IP addresses” are used. I would suggest sticking to just one term for consistency. Section 1. “Introduction” has the same mix of local vs private in it. Section 3.1.1 point 1 I think it would be helpful if this draft at least offers the suggestion to replace all RFC1918 addresses, or put a reference to section 3.1.2.2 as a recommendation on how to determine which addresses to replace. Section 3.1.2.2 3rd paragraph “Regardless of results, …” confuses me. The last sentence in the paragraph before talks about the case of a public candidate. If I’m not mistaken in the case of a public address there shouldn’t be a server reflexive candidate generated. Section 3.1.2.2 4th paragraph While I agree that caching the result might be useful it can become dangerous in case the set of STUN servers changes. As the new STUN servers might return different results, cached results should be invalidated. Would it be worth adding a warning about this? Section 6.4 I’m confused by the diagram showing that both agents send over their mDNS candidates before having checked with the STUN server if the interface IP addresses need to be filtered or not. I understand that section 3.1.2.2 recommends to first wait for the STUN binding response from the STUN server before deciding which addresses should be filtered and which not. Why is this example showing it differently? Best regards Nils Ohlmeier
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

Discussion:
WebRTC applications collect ICE candidates as part of the process of creating peer-to-peer connections.  To maximize the probability of a <del> direct peer-to-peer connection, client private IP addresses are included in this candidate collection.  However, disclosure of these addresses has privacy implications.  This document describes a way to share local IP addresses with other clients while preserving client privacy.  This is achieved by concealing IP addresses with dynamically generated Multicast DNS (mDNS) names. </del> <ins> direct peer-to-peer connection, the endpoint's local IP addresses are included in this candidate collection.  However, these addresses are typically private and, as such, their disclosure has privacy implications.  This document describes a privacy-preserving way to share local IP addresses with other endpoints by concealing the addresses with dynamically generated Multicast DNS (mDNS) names. </ins> 1. <del> As detailed in IPHandling, exposing client private IP addresses by </del> <ins> As detailed in IPHandling, exposing client local IP addresses by </ins> default to web applications maximizes the probability of successfully creating direct peer-to-peer connections between clients, but creates a significant surface for user fingerprinting.  IPHandling recognizes

This document proposes an overall solution to this problem by extending ICESDP to allow ICE implementations to register ephemeral <del> mDNS RFC6762 names for local private IP addresses, and then provide those names, rather than the IP addresses, in their ICE candidates. While this technique is intended to benefit WebRTC implementations in web browsers, by preventing collection of private IP addresses by </del> <ins> mDNS RFC6762 names for local IP addresses, and then provide those names, rather than the IP addresses, in their ICE candidates.  While this technique is intended to benefit WebRTC implementations in web browsers, by preventing collection of private IP addresses by </ins> arbitrary web pages, it can also be used by any endpoint that wants to avoid disclosing information about its local network to remote peers on other networks.

resolution internally and will not disclose the actual IP addresses to the application. <ins> While mDNS names are usually only valid within a local network, the same is true for private IP addresses, and therefore this does not limit the effectiveness of this technique. </ins> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",