jiebi/TextFlow huggingface dataset:
Original text:
than potentially excluding content, users, or uses of their service.  At all levels of the network hierarchy, the filtration mechanisms used to detect undesirable traffic are essentially the same: a censor sniffs transmitting packets and identifies undesirable content, and

Reviewer comments:
From Stephane:
Shouldn't the CA / cert hierarchy be a point of control? For example, KZ is requiring users to install their CA, to allow them to MITM all traffic: URL Another example of CA abuse is ROA whacking, RPKI manipulation, etc.: URL
Also got this feedback from Will Scott:

Revised text:
than potentially excluding content, users, or uses of their service. <ins> Certificate Authorities: Authorities that issue cryptographically secured resources can be a significant point of control. Certificate Authorities that issue certificates to domain holders for TLS/HTTPS or Regional/Local Internet Registries that issue Route Origination Authorizations to BGP operators can be forced to issue rogue certificates that may allow compromises in confidentiatlity guarantees - allowing censorship software to engage in identification and interference where not possible before - or integrity degrees - allowing, for example, adversarial routing of traffic. </ins> At all levels of the network hierarchy, the filtration mechanisms used to detect undesirable traffic are essentially the same: a censor sniffs transmitting packets and identifies undesirable content, and
Original text:
domain all other DNS servers will be unable to properly forward and cache the site.  Domain name registration is only really a risk where undesirable content is hosted on TLD controlled by the censoring <del> country, such as .cn or .ru Anderson-2011. </del>  6.3.

Reviewer comments:
From Stephane:
Shouldn't the CA / cert hierarchy be a point of control? For example, KZ is requiring users to install their CA, to allow them to MITM all traffic: URL Another example of CA abuse is ROA whacking, RPKI manipulation, etc.: URL
Also got this feedback from Will Scott:

Revised text:
domain all other DNS servers will be unable to properly forward and cache the site.  Domain name registration is only really a risk where undesirable content is hosted on TLD controlled by the censoring  <ins> country, such as .cn or .ru Anderson-2011 or where legal processes in countries like the United States result in domain name seizures and/ or DNS redirection by the government Kopel-2013. </ins> 6.3.
Original text:
Changed the registry policy to: <del> Updated the "Reference" to also refer to this document. </del>  See expert-pool for additional information about the designated expert pool.

Reviewer comments:
Tweaks to add the D values, explanations about D, etc.
We might want to check that the subsequent registries all have an appropriate value in the column.

Revised text:
Changed the registry policy to:  <ins> Updated the "Reference" to refer to this document instead of RFC8447. </ins> See expert-pool for additional information about the designated expert pool.
Original text:
Add a "Recommended" column with the contents as listed below. This table has been generated by marking Standards Track RFCs as <del> "Y" and all others as "N".  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126. IESG Approval is REQUIRED for a Y->N transition. </del>  IANA [SHALL update/has added] the following notes: The extensions added by I-D.ietf-tls-rfc8446bis are omitted from the <del> above table; additionally, token_binding is omitted, since RFC8472 specifies the value of the "Recommended" column as for this extension. </del>  I-D.ietf-tls-rfc8446bis also uses the TLS ExtensionType Values registry originally created in RFC4366.  The following text is from

Reviewer comments:
Tweaks to add the D values, explanations about D, etc.
We might want to check that the subsequent registries all have an appropriate value in the column.

Revised text:
Add a "Recommended" column with the contents as listed below. This table has been generated by marking Standards Track RFCs as  <ins> "Y", "truncated_hmac" (4) and "connection_id (deprecated)" (53) as "D", and all others as "N".  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N, Y->D, and D->Y|N transitions. </ins> IANA [SHALL update/has added] the following notes: The extensions added by I-D.ietf-tls-rfc8446bis are omitted from the  <ins> above table.  Likewise, extensions defined after RFC8447 are also not listed in the table as those RFCs specify the value of the extension's "Recommended"; extensions points defined after RFC8447 include token_binding, compress_certificate, record_size_limit, pwd_protect, pwd_clear, password_salt, ticket_pinning, tls_cert_with_extern_psk, delegated_credentials, supported_ekt_ciphers, connection_id, external_id_hash, external_session_id, quic_transport_parameters, ticket_request, and dnssec_chain. </ins> I-D.ietf-tls-rfc8446bis also uses the TLS ExtensionType Values registry originally created in RFC4366.  The following text is from
Original text:
gateway to convert between the signaling on the web side to the SIP signaling may be needed. <del> When a new codec is specified, and the SDP for the new codec is specified in the MMUSIC WG, no other standardization should be required for it to be possible to use that in the web browsers. Adding new codecs which might have new SDP parameters should not change the APIs between the browser and Javascript application. As soon as the browsers support the new codecs, old applications written before the codecs were specified should automatically be able to use the new codecs where appropriate with no changes to the JS applications. </del>  The particular choices made for WebRTC, and their implications for the API offered by a browser implementing WebRTC, are described in I-

Reviewer comments:
Tweaks to future proof document.
Spencer had the following comment: I found the reference to MMUSIC WG in When a new codec is specified, and the SDP for the new codec is specified in the MMUSIC WG, no other standardization should be required for it to be possible to use that in the web browsers. to be odd. MMUSIC may be around forever, but this work might be refactored at some point in the future. Is the point that When SDP for a new codec is specified, no other standardization should be required for it to be used in the web browsers. Or is there another way to say this? I'm also wondering if the statement is true for any WebRTC endpoint, not just browsers.

Revised text:
gateway to convert between the signaling on the web side to the SIP signaling may be needed.  <ins> When an SDP for a new codec is specified, no other standardization should be required for it to be possible to use that in the web browsers.  Adding new codecs which might have new SDP parameters should not change the APIs between the browser and Javascript application.  As soon as the browsers support the new codecs, old applications written before the codecs were specified should automatically be able to use the new codecs where appropriate with no changes to the JS applications. </ins> The particular choices made for WebRTC, and their implications for the API offered by a browser implementing WebRTC, are described in I-
Original text:
elements described. TCP RFC0793.  This is used for HTTP/WebSockets, as well as for <del> TURN/SSL and ICE-TCP. </del>  For both protocols, IPv4 and IPv6 support is assumed.

Reviewer comments:
From Ben Campbell's 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.

Revised text:
elements described. TCP RFC0793.  This is used for HTTP/WebSockets, as well as for  <ins> TURN/TLS and ICE-TCP. </ins> For both protocols, IPv4 and IPv6 support is assumed.
Original text:
This specification does not assume that the implementation will have access to ICMP or raw IP.  3.2. Web applications running in a WebRTC browser MUST be able to utilize

Reviewer comments:
From Ben Campbell's 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.

Revised text:
This specification does not assume that the implementation will have access to ICMP or raw IP. <ins> The following protocols may be used, but can be implemented by a WebRTC endpoint, and are therefore not defined as "system-provided interfaces": TURN - Traversal Using Relays Around NAT, STUN - Session Traversal Utilities for NAT, ICE - Interactive Connectivity Establishment, RFC5245 TLS - Trasnsport Layer Security, DTLS - Datagram Transport Layer Security, RFC6347. </ins> 3.2. Web applications running in a WebRTC browser MUST be able to utilize
Original text:
The WebRTC implementation MAY support accessing the Internet through an HTTP proxy.  If it does so, it MUST support the "connect" header <del> as specified in I-D.ietf-httpbis-tunnel-protocol. </del>  3.5.

Reviewer comments:
As described in URL
In the Dallas presentation on “transports” you stated that the reference to proxy authentication would be restored (See URL) but it does not seem to have happened. This is an oversight. (Noted by Andy Hutton)

Revised text:
The WebRTC implementation MAY support accessing the Internet through an HTTP proxy.  If it does so, it MUST support the "connect" header  <ins> 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. </ins> 3.5.
Original text:
4. <del> This section describes a typical RTCWeb session and shows how the </del>  various security elements interact and what guarantees are provided to the user.  The example in this section is a "best case" scenario in which we provide the maximal amount of user authentication and

Reviewer comments:
I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.

Revised text:
4.  <ins> This section describes a typical WebRTC session and shows how the </ins> various security elements interact and what guarantees are provided to the user.  The example in this section is a "best case" scenario in which we provide the maximal amount of user authentication and
Original text:
the calling service via HTTPS and so know the origin with some level of confidence.  They also have accounts with some identity provider. This sort of identity service is becoming increasingly common in the <del> Web environment in technologies such (BrowserID, Federated Google Login, Facebook Connect, OAuth, OpenID, WebFinger), and is often provided as a side effect service of a user's ordinary accounts with some service.  In this example, we show Alice and Bob using a </del>  separate identity service, though the identity service may be the same entity as the calling service or there may be no identity service at all.

Reviewer comments:
I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.

Revised text:
the calling service via HTTPS and so know the origin with some level of confidence.  They also have accounts with some identity provider. This sort of identity service is becoming increasingly common in the  <ins> Web environment (with technologies such as BrowserID, Federated Google Login, Facebook Connect, OAuth, OpenID, WebFinger), and is often provided as a side effect service of a user's ordinary accounts with some service.  In this example, we show Alice and Bob using a </ins> separate identity service, though the identity service may be the same entity as the calling service or there may be no identity service at all.
Original text:
freshness", i.e., allowing Alice to verify that Bob is still prepared to receive her communications so that Alice does not continue to send large traffic volumes to entities which went abruptly offline.  ICE <del> specifies periodic STUN keepalizes but only if media is not flowing. Because the consent issue is more difficult here, we require RTCWeb </del>  implementations to periodically send keepalives.  As described in Section 5.3, these keepalives MUST be based on the consent freshness mechanism specified in I-D.muthu-behave-consent-freshness.  If a

Reviewer comments:
I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.

Revised text:
freshness", i.e., allowing Alice to verify that Bob is still prepared to receive her communications so that Alice does not continue to send large traffic volumes to entities which went abruptly offline.  ICE  <ins> specifies periodic STUN keepalives but only if media is not flowing. Because the consent issue is more difficult here, we require WebRTC </ins> implementations to periodically send keepalives.  As described in Section 5.3, these keepalives MUST be based on the consent freshness mechanism specified in I-D.muthu-behave-consent-freshness.  If a
Original text:
NOT be permitted to control the local ufrag and password, though it of course knows it. <del> While continuing consent is required, that ICE RFC5245; Section 10 keepalives STUN Binding Indications are one-way and therefore not sufficient.  The current WG consensus is to use ICE Binding Requests for continuing consent freshness.  ICE already requires that implementations respond to such requests, so this approach is maximally compatible.  A separate document will profile the ICE timers to be used; see I-D.muthu-behave-consent-freshness. </del>  5.4.

Reviewer comments:
I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.

Revised text:
NOT be permitted to control the local ufrag and password, though it of course knows it.  <ins> While continuing consent is required, the ICE RFC5245; Section 10 keepalives use STUN Binding Indications which are one-way and therefore not sufficient.  The current WG consensus is to use ICE Binding Requests for continuing consent freshness.  ICE already requires that implementations respond to such requests, so this approach is maximally compatible.  A separate document will profile the ICE timers to be used; see I-D.muthu-behave-consent-freshness. </ins> 5.4.
Original text:
5.6. In a number of cases, it is desirable for the endpoint (i.e., the <del> browser) to be able to directly identity the endpoint on the other side without trusting only the signaling service to which they are </del>  connected.  For instance, users may be making a call via a federated system where they wish to get direct authentication of the other side.  Alternately, they may be making a call on a site which they

Reviewer comments:
I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.

Revised text:
5.6. In a number of cases, it is desirable for the endpoint (i.e., the  <ins> browser) to be able to directly identify the endpoint on the other side without trusting the signaling service to which they are </ins> connected.  For instance, users may be making a call via a federated system where they wish to get direct authentication of the other side.  Alternately, they may be making a call on a site which they
Original text:
identity on a site they do trust (such as a social network.) Recently, a number of Web-based identity technologies (OAuth, <del> BrowserID, Facebook Connect), etc. have been developed.  While the </del>  details vary, what these technologies share is that they have a Web- based (i.e., HTTP/HTTPS) identity provider which attests to your identity.  For instance, if I have an account at example.org, I could

Reviewer comments:
I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.

Revised text:
identity on a site they do trust (such as a social network.) Recently, a number of Web-based identity technologies (OAuth,  <ins> BrowserID, Facebook Connect etc.) have been developed.  While the </ins> details vary, what these technologies share is that they have a Web- based (i.e., HTTP/HTTPS) identity provider which attests to your identity.  For instance, if I have an account at example.org, I could
Original text:
The precise information from the signaling message that must be cryptographically bound to the user's identity and a mechanism for <del> carrying assertions in JSEP messages. sec.jsep-binding </del>  The interface to the IdP. sec.protocol-details specifies a specific protocol mechanism which allows the use of any identity

Reviewer comments:
I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.

Revised text:
The precise information from the signaling message that must be cryptographically bound to the user's identity and a mechanism for  <ins> carrying assertions in JSEP messages.  This is specified in sec.jsep-binding. </ins> The interface to the IdP. sec.protocol-details specifies a specific protocol mechanism which allows the use of any identity
Original text:
The specific IdP protocol which the IdP is using.  This is a completely opaque IdP-specific string, but allows an IdP to <del> implement two protocols in parallel.  This value may be the empty string. </del>  Each IdP MUST serve its initial entry page (i.e., the one loaded by the IdP proxy) from a RFC5785.  The well-known URI for an IdP proxy

Reviewer comments:
I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.

Revised text:
The specific IdP protocol which the IdP is using.  This is a completely opaque IdP-specific string, but allows an IdP to  <ins> implement multiple protocols in parallel.  This value may be the empty string. </ins> Each IdP MUST serve its initial entry page (i.e., the one loaded by the IdP proxy) from a RFC5785.  The well-known URI for an IdP proxy
Original text:
who have not implemented WebRTC at all, WebRTC implementations need to be more careful. <del> Consider the case of a call center which accepts calls via RTCWeb. </del>  An attacker proxies the call center's front-end and arranges for multiple clients to initiate calls to the call center.  Note that this requires user consent in many cases but because the data channel

Reviewer comments:
I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.

Revised text:
who have not implemented WebRTC at all, WebRTC implementations need to be more careful.  <ins> Consider the case of a call center which accepts calls via WebRTC. </ins> An attacker proxies the call center's front-end and arranges for multiple clients to initiate calls to the call center.  Note that this requires user consent in many cases but because the data channel
Original text:
6.4.1. Fundamentally, the IdP proxy is just a piece of HTML and JS loaded by <del> the browser, so nothing stops a Web attacker o from creating their own IFRAME, loading the IdP proxy HTML/JS, and requesting a signature.  In order to prevent this attack, we require that all signatures be tied to a specific origin ("rtcweb://...") which cannot be produced by content JavaScript.  Thus, while an attacker can instantiate the IdP proxy, they cannot send messages from an appropriate origin and so cannot create acceptable assertions.  I.e., the assertion request must have come from the browser.  This origin check is enforced on the relying party side, not on the authenticating party side.  The reason for this is to take the burden of knowing which origins are valid off of the IdP, thus making this mechanism extensible to other applications besides WebRTC.  The IdP simply needs to gather the origin information (from the posted message) and attach it to the assertion. </del>  Note that although this origin check is enforced on the RP side and not at the IdP, it is absolutely imperative that it be done.  The

Reviewer comments:
I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.

Revised text:
6.4.1. Fundamentally, the IdP proxy is just a piece of HTML and JS loaded by  <ins> the browser, so nothing stops a Web attacker from creating their own IFRAME, loading the IdP proxy HTML/JS, and requesting a signature. In order to prevent this attack, we require that all signatures be tied to a specific origin ("rtcweb://...") which cannot be produced by content JavaScript.  Thus, while an attacker can instantiate the IdP proxy, they cannot send messages from an appropriate origin and so cannot create acceptable assertions.  I.e., the assertion request must have come from the browser.  This origin check is enforced on the relying party side, not on the authenticating party side.  The reason for this is to take the burden of knowing which origins are valid off of the IdP, thus making this mechanism extensible to other applications besides WebRTC.  The IdP simply needs to gather the origin information (from the posted message) and attach it to the assertion. </ins> Note that although this origin check is enforced on the RP side and not at the IdP, it is absolutely imperative that it be done.  The
Original text:
Abstract <del> The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for enabling real-time communications within user-agents using web technologies (commonly called "WebRTC").  This document defines the security architecture for WebRTC. </del>  1.

Reviewer comments:
Pretty sure we'll get a GEN-ART reviewing say to not refer to the WG by name because it will get closed at some point. I basically stole the intro from overview and modified it slightly.

Revised text:
Abstract  <ins> This document defines the security architecture for WebRTC, a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". </ins> 1.
Original text:
All SenML Records in a Pack MUST have the same version number.  This is typically done by adding a Base Version field to only the first <del> Record in the Pack. </del>  Systems reading one of the objects MUST check for the Version field. If this value is a version number larger than the version which the

Reviewer comments:
As per Adam's comment, clarify that only the element() scheme of the XPointer Framework is supported (as that is the one that is required by RFC 7303).
LGTM

Revised text:
All SenML Records in a Pack MUST have the same version number.  This is typically done by adding a Base Version field to only the first  <ins> Record in the Pack, or by using the default value. </ins> Systems reading one of the objects MUST check for the Version field. If this value is a version number larger than the version which the
Original text:
4.5.2. If the Record has no Unit, the Base Unit is used as the Unit.  Having <del> no Unit and no Base Unit is allowed. </del>  4.5.3.

Reviewer comments:
As per Adam's comment, clarify that only the element() scheme of the XPointer Framework is supported (as that is the one that is required by RFC 7303).
LGTM

Revised text:
4.5.2. If the Record has no Unit, the Base Unit is used as the Unit.  Having  <ins> no Unit and no Base Unit is allowed; any information that may be required about units applicable to the value then needs to be provided by the application context. </ins> 4.5.3.