jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-rtcweb-ip-handling

Commentary: Sure - happy to add text of this sort if we think it would be valuable . OK . :-) OK . 
 When I say " local " here , I am referring to the fact that the IP address is local to the machine , rather than an address for a remote party . To avoid confusion , I probably could just omit the word altogether here . Regarding NATing , your observation is often correct , but  is becoming increasingly common . I could just clarify and say that overall IPv6 avoids the issue through use of 4941 addresses . 
 The most obvious case is a NAT64 scenario , where the IPv6 address is never seen by the outside world , and therefore exposing said address to the web site presents a potential leakage concern . This concern is significantly mitigated if the IPv6 address is a RFC4941 ephemeral address .
Private local IP addresses can also act as an identifier that allows
web applications running in isolated browsing contexts (e.g., normal
and private browsing) to learn that they are running on the same
device.  This could allow the application sessions to be correlated,
defeating some of the privacy protections provided by isolation.  It
should be noted that local addresses are just one potential mechanism
for this correlation and this is an area for further study.
Private IP addresses can also act as an identifier that allows web
applications running in isolated browsing contexts (e.g., normal and
private browsing) to learn that they are running on the same device.
This could allow the application sessions to be correlated, defeating
some of the privacy protections provided by isolation.  It should be
noted that private addresses are just one potential mechanism for
this correlation and this is an area for further study.
Draft: draft-ietf-rtcweb-ip-handling

Commentary: There is an implicit " where possible " here . The specific scenario is for two devices behind the same NAT who could communicate directly if only they knew each others ' addresses ; in this case , a direct connection should be possible , which implies that there needs to be some way for the two sides to share their machine addresses . Naturally , devices behind different NATs will not be able to do this . Noted .
By default, WebRTC should be able to negotiate direct peer-to-peer
connections between endpoints (i.e., without traversing a NAT or
relay server).  This ensures that applications that need true
peer-to-peer routing for bandwidth or latency reasons can operate
successfully.
By default, WebRTC should be able to negotiate direct peer-to-peer
connections between endpoints (i.e., without traversing a NAT or
relay server) when such connections are possible.  This ensures
that applications that need true peer-to-peer routing for
bandwidth or latency reasons can operate successfully.
Draft: draft-ietf-rtcweb-ip-handling

Commentary: I can add a reference to security - arch , e.g.
Mode 1 MUST NOT be used unless user consent has been provided.  The
details of this consent are left to the implementation; one potential
mechanism is to tie this consent to getUserMedia consent.
Alternatively, implementations can provide a specific mechanism to
obtain user consent.
Mode 1 MUST NOT be used unless user consent has been provided.  The
details of this consent are left to the implementation; one potential
mechanism is to tie this consent to getUserMedia (device permissions)
consent, described in I-D.ietf-rtcweb-security-arch, Section 6.2.
Alternatively, implementations can provide a specific mechanism to
obtain user consent.
Draft: draft-ietf-rtcweb-ip-handling

Commentary: Sounds good .
When trying to follow typical IP routing, the simplest approach is to
bind the sockets used for peer-to-peer connections to the wildcard
addresses (0.0.0.0 for IPv4, :: for IPv6), which allows the OS to
route WebRTC traffic the same way as it would HTTP traffic.  STUN and
TURN will work as usual, and host candidates can still be determined
as mentioned below.
When trying to follow typical IP routing, the simplest approach is to
bind() the sockets used for peer-to-peer connections to the wildcard
addresses (0.0.0.0 for IPv4, :: for IPv6), which allows the OS to
route WebRTC traffic the same way as it would HTTP traffic.  STUN and
TURN will work as usual, and host candidates can still be determined
as mentioned below.
Once a suitable remote IP has been determined, the implementation can
create a UDP socket, bind it to the appropriate wildcard address, and
tell it to connect to the remote IP.  Generally, this results in the
socket being assigned a local address based on the kernel routing
table, without sending any packets over the network.
Once a suitable remote IP has been determined, the implementation can
create a UDP socket, bind() it to the appropriate wildcard address,
and then connect() to the remote IP.  Generally, this results in the
socket being assigned a local address based on the kernel routing
table, without sending any packets over the network.
Draft: draft-ietf-rtcweb-ip-handling

Commentary: ( nit ) § 3 : Please expand " RTMFP " on first mention . ( nit ) § 5.2 : " Mode 1 MUST only be used when user consent has been provided " Please consider " ... MUST NOT be used unless user consent has been provided . " : It seems like the references for STUN and TURN should be normative .
Note also that these concerns predate WebRTC; Adobe Flash Player has
provided similar functionality since the introduction of RTMFP
RFC7016 in 2008.
Note also that these concerns predate WebRTC; Adobe Flash Player has
provided similar functionality since the introduction of Real-Time
Media Flow Protocol (RTMFP) support RFC7016 in 2008.
Mode 1 MUST only be used when user consent has been provided.  The
details of this consent are left to the implementation; one potential
mechanism is to tie this consent to getUserMedia consent.
Alternatively, implementations can provide a specific mechanism to
obtain user consent.
Mode 1 MUST NOT be used unless user consent has been provided.  The
details of this consent are left to the implementation; one potential
mechanism is to tie this consent to getUserMedia consent.
Alternatively, implementations can provide a specific mechanism to
obtain user consent.
Draft: draft-ietf-rtcweb-ip-handling

Commentary: Sure - happy to add text of this sort if we think it would be valuable . OK . :-) OK . 
 S 3 . That said , I could get behind switching ' will ' to ' can ' , as is used in S3 , category . S 6.2 . This seems like a good addition . 
 When I say " local " here , I am referring to the fact that the IP address is local to the machine , rather than an address for a remote party . To avoid confusion , I probably could just omit the word altogether here . Regarding NATing , your observation is often correct , but  is becoming increasingly common . I could just clarify and say that overall IPv6 avoids the issue through use of 4941 addresses . 
 The most obvious case is a NAT64 scenario , where the IPv6 address is never seen by the outside world , and therefore exposing said address to the web site presents a potential leakage concern . This concern is significantly mitigated if the IPv6 address is a RFC4941 ephemeral address .
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC2119 RFC8174 when, and only when, they appear in all capitals,
as shown here.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC8174 when, and only when, they appear in all capitals, as shown
here.
Draft: draft-ietf-rtcweb-ip-handling

Commentary: 8445 8174 Future documents , not future versions Fix normative refs 
 Sure - happy to add text of this sort if we think it would be valuable . OK . :-) OK . 
 LGTM
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.
In order to establish a peer-to-peer connection, WebRTC
implementations use Interactive Connectivity Establishment (ICE)
RFC5245, which attempts to discover multiple IP addresses using
techniques such as Session Traversal Utilities for NAT (STUN) RFC5389
and Traversal Using Relays around NAT (TURN) RFC5766, and then checks
the connectivity of each local-address-remote-address pair in order
to select the best one.  The addresses that are collected usually
consist of an endpoint's private physical/virtual addresses and its
public Internet addresses.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC2119 RFC8174 when, and only when, they appear in all capitals,
as shown here.
In order to establish a peer-to-peer connection, WebRTC
implementations use Interactive Connectivity Establishment (ICE)
RFC8445, which attempts to discover multiple IP addresses using
techniques such as Session Traversal Utilities for NAT (STUN) RFC5389
and Traversal Using Relays around NAT (TURN) RFC5766, and then checks
the connectivity of each local-address-remote-address pair in order
to select the best one.  The addresses that are collected usually
consist of an endpoint's private physical/virtual addresses and its
public Internet addresses.
Future versions of this document may define additional modes and/or
update the recommended default modes.
Future documents may define additional modes and/or update the
recommended default modes.