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

Commentary: PR of 
 Added a ' good ' example as well , and put them all in an examples section . PTAL . 
 Will merge once I get a second approval . 
 Some of this stuff is complicated , example diagrams can help . 
 Great to have examples . Regenerating the html , the examples do not show up in full on the html version , probably not a big deal , the txt version is fine . 
 LGTM
Paragraph (version A):
A peer-reflexive remote candidate could be learned and constructed
from the source transport address of the STUN Binding request as an
ICE connectivity check.  The peer-reflexive candidate could share the
same address as a remote mDNS ICE candidate whose name is in the
process of being resolved.  In addition to the elimination procedure
of redundant candidates defined in Section 5.1.3 of RFC8445, which
could remove constructed peer-reflexive remote candidates, the
address of any existing peer-reflexive remote candidate should not be
exposed to Web applications by ICE agents that implement this
proposal, as detailed in Section #guidelines.
Paragraph (version B):
A peer-reflexive remote candidate could be learned and constructed
from the source transport address of the STUN Binding request as an
ICE connectivity check.  The peer-reflexive candidate could share the
same address as a remote mDNS candidate that is in the process of
being signaled or name resolution.
Paragraph (version B):
In addition to the elimination procedure of redundant candidates
defined in Section 5.1.3 of RFC8445, which could remove constructed
peer-reflexive remote candidates, the address of any existing peer-
reflexive remote candidate should not be exposed to Web applications
by ICE agents that implement this proposal, as detailed in
Section #guidelines.
Paragraph (version B):
In this example, mDNS candidates are exchanged between peers and
resolved to obtain the corresponding IP addresses.
Paragraph (version B):
The following two examples indicate how peer-reflexive candidates for
host IP addresses can be created due to timing differences.
Paragraph (version B):
In this example, a peer-reflexive candidate is generated because the
mDNS candidate is signaled after the STUN checks begin.
Paragraph (version B):
In this example, a peer-reflexive candidate is generated because the
mDNS resolution for name N2 does not complete until after the STUN
checks are received.
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: PR for 
 Seems all feedback is addresses ? 
 Host ICE candidates , ICE host candidates , or something else ?
Paragraph (version A):
Check whether the ICE agent has a usable registered mDNS hostname
resolving to the ICE host candidate's IP address.  If one exists,
skip ahead to Step 6.
Paragraph (version B):
Check whether the ICE agent has a usable registered mDNS hostname
resolving to the ICE candidate's IP address.  If one exists, skip
ahead to Step 6.
Paragraph (version A):
Replace the IP address of the ICE host candidate with its mDNS
hostname, and expose the candidate as usual.
Paragraph (version B):
Replace the IP address of the ICE candidate with its mDNS
hostname, and expose the candidate as usual.
Paragraph (version A):
If it resolves to an IP address, replace the value of the ICE host
candidate by the resolved IP address and continue processing of
the candidate.
Paragraph (version B):
If it resolves to an IP address, replace the mDNS hostname of the
ICE candidate with the resolved IP address and continue processing
of the candidate.
Paragraph (version A):
A peer-reflexive remote candidate could be learned and constructed
from the source transport address of the STUN Binding request as an
ICE connectivity check.  The peer-reflexive candidate could share the
same address as a remote host ICE candidate that will be signaled or
has been signaled, received and is in the process of name resolution.
In addition to the elimination procedure of redundant candidates
defined in Section 5.1.3 of RFC8445, which could remove constructed
peer-reflexive remote candidates, the address of any existing peer-
reflexive remote candidate should not be exposed to Web applications
by ICE agents that implement this proposal, as detailed in
Section #guidelines.
Paragraph (version B):
A peer-reflexive remote candidate could be learned and constructed
from the source transport address of the STUN Binding request as an
ICE connectivity check.  The peer-reflexive candidate could share the
same address as a remote mDNS ICE candidate whose name is in the
process of being resolved.  In addition to the elimination procedure
of redundant candidates defined in Section 5.1.3 of RFC8445, which
could remove constructed peer-reflexive remote candidates, the
address of any existing peer-reflexive remote candidate should not be
exposed to Web applications by ICE agents that implement this
proposal, as detailed in Section #guidelines.
Paragraph (version A):
host ICE candidates with an IP address are not exposed as ICE
candidate events.
Paragraph (version A):
SDP does not expose any a=candidate line corresponding to a host
ICE candidate which contains an IP address.
Paragraph (version B):
ICE candidates with an IP address are not exposed as ICE candidate
events.
Paragraph (version B):
SDP does not expose any a=candidate line corresponding to an ICE
candidate which contains an IP address.
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: Some additional comments may be needed in the prflx section ? 
 I went ahead and a commit for my proposed changes . Let me know if the proposed changes are fine with you . 
 Did you only commit the html changes ? Can you include the markdown ? 
 Oh , I probably messed up with the commit . I was expecting to commit only the markdown . I 'll fix it . 
 It is conceivable that a server would implement ICE with mDNS candidates . There should be nothing in the ICE candidate processing that prevents this from working . Therefore we should call out what should happen when an mDNS query returns multiple IP addresses . E.g. use the ' best ' on ( where IPv6 is better than IPv4 ) ? 
 This is a complex area . A simpler option could be that we mandate 1:1 for mDNS , and/or pick the first address of the expected type . 
 Mandating 1:1 for mDNS in the context of WebRTC is probably the straightforward approach . We should probably also define the behavior in the case of multiple responses , picking the first record makes sense to me . This requirement causes a potential issue when using MDNS for non default route though : it creates a fingerprinting vector by counting the number of different MDNS names for a given peer connection . I am not sure what reliable means we have to know the expected type of the address and whether this is a requirement at all . The easy solution would be to include this information in the MDNS name . 
 Good point about type not being known a priori , and we could put a hint in the name . Another option could be to resolve the name before forming pairs , take the first record found , and then only pair the resolved address with local candidates of the appropriate family . 
 Fixed by 
 LGTM with one comment
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 RFC6762 names.
Paragraph (version A):
Multicast DNS resolution might end up retrieving both an IPv4 and
IPv6 address.  In that case, the IPv6 address may be used preferably
to the IPv4 address.
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary:  is obsoleted by RFC8445 .
Paragraph (version A):
This section uses the concept of ICE agent as define in RFC5245.  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 define in RFC8445.  In
the remainder of the document, it is assumed that each browser
execution context has its own ICE agent.
Paragraph (version A):
If the connection-address field value of the ICE candidate does
not finish by ".local", process the candidate as defined in
RFC5245.
Paragraph (version B):
If the connection-address field value of the ICE candidate does
not finish by ".local", process the candidate as defined in
RFC8445.