jiebi/TextFlow huggingface dataset:
Original text:
4.3. <del> Note that backward compatibility does not present a significant issue for the mDNS technique.  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.  In the event the legacy endpoint attempts to resolve mDNS names using </del>  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.  5. The examples below show how the mDNS technique is used during ICE

Reviewer comments:
LGTM
In the draft, we currently have no clear definition on this aspect. One thought we have is to couple the IP revealing permission with the getUserMedia permission. This is in alignment with the existing practice of the network enumeration permission in browsers. A separate permission from the user for the IP revealing is the alternative that reduces the implications from a single permission.
I think this is outside the scope of this work - it's already addressed in rtcweb-ip-handling.
My concern is the current draft does not provide a precise mapping to modes in rtcweb-ip-handling and the privacy guideline, namely Section 5. We may need the reference to mode 2.1 in ip-handling-ex-mdns, which however delegates the privacy guideline to ip-handling, and meanwhile ip-handling currently has only a brief recommendation after mode 4. A link feels missing in deriving (transitively) the exact condition in the text. This issue will probably be gone after consolidating the two ip-handling drafts and editing Section 5. Let me know what you think.
URL tries to spell this out, referring back to mdns-ice-candidates. I don't think mdns-ice-candidates should ref ip-handling-ex-mdns; I would prefer that any mode discussion be confined to that document.
Discussed and plan is to simply add some text that legacy endpoints are more likely to malfunction with mDNS names (in the same section where we talk about performance/cost downsides)
LGTM

Revised text:
4.3.  <ins> For the most part, backward compatibility does not present a significant issue for the mDNS technique.  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. In the event the legacy endpoint attempts to resolve mDNS names using </ins> 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 hostname, potentially leading to ICE failure.  Such endpoints have been identified during testing of this technique, but appear to be rare. </ins> 5. The examples below show how the mDNS technique is used during ICE
Original text:
IPv4 and IPv6 addresses MUST expose a different mDNS name for each address. <del> Any server-reflexive candidates generated from an mDNS local candidate MUST have their raddr field set to 0.0.0.0 and their rport field set to 0. </del>  Any candidates exposed to the web application via local descriptions MUST be identical to those provided during candidate gathering (i.e.,

Reviewer comments:
RFC 8445 sayeth in S 5.1.3: We should add a note to make it clear that mDNS candidates have distinct transport addresses from their equivalent IPs, and so a srflx candidate created from a public mDNS candidate MUST NOT be discarded as redundant.

Revised text:
IPv4 and IPv6 addresses MUST expose a different mDNS name for each address.  <ins> Note that any server-reflexive candidates generated from an mDNS host candidate will have IP addresses as their transport addresses, rather than mDNS hostnames.  Because their transport addresses are different (i.e., not hostnames), they MUST NOT be considered redundant with their host counterparts, per the guidance in RFC8445, Section 5.1.3. To avoid accidental leakage, these candidates MUST have their raddr field set to 0.0.0.0 and their rport field set to 0. </ins> Any candidates exposed to the web application via local descriptions MUST be identical to those provided during candidate gathering (i.e.,
Original text:
connectivity, reduced throughput and increased latency, as well as increased cost in case of TURN relay.  One potential mitigation, as discussed in privacy, is to not conceal candidates created from RFC4941 IPv6 addresses.  This permits connectivity even in large internal networks or where mDNS is <del> disabled. The exact impact of the mDNS technique is being researched experimentally and will be provided before publication of this document. </del>  4.2. 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.  Such endpoints have been identified during testing of this technique, but appear to be rare. </del>  5.

Reviewer comments:
ping
Will we get sources for these numbers that elaborate distribution and regional differences?
LGTM modulo the thought on mentioning the potential impact of c= line before the update.
No answer to my question?
NAME I struggled to respond to the question since it's so open-ended, and really outside the scope of this PR. Suggest filing an issue and we can discuss more there.

Revised text:
connectivity, reduced throughput and increased latency, as well as increased cost in case of TURN relay. <ins> During experimental testing of the mDNS technique across a set of known mDNS-aware endpoints that had configured a STUN server but not a TURN server, the observed impact to ICE connection rate was 2% (relative) when mDNS was enabled on both sides, compared to when mDNS was only enabled on one side.  In this testing, the percentage of connections that required STUN (i.e., went through a NAT) increased from 94% to 97%, indicating that mDNS succeeded about half the time, and fell back to NAT hairpin for the remainder.  The most likely explanation for the overall connection rate drop is that hairpinning failed in some cases. </ins> One potential mitigation, as discussed in privacy, is to not conceal candidates created from RFC4941 IPv6 addresses.  This permits connectivity even in large internal networks or where mDNS is  <ins> disabled.  Future versions of this document will include experimental data regarding this option. </ins> 4.2. However, some legacy endpoints are not fully spec-compliant and can behave unpredictably in the presence of ICE candidates that contain a  <ins> 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. </ins> 5.
Original text:
as the hostname is expected to be unique, the ICE agent SHOULD skip probing of the hostname. <del> If registering of the mDNS hostname fails, abort these steps.  The candidate is not exposed. </del> Store the mDNS hostname and its related IP address in the ICE agent for future reuse. ICE agents can implement this procedure in any way as long as it produces equivalent results.  An implementation may for instance pre- <del> register mDNS hostnames by executing steps 3 to 6 and prepopulate an ICE agent accordingly.  By doing so, only step 7 of the above </del>  procedure will be executed at the time of gathering candidates. <del> An implementation may also detect that mDNS is not supported by the available network interfaces.  The ICE agent may skip steps 3 and 4 and directly decide to not expose the host candidate. </del>  This procedure ensures that an mDNS name is used to replace only one IP address.  Specifically, an ICE agent using an interface with both

Reviewer comments:
Fixes URL
An implementation should probably expose mDNS candidates to a page regardless of successful registration or mDNS support in the network.

Revised text:
as the hostname is expected to be unique, the ICE agent SHOULD skip probing of the hostname.  Store the mDNS hostname and its related IP address in the ICE agent for future reuse. ICE agents can implement this procedure in any way as long as it produces equivalent results.  An implementation may for instance pre-  <ins> register mDNS hostnames by executing steps 3 to 5 and prepopulate an ICE agent accordingly.  By doing so, only step 6 of the above </ins> procedure will be executed at the time of gathering candidates.  <ins> In order to prevent web applications from using this mechanism to query for mDNS support in the local network, the ICE agent SHOULD still provide mDNS candidates in step 6 even if the local network does not support mDNS or mDNS registration fails in step 4. </ins> This procedure ensures that an mDNS name is used to replace only one IP address.  Specifically, an ICE agent using an interface with both
Original text:
To prevent disclosure of the host IP address to a TURN server, the ICE agent MUST NOT form candidate pairs between its own relay <del> candidates and remote mDNS candidates.  Note that the converse is not an issue; the ICE agent MAY form candidate pairs between its own mDNS candidates and remote relay candidates, as in this situation host IPs will not be sent directly to the TURN server. </del>  This restriction has no effect on connectivity; in the cases where host IP addresses are private and need to be wrapped with mDNS names,

Reviewer comments:
Fixes URL
It is required not to pair local relay candidates with remote mDNS candidates to avoid the leak via CreatePermission requests. As Phillip points in this issue (URL), an ICE agent should not rely on the candidate type field in a hostname candidate to reinforce this constraint. The a=candidate line in signaling can be modified to inject an arbitrary type. Suggest that we clarify the remote mDNS candidates include all hostname candidates with the .local pseudo-TLD.
Seems reasonable. The text does not restrict to "typ host", but being extra specific here would still be a good idea. Phillip also points out that we may want to do this for all DNS names, to prevent the browser from becoming a roundabout DNS resolver, but that is probably outside the scope of this document.

Revised text:
To prevent disclosure of the host IP address to a TURN server, the ICE agent MUST NOT form candidate pairs between its own relay  <ins> candidates and remote mDNS candidates.  This restriction must not be limited to remote mDNS candidates of a specific candidate type, typically host, as mDNS candidates are identified from their connection-address fields.  their connection-address field.  Note also that the converse is not an issue; the ICE agent MAY form candidate pairs between its own mDNS candidates and remote relay candidates, as in this situation host IPs will not be sent directly to the TURN server. </ins> This restriction has no effect on connectivity; in the cases where host IP addresses are private and need to be wrapped with mDNS names,
Original text:
Using Multicast DNS to protect privacy when exposing ICE candidates <del> draft-ietf-rtcweb-mdns-ice-candidates-latest </del>  Abstract

Reviewer comments:
LGTM but travis does not seem happy, not sure why: git -C /tmp/ghpages5574 push -q URL gh-pages 684make: * [ghpages] Error 128
I think the bot doesn't have push credentials on this repo. I'll look into it.
LGTM. The travis failure may render https://rtcweb-URL unavailable but shouldn't impact other parts. I wonder if the failure is caused by name mismatch somewhere in the config.

Revised text:
Using Multicast DNS to protect privacy when exposing ICE candidates  <ins> draft-ietf-mmusic-mdns-ice-candidates-latest </ins> Abstract
Original text:
4.3. <del> When sending data to a TURN RFC5766 server, the sending client tells the server the destination IP and port for the data.  This means that if the client uses TURN to send to an IP that was obtained by mDNS resolution, the TURN server will learn the underlying host IP and port, and this information can then be relayed to the web application, defeating the value of the mDNS wrapping. To prevent disclosure of the host IP address to a TURN server, the ICE agent MUST NOT form candidate pairs between its own relay candidates and remote mDNS candidates.  Note that the converse is not an issue; the ICE agent MAY form candidate pairs between its own mDNS candidates and remote relay candidates, as in this situation host IPs will not be sent directly to the TURN server. This restriction has no effect on connectivity; in the cases where host IP addresses are private and need to be wrapped with mDNS names, they will be unreachable from the TURN server, and as noted above, the reverse path will continue to work normally. 4.4. </del> 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 designed to hide.  The use of registered mDNS hostnames SHOULD be scoped by origin, and SHOULD have the lifetime of the page. <del> 4.5. </del>  As noted in IPHandling, privacy may be breached if a web application running in two browsing contexts can determine whether it is running

Reviewer comments:
PR of
I will upload a PR for this.
OK, bad merge, thanks for catching
Fixed by
E.g. "Step 5 in Section {{gathering}}" in .md becomes "Step 5 in Section Section 2.1" in .html or "Step 5 in Section Section 2.1" in the raw html source.
Was this fixed?
No, it looks to me an issue with the generator code. Or, can I fix it inline? I was assuming the html would be auto-generated, but if it is supposed to just upload a copy, I will fix it inline asap.
I was wrong. This issue is gone in the newly generated HTML (from the "here" link), but we probably need to regenerate it after merging PR
OK, will do as part of the upload
Resolved in latest HTML.

Revised text:
4.3.  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 designed to hide.  The use of registered mDNS hostnames SHOULD be scoped by origin, and SHOULD have the lifetime of the page.  <ins> 4.4. </ins> As noted in IPHandling, privacy may be breached if a web application running in two browsing contexts can determine whether it is running
Original text:
7.  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

Reviewer comments:
PR for
IANA Considerations A. Must specify if IANA has to create a new registry or modify rules for an existing registry. B. Must specify if the document requires IANA to assign or update values in an IANA registry before RFC publication. C. See "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) and in some cases also "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers" [RFC2780] (Bradner, S. and V. Paxson, “IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers,” March 2000.) [RFC5237] (Arkko, J. and S. Bradner, “IANA Allocation Guidelines for the Protocol Field,” February 2008.). In some case "Assigning Experimental and Testing Numbers Considered Useful" [RFC3692] (Narten, T., “Assigning Experimental and Testing Numbers Considered Useful,” January 2004.) may help as well. D. If there is no action for IANA, the section should say that, e.g., including something like "This document has no actions for IANA."
Good catch. Do you want to take a shot at this? JSEP says
Not blocking for today's doc, to be clear.
Fixed by

Revised text:
7. <ins> This document requires no actions from IANA. 8. </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
Original text:
a context that has a different origin than the top-level browsing context), or a private browsing context.  7. 7.1.

Reviewer comments:
Original text: I'm not sure this provides an actual new fingerprinting surface - assuming the interface is in fact exposed to the outside world, a srflx candidate will also be generated for each mDNS candidate - and in the mode we are most concerned about, Mode 2, there will either be 1 or 2 mDNS candidates.
If we decide that this draft only applies to mode 2 or default routes, I agree that there is no fingerprinting surface. However, that assumption hasn't been called out anywhere in this doc AFAIK.
We still get a srflx and TURN candidate for each interface though.
Ok, good point. I agree, we should remove that paragraph. I'll create a PR
If an interface cannot connect to a STUN server, there will be no srflx candidate. I don’t think we can assume that such interface will also not support multicast.
Right, as noted in the OP, but this seems like an edge case.
I think it is better to mention an issue even though this is an edge case. Something like: If there are multiple host candidates with different IP addresses, IPv4 and/or IPv6, each results in a separate mDNS hostname candidate. The number of mDNS hostname candidates might provide a fingerprinting dimension. This is in particular the case for network interfaces whose existence are not exposed through other means like provided STUN servers. No new information is provided when exposing default route candidates.
Filed URL to follow up on that.
Approved with minor suggestions

Revised text:
a context that has a different origin than the top-level browsing context), or a private browsing context. <ins> 6.5. Even when local IP addresses are not exposed, the number of mDNS hostname candidates can still provide a fingerprinting dimension. This is in particular the case for network interfaces with limited connectivity that will not generate server-reflexive or relay candidates. The more mDNS names an endpoint exposes through mDNS hostname candidates, the higher the fingerprinting risk.  One countermeasure is to limit this number to a small value. Note that no additional fingerprinting risk is introduced when restricting mDNS hostname candidates to default route only. </ins> 7. 7.1.
Original text:
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 <del> dynamically generated Multicast DNS (mDNS) RFC6762 names. </del>  1. not be supported. This document proposes an overall solution to this problem by <del> 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. </del>  2.

Reviewer comments:
From the 'nits' link on top of the IETF submitted version. ** The abstract seems to contain references ([RFC6762]), which it shouldn't. Please replace those with straight textual mentions of the documents in question.
Probably can just move the ref to the intro section.
URL
LGTM

Revised text:
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  <ins> dynamically generated Multicast DNS (mDNS) names. </ins> 1. not be supported. This document proposes an overall solution to this problem by  <ins> registering ephemeral mDNS RFC6762 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. </ins> 2.
Original text:
IPv6 address resolved, if one exists, or the first IPv4 address, if not.  4. 4.1. As above, mitigation of this threat is beyond the scope of this proposal.  8. This document requires no actions from IANA.

Reviewer comments:
As pointed by NAME one can stuff ICE candidates with mDNS names that are not UUID. This may ease exposing some devices (URL) to some unsolicited mDNS/STUN traffic.
To be noted that a web application can currently synthesize candidates with well-known IP addresses/address ranges. Allowing non UUID mDNS resolution might ease such attacks. We should evaluate whether this is fine as is or not. One possibility would be to mandate mDNS resolution for UUID-based names only.
I am inclining towards mandating mDNS resolution for UUID-base names only. My rationale is the technique proposed is essentially intended to expose no handle to applications to tweak. A general name + .local could fall back to the path of FQDN ICE supported by unicast DNS currently, with better security scrutiny.
Implementations might use the same code path for mDNS and unicast DNS, so I am not sure this will be easy to do this distinction in practice. I would do the distinction between applications that trust the source of ICE candidates (in which case any mDNS is fine) from cases where there is no trust (web browsers typically). In the latter case, I would go with a SHOULD statement.
Started PR URL
Fixed via
Approved with a few editorial comments

Revised text:
IPv6 address resolved, if one exists, or the first IPv4 address, if not. <ins> An ICE agent MAY add additional restrictions regarding the ICE candidates it will resolve using mDNS, as this mechanism allows attackers to send ICE traffic to devices with well-known mDNS names. </ins> 4. 4.1. As above, mitigation of this threat is beyond the scope of this proposal. <ins> 7.4. As noted in Section 4.2 of RTCWebSecurity, an attacker may use ICE as a way to send unsolicited network traffic to specific endpoints. While this is not specific to mDNS hostname candidates, this technique makes it easier to target devices with well-known mDNS names. As noted in processing, ICE agents may decide to not resolve mDNS names, for example, if these names are not in the format defined by gathering. </ins> 8. This document requires no actions from IANA.