jiebi/TextFlow huggingface dataset:
Original text:
Implementations MUST NOT implement DTLS renegotiation and MUST reject it with a "no_renegotiation" alert if offered.  The API MUST generate a new authentication key pair for every new call by default.  This is intended to allow for unlinkability.

Reviewer comments:
Address . Wasn't sure if we should reject the connection. NAME PTAL
This was entirely motivated by ekr's issue. Just trying to move this one along.
We should prohibit false start.
Why? (Sean in the PT said "because of ekr's issue", but I can't see what the issue is here)
Because the DTLS-SRTP cipher negotiation is not protected until the Finished.
That is covered by the false start RFC adequately in my view.
Which section do you believe covers it?
Well, I guess that URL covers cipher negotiation, but I would concede that it's probably more mechanical and less about the underlying principles.
Yes, and so consider the case where you are negotiating both double and regular SRTP....
Ugh. You have convinced me :) Prohibit it. And we should maybe say why.
I tend to agree that we should include a reason in .
Why make this prohibition? The description in RFC 7918 covers most of the reasons you might choose not to false start, is there anything in that set that motivates this? I mean, clients doing false start only do so if they aren't concerned about the implications of downgrade for the parameters that are (apparently) negotiated.

Revised text:
Implementations MUST NOT implement DTLS renegotiation and MUST reject it with a "no_renegotiation" alert if offered. <ins> Endpoints MUST NOT implement TLS False Start RFC7918. </ins> The API MUST generate a new authentication key pair for every new call by default.  This is intended to allow for unlinkability.
Original text:
attribute of the SDP RFC8122. This object is encoded in a RFC8259 string for passing to the IdP.  This structure does not need to be interpreted by the IdP or the IdP proxy.  It is consumed solely by the RP's browser.  The IdP merely 7.4.1. <del> Once an IdP has generated an assertion, it is attached to the SDP offer/answer message.  This is done by adding a new 'identity' attribute to the SDP.  The sole contents of this value are a RFC4648 identity assertion.  For example: </del>  The 'identity' attribute attests to all "fingerprint" attributes in the session description.  It is therefore a session-level attribute. Unlike the AP, the RP need not have any particular relationship with the IdP.  Rather, it needs to be able to process whatever assertion <del> is provided by the AP.  As the assertion contains the IdP's identity, the URI can be constructed directly from the assertion, and thus the RP can directly verify the technical validity of the assertion with no user interaction.  Authoritative assertions need only be verifiable.  Third-party assertions also MUST be verified against local policy, as described in sec.id-format. </del>  7.6.

Reviewer comments:
The description of how an assertion is constructed seemed to imply that the object with the fingerprints was what went in a=identity. You had to read much further down to learn that this wasn't right and that it was really the assertion. This just moves some of the critical text up, duplicating it really, so that this confusion is less likely.

Revised text:
attribute of the SDP RFC8122. This object is encoded in a RFC8259 string for passing to the IdP. <ins> The identity assertion returned by the IdP, which is encoded in the "identity" attribute, is a JSON object that is encoded as described in sec.carry-assertion. </ins> This structure does not need to be interpreted by the IdP or the IdP proxy.  It is consumed solely by the RP's browser.  The IdP merely 7.4.1.  <ins> Once an IdP has generated an assertion (see sec.request-assert), it is attached to the SDP offer/answer message.  This is done by adding a new 'identity' attribute to the SDP.  The sole contents of this value is the identity assertion.  The identity assertion produced by the IdP is encoded into a UTF-8 JSON text, then RFC4648 to produce this string.  For example: </ins> The 'identity' attribute attests to all "fingerprint" attributes in the session description.  It is therefore a session-level attribute. Unlike the AP, the RP need not have any particular relationship with the IdP.  Rather, it needs to be able to process whatever assertion  <ins> is provided by the AP.  As the assertion contains the IdP's identity in the "idp" field of the JSON-encoded object (see sec.request- assert), the URI can be constructed directly from the assertion, and thus the RP can directly verify the technical validity of the assertion with no user interaction.  Authoritative assertions need only be verifiable.  Third-party assertions also MUST be verified against local policy, as described in sec.id-format. </ins> 7.6.
Original text:
Recently, a number of Web-based identity technologies (OAuth, Facebook Connect etc.) have been developed.  While the details vary, what these technologies share is that they have a Web-based (i.e., <del> HTTP/HTTPS) identity provider which attests to your identity.  For instance, if I have an account at example.org, I could use the example.org identity provider to prove to others that I was </del>  alice@example.org.  The development of these technologies allows us <del> to separate calling from identity provision: I could call you on </del>  Poker Galaxy but identify myself as alice@example.org. Whatever the underlying technology, the general principle is that the service can strip off any such identity assertions, though it cannot forge new ones.  Note that all of the third-party security mechanisms available (whether X.509 certificates or a third-party IdP) rely on <del> the security of the third party--this is of course also true of your connection to the Web site itself.  Users who wish to assure </del>  themselves of security against a malicious identity provider can only do so by verifying peer credentials directly, e.g., by checking the peer's fingerprint against a value delivered out of band.

Reviewer comments:
In Section 7 I would suggest using Alice and Bob (or some other name) rather than "I" and "you/your." EMAIL is used there so the pronouns are mixed. Same comment for 9.1 -- I would suggest replacing "your" with "the user's."

Revised text:
Recently, a number of Web-based identity technologies (OAuth, Facebook Connect etc.) have been developed.  While the details vary, what these technologies share is that they have a Web-based (i.e.,  <ins> HTTP/HTTPS) identity provider which attests to Alice's identity.  For instance, if Alice has an account at example.org, Alice could use the example.org identity provider to prove to others that Alice is </ins> alice@example.org.  The development of these technologies allows us  <ins> to separate calling from identity provision: Alice could call you on </ins> Poker Galaxy but identify myself as alice@example.org. Whatever the underlying technology, the general principle is that the service can strip off any such identity assertions, though it cannot forge new ones.  Note that all of the third-party security mechanisms available (whether X.509 certificates or a third-party IdP) rely on  <ins> the security of the third party--this is of course also true of the user's connection to the Web site itself.  Users who wish to assure </ins> themselves of security against a malicious identity provider can only do so by verifying peer credentials directly, e.g., by checking the peer's fingerprint against a value delivered out of band.
Original text:
connections as well as new connections established using one of those fingerprints.  Note that I-D.ietf-rtcweb-jsep, Section 5.2.1 requires that each media section use the same set of fingerprints for every <del> media section. </del>  If the set of fingerprints changes, then the sender MUST either send a new 'identity' attribute or none at all.  Because a change in

Reviewer comments:
What happens if fingerprints don't change but identity does, and there's no new connection, (e.g., a codec change). This text needs to say you propagate that identity to the existing connections.
The webrtc text forbids changing of identity. You might want to note that, even if this new language is correct in a more general sense.

Revised text:
connections as well as new connections established using one of those fingerprints.  Note that I-D.ietf-rtcweb-jsep, Section 5.2.1 requires that each media section use the same set of fingerprints for every  <ins> media section.  If a new identity attribute is received, then the receiver MUST apply that identity to all existing connections. </ins> If the set of fingerprints changes, then the sender MUST either send a new 'identity' attribute or none at all.  Because a change in
Original text:
fig.assert-ex shows an example assertion formatted as JSON.  In this case, the message has presumably been digitally signed/MACed in some way that the IdP can later verify it, but this is an implementation <del> detail and out of scope of this document.  Line breaks are inserted solely for readability. </del>  For use in signaling, the assertion is serialized into JSON, RFC4648, <del> and used as the value of the "identity" attribute. </del>  7.7.

Reviewer comments:
The key point is that this is a self-consumed token, so you need to separate it from other self-consumed tokens with different semantics or externally consumed tokens, either by format or by using a separate ke. Ben suggests making this point in 7.4.

Revised text:
fig.assert-ex shows an example assertion formatted as JSON.  In this case, the message has presumably been digitally signed/MACed in some way that the IdP can later verify it, but this is an implementation  <ins> detail and out of scope of this document. </ins> For use in signaling, the assertion is serialized into JSON, RFC4648,  <ins> and used as the value of the "identity" attribute.  IdPs SHOULD ensure that any assertions they generate cannot be interpreted in a different context.  E.g., they should use a distinct format or have separate cryptographic keys for assertion generation and other purposes.  Line breaks are inserted solely for readability. </ins> 7.7.
Original text:
and to Alice's identity.  In this case, Alice has provided an identity assertion and so Bob's browser contacts Alice's identity provider (again, this is done in a generic way so the browser has no <del> specific knowledge of the IdP) to verify the assertion.  This allows the browser to display a trusted element in the browser chrome </del>  indicating that a call is coming in from Alice.  If Alice is in Bob's address book, then this interface might also include her real name, a picture, etc.  The calling site will also provide some user interface When an endpoint receives an offer or answer that contains an 'identity' attribute, the answerer can use the the attribute <del> information to contact the IdP, and verify the identity of the peer. If the identity verification fails, the answerer MUST discard the offer or answer as malformed. </del>  5.1.4.

Reviewer comments:
We'll leave this for later.
What's generic is the protocol, but if you have a third party IdP, trust has to be configured. Say that and point to 7.1
See also 5.1.3. Forward reference to 7.1

Revised text:
and to Alice's identity.  In this case, Alice has provided an identity assertion and so Bob's browser contacts Alice's identity provider (again, this is done in a generic way so the browser has no  <ins> specific knowledge of the IdP) to verify the assertion.  It is also possible to have IdPs with which the browser has a specific trustrelationship, as described in sec.trust-relationships.  This allows the browser to display a trusted element in the browser chrome </ins> indicating that a call is coming in from Alice.  If Alice is in Bob's address book, then this interface might also include her real name, a picture, etc.  The calling site will also provide some user interface When an endpoint receives an offer or answer that contains an 'identity' attribute, the answerer can use the the attribute  <ins> information to contact the IdP and verify the identity of the peer. If the identity requires a third-party IdP as described in sec.trust- relationships then that IdP will need to have been specifically configured.  If the identity verification fails, the answerer MUST discard the offer or answer as malformed. </ins> 5.1.4.
Original text:
The attacker modifies my HTTP connection to inject an IFRAME (or a redirect) to http://calling-service.example.com <del> The attacker forges the response apparently http://calling- </del>  service.example.com/ to inject JS to initiate a call to himself. Note that this attack does not depend on the media being insecure. user is behind a VPN that masks their IP address.  Implementations may wish to provide settings which suppress all non-VPN candidates if the user is on certain kinds of VPN, especially privacy-oriented <del> systems such as Tor. </del>  4.3. with the same lifetime as cookies).  Moreover, the API should provide mechanisms to allow sites intended for anonymous calling to force the minting of fresh identifiers.  In addition, IP addresses can be a <del> source of call linkage I-D.ietf-rtcweb-ip-handling </del>  4.4.2. and WebRTC is no exception.  Specifically, sites can use the presence or absence of specific devices as a browser fingerprint.  In general, the API needs to be balanced between functionality and the <del> incremental fingerprint risk.  See Fingerprinting </del>  5.

Reviewer comments:
Addressing Alissa's comments. I also added to periods that I noticed were missing.
NAME NAME PTAL
Scratch that, I'm reading backwards. The references are fine.

Revised text:
The attacker modifies my HTTP connection to inject an IFRAME (or a redirect) to http://calling-service.example.com  <ins> The attacker forges the response apparently from http://calling- </ins> service.example.com/ to inject JS to initiate a call to himself. Note that this attack does not depend on the media being insecure. user is behind a VPN that masks their IP address.  Implementations may wish to provide settings which suppress all non-VPN candidates if the user is on certain kinds of VPN, especially privacy-oriented  <ins> systems such as Tor.  See I-D.ietf-rtcweb-ip-handling for additional information. </ins> 4.3. with the same lifetime as cookies).  Moreover, the API should provide mechanisms to allow sites intended for anonymous calling to force the minting of fresh identifiers.  In addition, IP addresses can be a  <ins> source of call linkage I-D.ietf-rtcweb-ip-handling. </ins> 4.4.2. and WebRTC is no exception.  Specifically, sites can use the presence or absence of specific devices as a browser fingerprint.  In general, the API needs to be balanced between functionality and the  <ins> incremental fingerprint risk.  See Fingerprinting. </ins> 5.
Original text:
Abstract <del> The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for real-time communications between Web browsers, generally called "WebRTC".  The major use cases for WebRTC technology are real-time audio and/or video calls, Web conferencing, and direct data transfer.  Unlike most conventional real-time systems (e.g., SIP-based soft phones) WebRTC communications are directly controlled by a Web server, which poses new security challenges.  For instance, a Web browser might expose a JavaScript API which allows a server to place a video call.  Unrestricted access to such an API would allow any site which a user visited to "bug" a user's computer, capturing any activity which passed in front of their camera.  This document defines the WebRTC threat model and analyzes the security threats of WebRTC in that model. </del>  1.

Reviewer comments:
I suspect we'll get dinged here for referring to the RTCWEB WG by name. I'm thinking we can just trim it down to be a one sentence blurb (stolen from overview) and then say this is the threat model/analysis.

Revised text:
Abstract  <ins> WebRTC is a protocol suite for use with real-time applications that can be deployed in browsers - "real time communication on the Web". This document defines the WebRTC threat model and analyzes the security threats of WebRTC in that model. </ins> 1.
Original text:
binary CBOR value is base64-encoded (RFC4648).  The data value after base64 decoding is shown with CBOR diagnostic notation in ex-2-cbor.  2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Type, each of the content coding values is appended to the Content- Type value (media type and parameters, if any), separated by a "@" sign, in the order of the content codings were applied (the same <del> order as in RFC7231).  For example (using a content coding value of "deflate" as defined in RFC7230): </del>  If no "@" sign is present after the media type and parameters, then no content coding has been specified, and the "identity" content This specification provides a formal definition of the syntax of Content-Format-Spec strings using ABNF notation RFC5234, which contains three new rules and a number of rules collected and adapted <del> from various RFCs RFC7231 RFC6838 RFC5234 RFC8866. </del>  7.

Reviewer comments:
7de7a76 Update the ABNF to refer to httpbis-semantics; include quoted-pair 7775765 Switch from 7230/7231 to httpbis-semantics 0a57952 Address the question Roman Danyliw did not ask :-)

Revised text:
binary CBOR value is base64-encoded (RFC4648).  The data value after base64 decoding is shown with CBOR diagnostic notation in ex-2-cbor. <ins> 1.1. As with SenML in general, there is no expectation that the creator of a SenML pack knows (or has negotiated with) each consumer of that pack, which may be very remote in space and particularly in time. This means that the SenML creator in general has no way to know whether the consumer knows: each specific media-type-name used each parameter and each parameter value used each content coding in use each Content-Format number in use for a combination of these What SenML, as well as the new fields defined here, guarantees is that a recipient implementation when it needs to be updated to understand these field values and the values controlled by them; registries are used to evolve these name spaces in a controlled way.  SenML packs can be processed by a consumer while not understanding all the information in them, and information can generally be preserved in this processing such that it is useful for further consumers. </ins> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Type, each of the content coding values is appended to the Content- Type value (media type and parameters, if any), separated by a "@" sign, in the order of the content codings were applied (the same  <ins> order as in I-D.ietf-httpbis-semantics).  For example (using a content coding value of "deflate" as defined in I-D.ietf-httpbis- semantics): </ins> If no "@" sign is present after the media type and parameters, then no content coding has been specified, and the "identity" content This specification provides a formal definition of the syntax of Content-Format-Spec strings using ABNF notation RFC5234, which contains three new rules and a number of rules collected and adapted  <ins> from various RFCs I-D.ietf-httpbis-semantics RFC6838 RFC5234 RFC8866. [[replace: RFC editor: Please replace [RFC-httpbis-semantics] by what gets published from ]] </ins> 7.
Original text:
a name, that do not exist in any existing Record in the Pack, the given Record, with all the fields it contains, is added to the Pack. <del> If a Patch Record has a value field with value null, the matched Record (if any) is removed from the Pack. </del>  <del> For example, the following document could be given as (i)PATCH </del>  payload to change/set values of two SenML Records for the example in intro: If the request is successful, the resulting representation of the example SenML Pack would be as follows:  4. The security and privacy considerations of SenML apply also with the IANA is requested to assign CoAP Content-Format IDs for the SenML PATCH and FETCH media types in the "CoAP Content-Formats" sub- <del> registry, within the "CoRE Parameters" registry RFC7252.  All IDs are assigned from the "IETF Review or IESG Approval" range.  The assigned IDs are show in tbl-coap-content-formats. </del>  5.2.

Reviewer comments:
“Are show”
Should clarify that null value for deleting records should always be in "v" field regardless of the value type used in the Record.
Also example of deleting would be useful

Revised text:
a name, that do not exist in any existing Record in the Pack, the given Record, with all the fields it contains, is added to the Pack.  <ins> If a Patch Record has a value ("v") field with value null, the matched Record (if any) is removed from the Pack. </ins>  <ins> For example, the following document could be given as an (i)PATCH </ins> payload to change/set values of two SenML Records for the example in intro: If the request is successful, the resulting representation of the example SenML Pack would be as follows: <ins> As another example, the following document could be given as an (i)PATCH payload to remove the two SenML Records: </ins> 4. The security and privacy considerations of SenML apply also with the IANA is requested to assign CoAP Content-Format IDs for the SenML PATCH and FETCH media types in the "CoAP Content-Formats" sub-  <ins> registry, within the "CoRE Parameters" registry RFC7252.  The assigned IDs are shown in tbl-coap-content-formats. </ins> 5.2.
Original text:
9.2. In addition to the SenML Fragment Identifiers described above, with <del> the XML SenML formats also the syntax defined in XPointerFramework can be used, as recommended by RFC7303. </del>  10.

Reviewer comments:
EXI is XML so for consistency we should allow anything that is allowed for (character) XML for EXI as well. Make Klaus' point about content negotiation possibly leading to a format where xpointer does not apply and add the Accept workaround.
LGTM

Revised text:
9.2. In addition to the SenML Fragment Identifiers described above, with  <ins> the XML and EXI SenML formats also the syntax defined in XPointerFramework can be used.  (This is required by RFC7303 for media types using the "+xml" structured syntax suffix.  SenML allows this for the EXI formats as well for consistency.) Note that fragment identifiers are available to the client side only; they are not provided in transfer protocols such as CoAP or HTTP. Thus, they cannot be used by the server in deciding which media type to send.  Where a server has multiple representations available for a resource identified by a URI, it might send a JSON or CBOR representation when the client was directed to use an XML/EXI fragment identifier with this.  Clients can prevent running into this problem by explicitly requesting an XML or EXI media type (e.g., using the CoAP Accept option) when XML/EXI-only fragment identifier syntax is in use in the URI. </ins> 10.
Original text:
using SenML need to look at the overall context of how these formats will be used to decide if the security is adequate.  In particular for sensitive sensor data and actuation use it is important to ensure <del> that proper security mechanisms are used. </del>  The SenML formats defined by this specification do not contain any executable content.  However, future extensions could potentially

Reviewer comments:
The RFC editor will add in the missing comma. Maybe use the usual sequence (confidentiality first). But all this is motherhood and apple pie anyway...
LGTM - thanks

Revised text:
using SenML need to look at the overall context of how these formats will be used to decide if the security is adequate.  In particular for sensitive sensor data and actuation use it is important to ensure  <ins> that proper security mechanisms are used to provide, e.g., confidentiality, data integrity, and authentication as appropriate for the usage. </ins> The SenML formats defined by this specification do not contain any executable content.  However, future extensions could potentially