jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: rtcweb-transports

Commentary: Also do reformatting ( xxe equivalent of tidy ) . 
 From    IESG comments :
ICE - Interactive Connectivity Establishment,
Sending data over multiple 5-tuples is not supported.
Sending data channel data over multiple 5-tuples is not supported.
Draft: rtcweb-transports

Commentary: From    review : 
 Second point is fixed by . I 'm not sure the third point is an improvement . 
 SSL is used exactly once , as part of the acronym " TURN / SSL " . This is also the first mention of TURN , but the second was much more convenient to attach the expansion to . Given that it was so awkward to attach them , I included a new section listing the " used protocols " instead .
TCP RFC0793.  This is used for HTTP/WebSockets, as well as for
TURN/SSL and ICE-TCP.
TCP RFC0793.  This is used for HTTP/WebSockets, as well as for
TURN/TLS and ICE-TCP.
TURN - Traversal Using Relays Around NAT,
STUN - Session Traversal Utilities for NAT,
TLS - Trasnsport Layer Security,
DTLS - Datagram Transport Layer Security, RFC6347.
Draft: rtcweb-transports

Commentary: please review 
 From Magnus Westerlund in IETF LC : 3.5 : WebRTC implementations MUST support multiplexing of DTLS and RTP over the same port pair , as described in the DTLS - SRTP specification [ RFC5764 ] , section 5.1.2 . All application layer protocol payloads over this DTLS connection are SCTP packets . This text should reference also the update to RFC5764 : That document is publication requested so even as normative reference it will hopefully have minimal impact on the publication progress of this document . 
 Looking at -mux - fixes , I think this is worth including . Adding .
WebRTC implementations MUST support multiplexing of DTLS and RTP over
the same port pair, as described in the DTLS-SRTP specification
RFC5764, section 5.1.2.  All application layer protocol payloads over
this DTLS connection are SCTP packets.
WebRTC implementations MUST support multiplexing of DTLS and RTP over
the same port pair, as described in the DTLS-SRTP specification
RFC5764, section 5.1.2, with clarifications in I-D.ietf-avtcore-
rfc5764-mux-fixes.  All application layer protocol payloads over this
DTLS connection are SCTP packets.
Draft: rtcweb-transports

Commentary: please review 
 From Magnus Westerlund in IETF LC review : 3.4 : If TCP connections are used , RTP framing according to [  ] MUST be used , both for the RTP packets and for the DTLS packets used to carry data channels . I think the last part of this sentence , unintentionally excludes the DTLS handshake packets . The ICE TCP spec also specifies that the STUN connectivity checks are using  framing . Thus , I think some reformulation of this sentence is in order .
If TCP connections are used, RTP framing according to RFC4571 MUST be
used, both for the RTP packets and for the DTLS packets used to carry
data channels.
If TCP connections are used, RTP framing according to RFC4571 MUST be
used for all packets.  This includes the RTP packets, DTLS packets
used to carry data channels, and STUN connectivity check packets.
Draft: rtcweb-transports

Commentary: reformulated the TCP point , addressed security with a reference to -qos . 
 From    review : 
 Second point is fixed by . I 'm not sure the third point is an improvement . 
 SSL is used exactly once , as part of the acronym " TURN / SSL " . This is also the first mention of TURN , but the second was much more convenient to attach the expansion to . Given that it was so awkward to attach them , I included a new section listing the " used protocols " instead . 
 From Magnus Westerlund in IETF LC : 8.1 : [ I - D.martinsen - mmusic - ice - dualstack - fairness ]  , P. , Reddy , T. , and   , " ICE IPv4 / IPv6 Dual Stack Fairness " , draft - martinsen - mmusic - ice- dualstack - fairness-02 ( work in progress ) , February 2015 . Can be updated as this is now an WG item in ICE . 
 Updated in 
 Fixed by 
 I have reviewed this document in preparation for IETF last call . It is in good shape and I have requested the last call . While the last call is ongoing , I would like to double - check that this document ( particularly Section 4 ) raises no new security considerations that should be documented in Section 6 . I 'm wondering if there are scenarios where a malicious application could try to game the priority scheme to some ill effect ? draft - ietf - tsvwg - rtcweb - qos talks a bit about this , so I 'm wondering if anything needs to be said here . And I found a couple of nits to be resolved together with any LC comments : Sec 3.2 - Please update the citation to point to draft - ietf - mmusic - ice - dualstack - fairness-02 . Sec 3.4 - " Third , using TCP only between the endpoint and its relay may result in less issues with TCP in regards to real - time constraints , e.g. due to head of line blocking . " This is awkwardly phrased . I would suggest something like " Third , using TCP between the client 's TURN server and its peer may result in more performance problems ( due to head - of - line blocking ) than using UDP . " And one bit I left out — if text is to be to reference draft - ietf - rtcweb - return , that should be done together with addressing nits and LC comments . 
 There seems no consensus to add RETURN , so I 'm skipping this for now .
When TURN is used, and the TURN server has IPv4 or IPv6 connectivity
to the peer or its TURN server, candidates of the appropriate types
MUST be supported.  The "Happy Eyeballs" specification for ICE I-
D.martinsen-mmusic-ice-dualstack-fairness SHOULD be supported.
When TURN is used, and the TURN server has IPv4 or IPv6 connectivity
to the peer or the peer's TURN server, candidates of the appropriate
types MUST be supported.  The "Happy Eyeballs" specification for ICE
I-D.ietf-mmusic-ice-dualstack-fairness SHOULD be supported.
Third, using TCP only between the endpoint and its relay may result
in less issues with TCP in regards to real-time constraints, e.g. due
to head of line blocking.
Third, using TCP between the client's TURN server and the peer may
result in more performance problems than using UDP, e.g. due to head
of line blocking.
RTCWEB security considerations are enumerated in I-D.ietf-rtcweb-
security.
Draft: rtcweb-transports

Commentary: Notes that there 's no way to mark a stream as non - interactive . 
 From discussion with DSCP folks : 
 after 
 Discussion people : Cc : draft - ietf - tsvwg - rtcweb- ; tsvwg- ; rtcweb- ; ; Black ,  
 I chose to integrate this minus the  reference , since I did not know how to get that reference in using XML2RFC markup , and the reference to 4594 already covers it . 
 Fixed in ( version -14 )
All media flows in WebRTC are assumed to be interactive, as defined
in RFC4594; there is no browser API support for indicating whether
media is interactive or non-interactive.
Draft: rtcweb-transports

Commentary: Fixes 
 From   , RTCWEB mailing list Feb 3 2016 : I think we need to make the ALPN a bit more explicit . We agreed to include the ALPN header so that a proxy knows it might receive video packet rates tunnelled across it . However the text on this is not 100 % clear . Right now it says If it does so , it MUST support the " ALPN " header as specified in [ RFC7639 ] , But some people have posted out including this header is optional in 7639 so there might be some ubiquity here about what is meant . I think we should change the word “ support ” to “ include ” to make it clear this needs to be sent to the proxy so that it would read specified in [ RFC7639 ] , I believe that correctly reflects what we intended on this . There is no requirement for the proxy to understand or do anything with this header . Old proxies will just ignore it and cary on as if it was not there . 
 Fixed in version -10 . 
 Seems " support " never got changed to " include " , so reopening issue .
The WebRTC implementation MAY support accessing the Internet through
an HTTP proxy.  If it does so, it MUST support the "ALPN" header as
specified in RFC7639, and proxy authentication as described in
Section 4.3.6 of RFC7231 and RFC7235 MUST also be supported.
The WebRTC implementation MAY support accessing the Internet through
an HTTP proxy.  If it does so, it MUST include the "ALPN" header as
specified in RFC7639, and proxy authentication as described in
Section 4.3.6 of RFC7231 and RFC7235 MUST also be supported.
Draft: rtcweb-transports

Commentary: o Added a SHOULD NOT about using deprecated temporary IPv6 addresses . o Updated draft - ietf - dart - dscp - rtp reference to RFC 7657 
 Some systems keep old IPv6 addresses around even when changing to new for privacy . How should we avoid trying the ones that do n't make sense to try ? 
 As documented here : and here : it appears that the implementers claim everything is working as designed on systems which accumulate several temporary deprecated IPv6 addresses . My assumption here is that using deprecated temp addresses as ICE candidates ( additionally to the non deprecated temporary address ) is not going to increase the likeliness of establishing a connection . So adding these additional ICE candidates only causes extra over head . Therefore adding a warning / clarification statement for implementers to avoid deprecated temporary IPv6 addresses ( in case there is usable non - deprecated temporary IPv6 address available ) seem appropriate . 
 Adding warning in -12 : " If some of the temporary IPv6 addresses , but not all , are marked deprecated , the client SHOULD discard the deprecated addresses . " 
 Sounds good to me . 
 Addressed in ( version -12 )
If some of the temporary IPv6 addresses, but not all, are marked
deprecated, the client SHOULD discard the deprecated addresses.
More advice on the use of DSCP code points with RTP is given in I-
D.ietf-dart-dscp-rtp.
More advice on the use of DSCP code points with RTP is given in
RFC7657.
Draft: rtcweb-transports

Commentary: As described in 
 In the Dallas presentation on “ transports ” you stated that the reference to proxy authentication would be restored ( See ) but it does not seem to have happened . This is an oversight . ( Noted by   )
The WebRTC implementation MAY support accessing the Internet through
an HTTP proxy.  If it does so, it MUST support the "connect" header
as specified in I-D.ietf-httpbis-tunnel-protocol.
The WebRTC implementation MAY support accessing the Internet through
an HTTP proxy.  If it does so, it MUST support the "connect" header
as specified in I-D.ietf-httpbis-tunnel-protocol, and proxy
authentication as described in Section 4.3.6 of RFC7231 and RFC7235
MUST also be supported.
Draft: rtcweb-transports

Commentary: LGTM with comment above . 
 I think we should just refer people to 5763 , S 6.7.1 : Interactive Connectivity Establishment ( ICE ) , as specified in [ RFC5245 ] , provides a methodology of allowing participants in multimedia sessions to verify mutual connectivity . When ICE is being used , the ICE connectivity checks are performed before the DTLS handshake begins . Note that if aggressive nomination mode is used , multiple candidate pairs may be marked valid before ICE finally converges on a single candidate pair . Implementations MUST treat all ICE candidate pairs associated with a single component as part of the same DTLS association . Thus , there will be only one DTLS handshake even if there are multiple valid candidate pairs . Note that this may mean adjusting the endpoint IP addresses if the selected candidate pair shifts , just as if the DTLS packets were an ordinary media stream . Specifically , I think we should say : Note : DTLS - SRTP as defined in < xref target="RFC5763"/defines how DTLS interacts with ICE in Section 6.7.1 . As indicated therein , implementations MUST treat all ICE candidate pairs associated with a single component as part of the same DTLS association . Thus , there will be only one DTLS handshake even if there are multiple valid candidate pairs . 
 Rephrased according to Justin 's suggestion .
Note: DTLS-SRTP as defined in RFC5764 section 6.7.1 defines the
interaction between DTLS and ICE ( RFC5245).  The effect of this
specification is that all ICE candidate pairs associated with a
single component are part of the same DTLS association.  Thus, there
will only be one DTLS handshake even if there are multiple valid
candidate pairs.