Change:
SDP does not expose any a=candidate line corresponding to a host ICE candidate which contains an IP address. <del> RTCIceCandidateStats dictionaries exposed to web pages do not contain any 'ip' member if related to a host ICE candidate. </del> <ins> Statistics related to ICE candidates MUST NOT contain the resolved IP address of a remote mDNS candidate or the IP address of a peer- reflexive candidate, unless that IP address has already been learned through other means, e.g., receiving it in a separate server-reflexive remote candidate. 3.2. It is important that use of registered mDNS hostnames is limited in time and/or scope.  Indefinitely reusing the same mDNS hostname candidate would provide applications an even more reliable tracking mechanism than the private IP addresses that this specification is designed to hide.  The use of registered mDNS hostnames SHOULD be scoped by origin, and SHOULD have the lifetime of the page. 3.3. As noted in IPHandling, privacy may be breached if a web application running in two browser contexts can determine whether it is running on the same device.  While the approach in this document prevents the application from directly comparing local private IP addresses, a successful local WebRTC connection can also present a threat to user privacy.  Specifically, when the latency of a WebRTC connection latency is close to zero, the probability is high that the two peers are running on the same device. 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. 4. 4.1. The implementation of this proposal requires the mDNS querying capability of the browser for registering mDNS names or adding remote ICE host candidates with such names.  It also requires the mDNS responding capability of either the browser or the operating platform of the browser for registering, removing or resolving mDNS names.  In particular, the registration of name requires optional probing queries and mandatory announcing responses (RFC6762, Section 8}), and this is performed at the beginning of ICE gathering; the addition of remote ICE host candidates with mDNS names generates mDNS queries for names of each candidate; the removal of names could happen when the execution context of the ICE agent is destroyed in an implementation, and goodbye responses should be sent to invalidate records generated by the ICE agent in the local network (RFC6762, Section 10.1). A malicious Web application could flood the local network with mDNS messages by: creating execution contexts that create ICE agents and start gathering of local ICE host candidates; destroying these local candidates soon after the name registration is done; adding fictitious remote ICE host candidates with mDNS names. RFC6762 defines a per-record multicast rate limiting rule, in which a given record on a given interface cannot be sent less than one second since its last transmission.  This rate limiting rule however does not mitigate the above attacks, in which new names, hence new records, are constantly created and sent.  A browser-wide mDNS message rate limit MUST be provided for all messages that can be indirectly dispatched by a web application, namely the probing queries, announcement responses, resolution queries, and goodbye responses associated with mDNS. </ins> 4.2. <del> 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. </del> <ins> If the optional probing queries are implemented for the name registration, a malicious endpoint in the local network, which is capable of responding mDNS queries, could send responses to block the use of the generated names.  This would lead to the discarding of this ICE host candidate as in Step 5 in Section #gathering. The above attack can be mitigated by skipping the probing when registering a name, which also conforms to Section 8 in RFC6762, given that the name is randomly generated for the probabilistic uniqueness (e.g. a version 4 UUID) in Step 3 in Section #gathering. However, a similar attack can be performed by exploiting the negative responses (defined in RFC6762, Section 8.1), in which NSEC resource records are sent to claim the nonexistence of records related to the gathered ICE host candidates. The existence of malicious endpoints in the local network poses a generic threat, and requires dedicated protocol suites to mitigate, which is beyond the scope of this proposal. </ins> 4.3. <del> Privacy might also be breached if two execution contexts can identify whether they are run in the same device based on a successful peer- to-peer connection.  The proposed rule is to not register any name using Multicast DNS for any ICE agent belonging to: A third-party browser execution context, i.e. a context that is not same origin as the top level execution context. </del> <ins> A malicious endpoint in the local network may also record other endpoints who are registering, unregistering, and resolving mDNS names.  By doing so, they can create a session log that shows which endpoints are communicating, and for how long.  If both endpoints in the session are on the same network, the fact they are communicating can be discovered. </ins> <del> A private browsing execution context. </del> <ins> As above, mitigation of this threat is beyond the scope of this proposal. </ins> 5. <del> 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. </del> <ins> 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. </ins> <del> 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. </del> <ins> The proposal relies on adding the ability to register mDNS names at ICE gathering time.  This could be described in ICESDP and/or WebRTCSpec. </ins> The proposal allows updating IPHandling so that mode 2 is not the mode used by default when user consent is not required.  Instead, the <del> default mode could be defined as mode 3 with Multicast DNS based ICE </del> <ins> default mode could be defined as mode 3 with mDNS-based ICE </ins> candidates.

Discussion:
Attacks by message flooding and name registration blocking are detailed.
This PR is doing some renaming. Maybe it should be done in a separate commit PR. Also, the mention of a mdns name per browsing context might conflict with another PR.
LGTM with change to make limit browser-wide.
LGTM