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

Commentary: Let 's remove this sentence and add more information when we will have this additional experimental data 
 This area probably needs more experimentation in general . For instance , it is unclear how much we could partition such IPv6 addresses by origin like we ask for mDNS names . Given we already talk about this approach in the privacy section , these sentences do not feel mandatory to keep . No strong feelings either way though . 
 I looked at the current text more closely and I see what you are saying , especially regarding different origins . We should probably talk about the separation of origins or browsing contexts more in the introduction though . Currently it only refers to the fingerprinting threat , which could be construed to simply mean a long - term identifier . 
 I do n't think we needed to nuke this whole section , just the future version of the document sentence .
Paragraph (version A):
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
disabled.  Future versions of this document will include experimental
data regarding this option.
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: Fixes 
 There is some metadata that needs to be set , the style also tends to be to put the update into its own section ( e.g. , ) . I updated the PR accordingly . 
 LGTM 
 Ensure that ice - sip - sdp ( S 4.1 ) has been updated to allow FQDN addresses . 
 What are the next steps here ? 
 ice - sip - sdp sayeth : < connection - address : is taken from RFC 4566 [ RFC4566 ] . It is the IP address of the candidate , allowing for IPv4 addresses , IPv6 addresses , and fully qualified domain names ( FQDNs ) . When parsing this field , an agent can differentiate an IPv4 address and an IPv6 address by presence of a colon in its value - the presence of a colon indicates IPv6 . An agent generating local candidates MUST NOT use FQDN addresses . An agent processing remote candidates MUST ignore candidate lines that include candidates with FQDN or IP address versions that are not supported or recognized . The procedures for generation and handling of FQDN candidates , as well as , how agents indicate support for such procedures , need to be specified in an extension specification . Perhaps this spec should explicitly update mmusic - sip - sdp as providing a procedure for handling mDNS FQDN candidates . Probably something for the WG to weigh in on . 
 The latest guideline from the email thread is to update ICE - SIP - SDP in the mdns - ice - candidates draft . 
 I 'm not sure either if we need to update anything else to link the monkey patch to ICESDP . I 'll look that up . Otherwise lgtm .
Paragraph (version A):
This document proposes an overall solution to this problem by
providing a mechanism for WebRTC implementations to register
ephemeral mDNS RFC6762 names for local private IP addresses, and then
provide those names, rather than the IP addresses, in their ICE
candidates.  While this technique is intended to benefit WebRTC
implementations in web browsers, by preventing collection of private
IP addresses by arbitrary web pages, it can also be used by any
endpoint that wants to avoid disclosing information about its local
network to remote peers on other networks.
Paragraph (version B):
This document proposes an overall solution to this problem by
extending ICESDP to allow ICE implementations to register ephemeral
mDNS RFC6762 names for local private IP addresses, and then provide
those names, rather than the IP addresses, in their ICE candidates.
While this technique is intended to benefit WebRTC implementations in
web browsers, by preventing collection of private IP addresses by
arbitrary web pages, it can also be used by any endpoint that wants
to avoid disclosing information about its local network to remote
peers on other networks.
Paragraph (version B):
An agent generating local candidates MUST NOT use FQDN addresses.
An agent processing remote candidates MUST ignore candidate lines
that include candidates with FQDN or IP address versions that are
not supported or recognized.
Paragraph (version B):
This document extends ICESDP to specifically allow the generation and
processing of ICE candidates with the ".local" FQDNs defined in
{gathering}.  The restrictions on other FQDNs are unaffected.
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: PR related to
Paragraph (version A):
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.
Paragraph (version B):
As noted in processing, ICE agents are discouraged to resolve mDNS
names that are not in the format defined by gathering and may further
constrain the mDNS names they will actually try to resolve.
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: Together with , this should fix
Paragraph (version B):
Statistics SHOULD NOT leak whether the mDNS resolution succeeds or
fails.  For that reason, RTCIceCandidateStats objects as defined in
WebRTCStats SHOULD be generated for any remote mDNS candidate
submitted to the ICE agent, even if the mDNS candidate is ignored as
part of processing.  An implementation strategy to obfuscate the
address of an mDNS candidate in the statistics, regardless if it is
resolved or not, is to replace the mDNS hostname of the ICE candidate
with IP values "0.0.0.0" or "::".
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: Fixes 
 See for details 
 I a step where we ignore the candidate in that case . The term ' ignore ' should probable be refined as it is used both here and in the context of We might want to update ignore in context . 
 LGTM
Paragraph (version B):
If the ICE candidate policy is "relay", as defined in JSEP, ignore
the candidate.
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: Partially solves 
 LGTM
Paragraph (version A):
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):
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.
In particular, ICE agents SHOULD NOT resolve mDNS names if they are
not in the format defined by gathering.
Paragraph (version B):
Also, the same technique can be used as an oracle to determine
whether some local services are reachable in the local network.  This
knowledge can be used for fingerprinting purposes or as a basis for
attacking local networks.
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: Fixes 
 It is required not to pair local relay candidates with remote mDNS candidates to avoid the leak via CreatePermission requests . As  points in this issue ( ) , 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 .  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 .
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 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.  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.
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: Good catch . LGTM .
Paragraph (version A):
Check whether the ICE agent has previously generated, registered,
and stored an mDNS hostname for this IP address as per Steps 3, 4,
and 6.  If it has, skip ahead to Step 7.
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: Fixes 
 An implementation should probably expose mDNS candidates to a page regardless of successful registration or mDNS support in the network .
Paragraph (version A):
If registering of the mDNS hostname fails, abort these steps.  The
candidate is not exposed.
Paragraph (version A):
ICE agents can implement this procedure in any way as long as it
produces equivalent results.  An implementation may for instance pre-
register mDNS hostnames by executing steps 3 to 6 and prepopulate an
ICE agent accordingly.  By doing so, only step 7 of the above
procedure will be executed at the time of gathering candidates.
Paragraph (version A):
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.
Paragraph (version B):
ICE agents can implement this procedure in any way as long as it
produces equivalent results.  An implementation may for instance pre-
register mDNS hostnames by executing steps 3 to 5 and prepopulate an
ICE agent accordingly.  By doing so, only step 6 of the above
procedure will be executed at the time of gathering candidates.
Paragraph (version B):
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.
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary:   , PTAL 
 LGTM too 
 Currently it contains : c = IN IP4 address / ttl Obviously , putting one of the candidate 's IP address there would defeat the purpose of use mDNS . Options : Can this be omitted ? Should it have a fake IP address of the right address family ? Should it be allowed to have an mDNS name ? 
 Just use the mDNS name . 
 If we run into issues , we could use 0.0.0.0:9 as we do when there are no candidates , but that starts to get complicated ( i.e. may require updates to other specs ) 
 mDNS name with IP4 ? 
 good point - should n't matter that much , but IP4 seems like the safest choice . 
 Agreed to use mDNS + IP4 . We 'll reevaluate if this causes problems . 
 Fixed by 
 We have observed an interop issue in the experimental deployment . Endpoints can fail to parse the SDP when the c= line contains a FQDN . This is the current solution . 
 Well , at least we thought of the solution already :)
Paragraph (version A):
Regardless of the result, a server-reflexive candidate will be
generated; the transport address of this candidate is an IP address
and therefore distinct from the hostname transport address of the
associated mDNS candidate, and as such MUST NOT be considered
redundant per the guidance in RFC8445, Section 5.1.3.  To avoid
accidental IP address, this server-reflexive candidate MUST have its
raddr field set to 0.0.0.0 and its rport field set to 0.
Paragraph (version B):
Regardless of the result, a server-reflexive candidate will be
generated; the transport address of this candidate is an IP address
and therefore distinct from the hostname transport address of the
associated mDNS candidate, and as such MUST NOT be considered
redundant per the guidance in RFC8445, Section 5.1.3.  To avoid
accidental IP address disclosure, this server-reflexive candidate
MUST have its raddr field set to "0.0.0.0"/"::" and its rport field
set to "9", as discussed in ICESDP, Section 9.1.
Paragraph (version A):
The mDNS name of an mDNS candidate MUST be used in the connection-
address field of its candidate attribute.  When an mDNS candidate is
the default candidate, its mDNS name MUST be used in the connection-
address field of the SDP "c=" line.  Since an mDNS candidate also
conceals its address family, the "c=" line SHOULD use "IP4" in the
address-type field.
Paragraph (version B):
The mDNS name of an mDNS candidate MUST be used in the connection-
address field of its candidate attribute.  However, when an mDNS
candidate would be the default candidate, typically because there are
no other candidates, its mDNS name MUST NOT be used in the
connection-address field of the SDP "c=" line, as experimental
deployment has indicated that many remote endpoints will fail to
handle such a SDP.  In this situation, the IP address values
"0.0.0.0"/"::" and port value "9" MUST instead be used in the c= and
m= lines, similar to how the no-candidates case is handled in ICESDP,
Section 4.3.1.
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary:    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 ? 
 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 .
Paragraph (version A):
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
disabled.
Paragraph (version A):
The exact impact of the mDNS technique is being researched
experimentally and will be provided before publication of this
document.
Paragraph (version B):
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.
Paragraph (version B):
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
disabled.  Future versions of this document will include experimental
data regarding this option.
Paragraph (version A):
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.
Paragraph (version B):
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.  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.
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: PR for I considered referring to RFC6724 , but that raises more questions than it answers it seems . 
 From   : When more than one IPv4 or more than one IPv6 address is present , it seems like it would be better to first prefer an address that is on a shared network instead of always taking the first one ( which does n’t mean anything in DNS ) . If you want others to use the same address you should prefer the lowest one or the highest one or something sortable instead of the first one which could be different depending on hashing in a cache . 
 Discussed and agreement was to find a simple alternate algorithm . 
 Closed by PR
Paragraph (version A):
An ICE agent that supports mDNS candidates MUST support the situation
where the hostname resolution results in more than one IP address.
In this case, the ICE agent MUST take exactly one of the resolved IP
addresses and ignore the others.  The ICE agent SHOULD use the first
IPv6 address resolved, if one exists, or the first IPv4 address, if
not.
Paragraph (version B):
An ICE agent SHOULD ignore candidates where the hostname resolution
returns more than one IP address.
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: 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 .
Paragraph (version A):
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.
Paragraph (version B):
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.
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: 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 . 
 tries to spell this out , referring back to mdns - ice - candidates . I do n'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
Paragraph (version A):
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.
Paragraph (version B):
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
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.
Paragraph (version B):
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.
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: PR for 
 In the section gather candidates , it says : " 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 . " We , maybe , should clarify this refers to a registered mDNS hostname as produce by this spec , not another ( possibly meaningful ) name created in some other context . 
 Makes sense as an editorial cleanup . 
 Fixed by
Paragraph (version A):
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 B):
Check whether the ICE agent has previously generated, registered,
and stored an mDNS hostname for this IP address as per Steps 3, 4,
and 6.  If it has, skip ahead to Step 7.
Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: PR of 
 Currently it contains : c = IN IP4 address / ttl Obviously , putting one of the candidate 's IP address there would defeat the purpose of use mDNS . Options : Can this be omitted ? Should it have a fake IP address of the right address family ? Should it be allowed to have an mDNS name ? 
 Just use the mDNS name . 
 If we run into issues , we could use 0.0.0.0:9 as we do when there are no candidates , but that starts to get complicated ( i.e. may require updates to other specs ) 
 mDNS name with IP4 ? 
 good point - should n't matter that much , but IP4 seems like the safest choice . 
 Agreed to use mDNS + IP4 . We 'll reevaluate if this causes problems . 
 Fixed by 
 We have observed an interop issue in the experimental deployment . Endpoints can fail to parse the SDP when the c= line contains a FQDN . This is the current solution . 
 Well , at least we thought of the solution already :)
Paragraph (version B):
The mDNS name of an mDNS candidate MUST be used in the connection-
address field of its candidate attribute.  When an mDNS candidate is
the default candidate, its mDNS name MUST be used in the connection-
address field of the SDP "c=" line.  Since an mDNS candidate also
conceals its address family, the "c=" line SHOULD use "IP4" in the
address-type field.