jiebi/TextFlow huggingface dataset:
Original text:
concentrates on specifying the protocols and subprotocols that are needed to specify the interactions over the network.  This memo uses the term "WebRTC" (note the case used) to refer to the overall effort consisting of both IETF and W3C efforts.

Reviewer comments:
Benoit submitted a DISCUSS related to management. It was discussed and adding the following text as the penultimate paragraph in s1 ought will resolve it: Operators should note that deployment of WebRTC will result in a change in the nature of signaling for real time media on the network, and may result in a shift in the kinds of devices used to create and consume such media. In the case of signaling, WebRTC session setup will typically occur over TLS-secured web technologies (such as WebSockets [RFC6455]) using application-specific protocols. Operational techniques that involve inserting network elements to interpret SDP -- either through endpoint cooperation [RFC3361] or through the transparent insertion of of SIP Application Level Gateways (ALGs) -- will not work with such signaling. In the case of networks using cooperative endpoints, the approaches defined in [RFC8155] may serve as a suitable replacement for [RFC3361]. The increase in browser-based communications may also lead to a shift away from dedicated real-time-communications hardware, such as SIP desk phones. This will diminish the efficacy of operational techniques that place dedicated real-time devices on their own network segment, address range, or VLAN for purposes such as applying traffic filtering and QoS. The markings described in [URL] may be appropriate replacements for such techniques.

Revised text:
concentrates on specifying the protocols and subprotocols that are needed to specify the interactions over the network. <ins> Operators should note that deployment of WebRTC will result in a change in the nature of signaling for real time media on the network, and may result in a shift in the kinds of devices used to create and consume such media.  In the case of signaling, WebRTC session setup will typically occur over TLS-secured web technologies using application-specific protocols.  Operational techniques that involve inserting network elements to interpret SDP -- either through endpoint cooperation RFC3361 or through the transparent insertion of SIP Application Level Gateways (ALGs) -- will not work with such signaling.  In the case of networks using cooperative endpoints, the approaches defined in RFC8155 may serve as a suitable replacement for RFC3361.  The increase in browser-based communications may also lead to a shift away from dedicated real-time-communications hardware, such as SIP desk phones.  This will diminish the efficacy of operational techniques that place dedicated real-time devices on their own network segment, address range, or VLAN for purposes such as applying traffic filtering and QoS.  Applying the markings described in I-D.ietf-tsvwg-rtcweb-qos may be appropriate replacements for such techniques. </ins> This memo uses the term "WebRTC" (note the case used) to refer to the overall effort consisting of both IETF and W3C efforts.
Original text:
other party is willing to accept communication at the base level of that specification, you can communicate successfully. <del> The alternative - that of having no mandatory to implement - does not </del>  mean that you cannot communicate, it merely means that in order to be part of the communications partnership, you have to implement the <del> standard "and then some" - that "and then some" usually being called a profile of some sort; in the version most antithetical to the </del>  Internet ethos, that "and then some" consists of having to use a specific vendor's product only.

Reviewer comments:
Ben noted is his comments: 2.3, last paragraph: The paragraph is a single, convoluted sentence that is hard to parse. (It's also a comma splice). Please consider breaking into multiple simpler sentences.
This text is gross, but the changes are fine.

Revised text:
other party is willing to accept communication at the base level of that specification, you can communicate successfully.  <ins> The alternative, that is having no mandatory to implement, does not </ins> mean that you cannot communicate, it merely means that in order to be part of the communications partnership, you have to implement the  <ins> standard "and then some".  The "and then some" is usually called a profile of some sort; in the version most antithetical to the </ins> Internet ethos, that "and then some" consists of having to use a specific vendor's product only.
Original text:
3. <del> The model of real-time support for browser-based applications does not assume that the browser will contain all the functions that need to be performed in order to have a function such as a telephone or a video conferencing unit; the vision is that the browser will have the functions that are needed for a Web application, working in conjunction with its backend servers, to implement these functions. </del>  This means that two vital interfaces need specification: The protocols that browsers use to talk to each other, without any

Reviewer comments:
Please double check this, but it did say "functions for ... function such as" so I changed the second function to application.
Ben had the following comment: 3, first paragraph: This is also convoluted and hard to parse.

Revised text:
3.  <ins> For browser-based applications, the model for real-time support does not assume that the browser will contain all the functions needed for an application such as a telephone or a video conference.  The vision is that the browser will have the functions needed for a Web application, working in conjunction with its backend servers, to implement these functions. </ins> This means that two vital interfaces need specification: The protocols that browsers use to talk to each other, without any
Original text:
protocol suite is intended to enable all the applications that are described as required scenarios in the use cases document RFC7478. <del> Other efforts, for instance the W3C WEBRTC, Web Applications and Device API working groups, focus on making standardized APIs and interfaces available, within or alongside the HTML5 effort, for those functions; this memo concentrates on specifying the protocols and subprotocols that are needed to specify the interactions that happen across the network. </del>  This memo uses the term "WebRTC" (note the case used) to refer to the overall effort consisting of both IETF and W3C efforts.

Reviewer comments:
Spencer had the following comment: This is a nit, but in this text, Other efforts, for instance the W3C WEBRTC, Web Applications and Device API working groups, focus on making standardized APIs and interfaces available, within or alongside the HTML5 effort, it would be nice to have the names here match what's on the W3C website. So, "Web Real-Time Communication", "Web Application Security", and "Device and Sensors", unless I'm guessing at the mapping wrong. It's also easy to read that text with "Web Applications and Device API" as a single working group, so using a comma after "Web Application Security" would be helpful.
LGTM with editorial

Revised text:
protocol suite is intended to enable all the applications that are described as required scenarios in the use cases document RFC7478.  <ins> Other efforts, for instance the W3C Web Real-Time Communications, Web Applications Security, and Device and Sensor working groups, focus on making standardized APIs and interfaces available, within or alongside the HTML5 effort, for those functions.  This memo concentrates on specifying the protocols and subprotocols that are needed to specify the interactions over the network. </ins> This memo uses the term "WebRTC" (note the case used) to refer to the overall effort consisting of both IETF and W3C efforts.
Original text:
The functionality groups that are needed in the browser can be specified, more or less from the bottom up, as: <del> Data transport: TCP, UDP and the means to securely set up </del>  connections between entities, as well as the functions for deciding when to send data: Congestion management, bandwidth estimation and so on.

Reviewer comments:
Mirja had the following comment: section 3: "Data transport: TCP, UDP and the means to securely set up connections between entities, as well as the functions for deciding when to send data: Congestion management, bandwidth estimation and so on." This seems to implicitly assume that only TCP or something encapsulated over UDP can be used. Even though that might be true, I assume this was not intentionally, maybe: NEW "Data transport: such as TCP or UDP and the means to securely set up connections between entities, as well as the functions for deciding when to send data: Congestion management, bandwidth estimation and so on."

Revised text:
The functionality groups that are needed in the browser can be specified, more or less from the bottom up, as:  <ins> Data transport: such as TCP, UDP and the means to securely set up </ins> connections between entities, as well as the functions for deciding when to send data: Congestion management, bandwidth estimation and so on.
Original text:
("low path") goes directly between the browsers, so it has to be conformant to the specifications of the WebRTC protocol suite; the signaling path ("high path") goes via servers that can modify, <del> translate or massage the signals as needed. </del>  If the two Web servers are operated by different entities, the inter- server signaling mechanism needs to be agreed upon, either by

Reviewer comments:
Mirja had the following comment/nit: massage the signals": not sure if "massage" is actually a meaningful word here…

Revised text:
("low path") goes directly between the browsers, so it has to be conformant to the specifications of the WebRTC protocol suite; the signaling path ("high path") goes via servers that can modify,  <ins> translate or manipulate the signals as needed. </ins> If the two Web servers are operated by different entities, the inter- server signaling mechanism needs to be agreed upon, either by
Original text:
servers implement Extensible Messaging and Presence Protocol (XMPP), XMPP could be used for communication between XMPP servers, with either a standardized signaling mechanism (e.g.  XMPP over WebSockets <del> or BOSH) or a proprietary signaling mechanism used between the application running in the browser and the web server. </del>  The choice of protocols for client-server and inter-server signalling, and definition of the translation between them, is

Reviewer comments:
Jingle and XMPP already had references by BOSH didn't so I added it.
Kathleen had the following comment: I had to look up jingle and BOSH, you may want to consider adding references to the XMPP specifications.

Revised text:
servers implement Extensible Messaging and Presence Protocol (XMPP), XMPP could be used for communication between XMPP servers, with either a standardized signaling mechanism (e.g.  XMPP over WebSockets  <ins> or BOSH XEP-0124 or a proprietary signaling mechanism used between the application running in the browser and the web server. </ins> The choice of protocols for client-server and inter-server signalling, and definition of the translation between them, is
Original text:
The following principles apply: The WebRTC media negotiations will be capable of representing the <del> same SDP offer/answer semantics that are used in SIP RFC3264, in </del>  such a way that it is possible to build a signaling gateway between SIP and the WebRTC media negotiation.

Reviewer comments:
Ben provided the following comment: s7, list item 1: The citiation to [3264] seems misplaced. It describes the offer/answer model, not SIP in general. I suggest moving the citation to after the word "semantics”.

Revised text:
The following principles apply: The WebRTC media negotiations will be capable of representing the  <ins> same SDP offer/answer semantics RFC3264 that are used in SIP, in </ins> such a way that it is possible to build a signaling gateway between SIP and the WebRTC media negotiation.
Original text:
intervening servers, and the APIs that are offered for a Javascript application to take advantage of the browser's functionality. <del> Note that HTTP and WebSockets are also offered to the Javascript </del>  application through browser APIs. As for all protocol and API specifications, there is no restriction

Reviewer comments:
LGMT
ekr provided the following comment for s3: I would say HTTP(S) in this diagram.

Revised text:
intervening servers, and the APIs that are offered for a Javascript application to take advantage of the browser's functionality.  <ins> Note that HTTPS and WebSockets are also offered to the Javascript </ins> application through browser APIs. As for all protocol and API specifications, there is no restriction
Original text:
Data transport: such as TCP, UDP and the means to securely set up connections between entities, as well as the functions for <del> deciding when to send data: Congestion management, bandwidth </del>  estimation and so on. <del> Data framing: RTP, SCTP and other data formats that serve as containers, and their functions for data confidentiality and </del>  integrity. Data formats: Codec specifications, format specifications and formats, a way to describe them, a session description, is needed. Connection management: Setting up connections, agreeing on data <del> formats, changing data formats during the duration of a call; SIP and Jingle/XMPP belong in this category. </del>  Presentation and control: What needs to happen in order to ensure that interactions behave in a non-surprising manner.  This can

Reviewer comments:
ekr had the following comment: You should probably list DTLS, SCTP, and SDP in this section. It's not like we haven't decided we need them.
LGTM with nits

Revised text:
Data transport: such as TCP, UDP and the means to securely set up connections between entities, as well as the functions for  <ins> deciding when to send data: congestion management, bandwidth </ins> estimation and so on.  <ins> Data framing: RTP, SCTP, DTLS, and other data formats that serve as containers, and their functions for data confidentiality and </ins> integrity. Data formats: Codec specifications, format specifications and formats, a way to describe them, a session description, is needed. Connection management: Setting up connections, agreeing on data  <ins> formats, changing data formats during the duration of a call; SDP, SIP, and Jingle/XMPP belong in this category. </ins> Presentation and control: What needs to happen in order to ensure that interactions behave in a non-surprising manner.  This can
Original text:
Transports for WebRTC <del> draft-ietf-rtcweb-transports-11 </del>  Abstract exposing addresses to the application or using them in ICE.  This is consistent with the default policy described in RFC6724.  3.4. The primary mechanism to deal with middle boxes is ICE, which is an All packets on one TCP connection, no matter what it carries, MUST use a single DSCP code point. <del> More advice on the use of DSCP code points with RTP is given in I- D.ietf-dart-dscp-rtp. </del>  There exist a number of schemes for achieving quality of service that do not depend solely on DSCP code points.  Some of these schemes

Reviewer comments:
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 don't make sense to try?
As documented here: URL and here: URL 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)

Revised text:
Transports for WebRTC  <ins> draft-ietf-rtcweb-transports-12 </ins> Abstract exposing addresses to the application or using them in ICE.  This is consistent with the default policy described in RFC6724. <ins> If some of the temporary IPv6 addresses, but not all, are marked deprecated, the client SHOULD discard the deprecated addresses. </ins> 3.4. The primary mechanism to deal with middle boxes is ICE, which is an All packets on one TCP connection, no matter what it carries, MUST use a single DSCP code point.  <ins> More advice on the use of DSCP code points with RTP is given in RFC7657. </ins> There exist a number of schemes for achieving quality of service that do not depend solely on DSCP code points.  Some of these schemes
Original text:
(300 Try Alternate) MUST be supported. The WebRTC implementation MAY support accessing the Internet through <del> an HTTP proxy.  If it does so, it MUST support the "ALPN" header as </del>  specified in RFC7639, and proxy authentication as described in Section 4.3.6 of RFC7231 and RFC7235 MUST also be supported.

Reviewer comments:
Fixes URL
From Cullen Jennings, 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.

Revised text:
(300 Try Alternate) MUST be supported. The WebRTC implementation MAY support accessing the Internet through  <ins> an HTTP proxy.  If it does so, it MUST include the "ALPN" header as </ins> specified in RFC7639, and proxy authentication as described in Section 4.3.6 of RFC7231 and RFC7235 MUST also be supported.
Original text:
Transports for WebRTC <del> draft-ietf-rtcweb-transports-08 </del>  Abstract The setup protocol for WebRTC data channels described in I-D.ietf- rtcweb-data-protocol MUST be supported.  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

Reviewer comments:
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 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.

Revised text:
Transports for WebRTC  <ins> draft-ietf-rtcweb-transports-09 </ins> Abstract The setup protocol for WebRTC data channels described in I-D.ietf- rtcweb-data-protocol MUST be supported. <ins> 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. </ins> 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
Original text:
Transports for WebRTC <del> draft-ietf-rtcweb-transports-13 </del>  Abstract specification does not describe prioritization between the RTP streams that come from a single "media source".  A "data flow" is the outgoing data on a single WebRTC data channel. The priority associated with a media flow or data flow is classified

Reviewer comments:
Notes that there's no way to mark a stream as non-interactive.
From discussion with DSCP folks:
after
Discussion people: Cc: EMAIL; EMAIL; EMAIL; EMAIL; Black, David
I chose to integrate this minus the G.1010 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)

Revised text:
Transports for WebRTC  <ins> draft-ietf-rtcweb-transports-14 </ins> Abstract specification does not describe prioritization between the RTP streams that come from a single "media source". <ins> 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. </ins> A "data flow" is the outgoing data on a single WebRTC data channel. The priority associated with a media flow or data flow is classified
Original text:
WebRTC implementations MUST support multiplexing of DTLS and RTP over the same port pair, as described in the DTLS-SRTP specification <del> RFC5764, section 5.1.2.  All application layer protocol payloads over this DTLS connection are SCTP packets. </del>  Protocol identification MUST be supplied as part of the DTLS handshake, as specified in I-D.ietf-rtcweb-alpn.

Reviewer comments:
NAME please review
From Magnus Westerlund in IETF LC: Section 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: URL 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.

Revised text:
WebRTC implementations MUST support multiplexing of DTLS and RTP over the same port pair, as described in the DTLS-SRTP specification  <ins> 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. </ins> Protocol identification MUST be supplied as part of the DTLS handshake, as specified in I-D.ietf-rtcweb-alpn.