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

Commentary: Or alternatively consistently use mDNS , but mention in the intro that this refers to Multicast DNS { { RFC6762 } } 
 Yeah , I think we should do the latter . That 's what 6762 does .
Paragraph (version A):
WebRTC applications collect ICE candidates as part of the process of
creating peer-to-peer connections.  To maximize the probability of a
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 obfuscating IP addresses with
dynamically generated Multicast DNS RFC6762 names.
Paragraph (version B):
WebRTC applications collect ICE candidates as part of the process of
creating peer-to-peer connections.  To maximize the probability of a
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 obfuscating IP addresses with
dynamically generated Multicast DNS (mDNS) RFC6762 names.
Paragraph (version A):
This document proposes an overall solution to this problem by
registering ephemeral Multicast DNS names for each local private IP
address, and then providing those names, rather than the IP
addresses, to the web application when it gathers ICE candidates.
WebRTC implementations resolve these names to IP addresses and
perform ICE processing as usual, but the actual IP addresses are not
exposed to the web application.
Paragraph (version B):
This document proposes an overall solution to this problem by
registering ephemeral mDNS names for each local private IP address,
and then providing those names, rather than the IP addresses, to the
web application when it gathers ICE candidates.  WebRTC
implementations resolve these names to IP addresses and perform ICE
processing as usual, but the actual IP addresses are not exposed to
the web application.
Paragraph (version A):
Register the candidate's mDNS hostname using Multicast DNS.
Paragraph (version B):
Register the candidate's mDNS hostname as defined in RFC6762.
Paragraph (version A):
Otherwise, use the value and resolve it using Multicast DNS.
Paragraph (version B):
Otherwise, resolve the candidate using mDNS.
Paragraph (version A):
To avoid this issue, browsers SHOULD NOT register Multicast DNS names
for WebRTC applications running in a third-party browser execution
context (i.e., a context that has a different origin than the top-
level execution context), or a private browser execution context.
Paragraph (version A):
The proposal relies on identifying and resolving any Multicast DNS
based ICE candidates as part of adding/processing a remote candidate.
ICESDP section 4.1 could be updated to explicitly allow Multicast DNS
names in the connection-address field.
Paragraph (version A):
The proposal relies on adding the ability to register Multicast DNS
names at ICE gathering time.  This could be described in ICESDP and/
or WebRTCSpec.
Paragraph (version B):
To avoid this issue, browsers SHOULD NOT register mDNS names for
WebRTC applications running in a third-party browser execution
context (i.e., a context that has a different origin than the top-
level execution context), or a private browser execution context.
Paragraph (version B):
The proposal relies on identifying and resolving any mDNS-based ICE
candidates as part of adding/processing a remote candidate.  ICESDP
section 4.1 could be updated to explicitly allow mDNS names in the
connection-address field.
Paragraph (version B):
The proposal relies on adding the ability to register mDNS names at
ICE gathering time.  This could be described in ICESDP and/or
WebRTCSpec.