jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: Let 's also consider data use cases here : Fallback to TURN has a severe effect on throughput in many cases . 
 Sure , could add a brief note on this . 
 The text here is n't normative , so I do n't think we need to have a lengthy discussion of this - a few words should suffice . 
 Fixed by 
 LGTM
Paragraph (version A):
When mDNS fails, ICE will attempt to fall back to either NAT hairpin,
if supported, or TURN relay, if not.  As noted in IPHandling, this
may result in increased media latency and reduced connectivity/
increased cost (depending on whether the application chooses to use
TURN).
Paragraph (version B):
When mDNS fails, ICE will attempt to fall back to either NAT hairpin,
if supported, or TURN relay if not.  This may result in reduced
connectivity, reduced throughput and increased latency, as well as
increased cost in case of TURN relay.
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: This work is already in motion in the desired documents . 
 LGTM 
 IOW , should this document define the new modes , or just how mDNS should be used to hide local IP addresses ? If the latter , we would then also need to write a ip - handling v2 that defined the new modes , and pointed at this doc for details on how the technique should work . 
 From last meeting discussions , the plan was to define the new modes in this document and add a note in the ip - handling document that new modes might be defined with an informative reference to this document . I think defining the new modes in this document will also ease the authoring work and the review from the RTCWeb WG . In the long run , I think an ip - handling v2 might be a better place for the definition of the modes . For instance the guidelines around a default mode does belong in the ip - handling document , not the mdns - ice - candidate document . 
 OK . This particular document may be in the wrong WG then , but we can leave those details for later . 
 Leaving this open to cull the Specification Requirements section once it has been fully incorporated into ip - mdns - ext .
Paragraph (version A):
This document requires no actions from IANA.
Paragraph (version A):
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 A):
The proposal relies on adding the ability to register mDNS names at
ICE gathering time.  This could be described in ICESDP and/or
WebRTCSpec.
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: On line 421 : " that this specification is designed to hide " . Could edit that as well . 
 My take is that we do n't need to use the same term in every case , but the terms should have the same meaning . conceal and hide are fairly synonymous , but conceal and obfuscate have slightly different meanings . 
 Does it obfuscate , conceal , or obscure local IP addresses ? My vote is for conceal . 
 Conceal / concealment sgtm . 
 As noted in , we do n't need to use the same term in every case , but the terms should have the same meaning . conceal and hide are fairly synonymous , but conceal and obfuscate have slightly different meanings .
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 (mDNS) 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 concealing IP addresses with
dynamically generated Multicast DNS (mDNS) names.
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: As pointed by one can stuff ICE candidates with mDNS names that are not UUID . This may ease exposing some devices ( ) 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 
 Fixed via 
 Approved with a few editorial comments
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: This allows specific examples to be referenced directly . 
 Will wait for 2nd LGTM before merging .
Paragraph (version A):
In this example, mDNS candidates are exchanged between peers and
resolved to obtain the corresponding IP addresses.
Paragraph (version A):
The following two examples indicate how peer-reflexive candidates for
host IP addresses can be created due to timing differences.
Paragraph (version B):
The examples below show how the mDNS technique is used during ICE
processing.  The first example shows the typical case, and the other
two examples demonstrate how peer-reflexive candidates for local IP
addresses can be created due to timing differences.
Paragraph (version B):
In this example, mDNS candidates are exchanged between peers and
resolved normally to obtain the corresponding IP addresses.
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: Added new section on latency , as requested by PTAL - will plan to merge at EOD if there are no outstanding comments . 
 Include experimental results , if we have them 
 LGTM
Paragraph (version B):
With typical ICE, endpoints on the same network will usually be able
to establish a direct connection between their local IP addresses.
When using the mDNS technique, a direct connection is still possible,
but only if at least one side can properly resolve the provided mDNS
candidates.  This may not be possible in all scenarios.
Paragraph (version B):
First, some networks may entirely disable mDNS.  Second, mDNS queries
have limited scope.  On large networks, this may mean that an mDNS
name cannot be resolved if the remote endpoint is too many segments
away.
Paragraph (version B):
When mDNS fails, ICE will attempt to fall back to either NAT hairpin,
if supported, or TURN relay, if not.  As noted in IPHandling, this
may result in increased media latency and reduced connectivity/
increased cost (depending on whether the application chooses to use
TURN).
Paragraph (version B):
The exact impact of this technique is being researched experimentally
and will be provided before publication of this document.
Paragraph (version B):
As noted in {#principle}, ICE agents using the mDNS technique are
responsible for registering and resolving mDNS names as part of the
ICE process.  These steps may delay establishment of a direct peer-
to-peer connection, compared to when raw local IP addresses are used.
Paragraph (version B):
Given that these mDNS registrations and queries are typically
occurring on a local network, any associated delays should be small.
Also, as noted in {#gathering}, pre-registration can be employed to
eliminate gathering delays entirely.
Paragraph (version B):
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
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.
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: From the ' nits ' link on top of the IETF submitted version . * * The abstract seems to contain references ( [ RFC6762 ] ) , which it should n't . Please replace those with straight textual mentions of the documents in question . 
 Probably can just move the ref to the intro section . 
 LGTM
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 (mDNS) 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) names.
Paragraph (version A):
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 B):
This document proposes an overall solution to this problem by
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.
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: 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 has n'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 can not connect to a STUN server , there will be no srflx candidate . I do n’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 to follow up on that . 
 Approved with minor suggestions
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
Note that no additional fingerprinting risk is introduced when
restricting mDNS hostname candidates to default route only.
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: PR for 
 The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate , even if it appears to use RFC 2119 keywords . 
 Indeed . Probably just need a Section 2 that says The key words " MUST " , " MUST NOT " , " REQUIRED " , " SHALL " , " SHALL NOT " , " SHOULD " , " SHOULD NOT " , " RECOMMENDED " , " MAY " , and " OPTIONAL " in this document are to be interpreted as described in { { RFC2119 } } . 
 Fixed by
Paragraph (version B):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119.
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: 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 ] (  , 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   , “ IANA Allocation Guidelines For Values In the Internet Protocol and   , ” March 2000 . ) [ RFC5237 ] ( Arkko ,  and S. Bradner , “ IANA Allocation Guidelines for the Protocol Field , ” February 2008 . ) . In some case " Assigning Experimental and Testing Numbers Considered Useful " [ RFC3692 ] (  , 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 ?  says 
 Not blocking for today 's doc , to be clear . 
 Fixed by
Paragraph (version B):
This document requires no actions from IANA.
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: 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 < a href="#gathering " class="xref"Section 2.1</a " 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 .
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version A):
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.
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: LGTM too , will resolve conflicts 
 If we resolve a name N1 to 1.1.1.1 , should we pair it with relay candidates ? If we do so , 1.1.1.1 will be sent to the TURN server , which seems like a leak ( could be under the control of the web app ) . Probably need to add a section in the privacy considerations saying any remote mdns candidates MUST NOT be paired with local relay candidates ( although the reverse should be OK ) . 
 I am thinking about the impact on the connectivity , and if we can ever resolve the remote mdns candidate , the chance of selecting relay<-mdns even if this is allowed could probably be low if the local side also gathers a host candidate . The MUST level lgtm . 
 yeah , and keep in mind that usually these host IPs will be things like 192.168.1.3 that are not even reachable by the outside world . 
 Well thought ! Agreed , I always thought TURN and STUN were intertwined ( TURN server is probably also a STUN server or at least hosted in the same network ) so that we can use server reflexive candidates for TURN without losing much . 
 yeah - we already throw away private IPs for TURN to avoid creating connections that wo n't work , so the actual impact here is negligible . 
 LGTM
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: PR of 
 Anyone else want to take a look ? 
 ( browser ) execution context -browsing context 
 It was suggested to replace the name by " browsing context " in the PR of the security consideration . Execution or browser execution context is consistently used in the new commits , and I will create a PR for this if we decide to change the name .
Paragraph (version A):
This section uses the concept of ICE agent as define in RFC8445.  In
the remainder of the document, it is assumed that each browser
execution context has its own ICE agent.
Paragraph (version B):
This section uses the concept of ICE agent as defined in RFC8445.  In
the remainder of the document, it is assumed that each browsing
context (as defined in Section 7.1 of HTMLSpec) has its own ICE
agent.
Paragraph (version A):
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.
Paragraph (version B):
As noted in IPHandling, privacy may be breached if a web application
running in two browsing 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.
Paragraph (version A):
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):
To avoid this issue, browsers SHOULD NOT register mDNS names for
WebRTC applications running in a third-party browsing context (i.e.,
a context that has a different origin than the top-level browsing
context), or a private browsing context.
Paragraph (version A):
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).
Paragraph (version B):
the removal of names could happen when the browsing 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).