jiebi/TextFlow huggingface dataset:
Original text:
Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier <del> draft-ietf-tls-rfc4492bis-14 </del>  Abstract out of scope for this document.  In particular, this document defines: <del> the use of the Elliptic Curve Diffie-Hellman key agreement scheme with ephemeral keys to establish the TLS premaster secret, and the use of ECDSA certificates for authentication of TLS peers. </del>  The remainder of this document is organized as follows. ecdh provides an overview of ECC-based key exchange algorithms for TLS. clientauth

Reviewer comments:
Use initialism consistently in the Introduction Mention EdDSA in addition to ECDSA as a signature scheme
lgtm

Revised text:
Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier  <ins> draft-ietf-tls-rfc4492bis-15 </ins> Abstract out of scope for this document.  In particular, this document defines:  <ins> the use of the ECDHE key agreement scheme with ephemeral keys to establish the TLS premaster secret, and the use of ECDSA and EdDSA signatures for authentication of TLS peers. </ins> The remainder of this document is organized as follows. ecdh provides an overview of ECC-based key exchange algorithms for TLS. clientauth
Original text:
All ECDSA computations MUST be performed according to ANSI X9.62 or its successors.  Data to be signed/verified is hashed, and the result run directly through the ECDSA algorithm with no additional hashing. <del> The default hash function is SHA-1 FIPS.180-2, and sha_size (see ske and cert_verify) is 20.  However, an alternative hash function, such as one of the new SHA hash functions specified in FIPS 180-2 FIPS.180-2, SHOULD be used instead. </del>  All EdDSA computations MUST be performed according to RFC8032 or its succesors.  Data to be signed/verified is run through the EdDSA

Reviewer comments:
RFC 4492 called SHA-1 the "default" hash for ECDSA, because that was the only hash defined in X9.62 at the time. The new X9.62 (new being a relative term - it's from 2005) defines all the SHA-2 hashes as well. We now make the use of secure hashes a MUST and we call out SHA-256, SHA-384, and SHA-512 explicitly as examples. Also had to update the reference to the SHA document from NIST 180-2 (which did not contain SHA-2) to the current NIST 180-4 (which does)

Revised text:
All ECDSA computations MUST be performed according to ANSI X9.62 or its successors.  Data to be signed/verified is hashed, and the result run directly through the ECDSA algorithm with no additional hashing.  <ins> A secure hash function such as SHA-256, SHA-384, or SHA-512 from FIPS.180-4 MUST be used. </ins> All EdDSA computations MUST be performed according to RFC8032 or its succesors.  Data to be signed/verified is run through the EdDSA
Original text:
point that they may recover the entire private key in a few requests, if that key is not really ephemeral. <del> X25519 was designed in a way that the result of X25519(x, d) will never reveal information about d, provided it was chosen as prescribed, for any value of x (the same holds true for X448). All-zeroes output from X25519 or X448 MUST NOT be used for premaster secret (as required by definition of X25519 and X448).  If the premaster secret would be all zeroes, the handshake MUST be aborted (most probably by sending a fatal alert). Let's define legitimate values of x as the values that can be obtained as x = X25519(G, d') for some d', and call the other values illegitimate.  The definition of the X25519 function shows that legitimate values all share the following property: the high-order bit of the last byte is not set (for X448, any bit can be set). Since there are some implementation of the X25519 function that impose this restriction on their input and others that don't, implementations of X25519 in TLS SHOULD reject public keys when the high-order bit of the final byte is set (in other words, when the value of the rightmost byte is greater than 0x7F) in order to prevent implementation fingerprinting.  Note that this deviates from RFC 7748 which suggests that This value be masked. </del>  Ed25519 and Ed448 internally do public key validation as part of signature verification. <del> Other than this recommended check, implementations do not need to ensure that the public keys they receive are legitimate: this is not necessary for security with X25519. </del> 6. The table below defines new ECC cipher suites that use the key

Reviewer comments:
RFC 7748, TLS 1.3, and existing implementations do not check the significant bit. Instead, they mask it off. Align with all of these. Also tweak the all-zeros citation. RFC 7748 describes it as an optional check.
This looks goo to me.
LGTM

Revised text:
point that they may recover the entire private key in a few requests, if that key is not really ephemeral.  <ins> With X25519 and X448, a receiving party MUST check whether the computed premaster secret is the all-zero value and abort the handshake if so, as described in section 6 of RFC7748. </ins> Ed25519 and Ed448 internally do public key validation as part of signature verification.  6. The table below defines new ECC cipher suites that use the key
Original text:
encryption/MAC keys and initialization vectors is independent of the key exchange algorithm and not impacted by the introduction of ECC. <del> The table below summarizes the new key exchange algorithms, which mimic DHE_DSS, DHE_RSA, and DH_anon, respectively. The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward secrecy.  With ECDHE_RSA, a server can reuse its existing RSA certificate and easily comply with a constrained client's elliptic curve p references (see tlsext).  However, the computational cost incurred by a server is higher for ECDHE_RSA than for the traditional RSA key exchange, which does not provide forward secrecy. </del>  The anonymous key exchange algorithm does not provide authentication of the server or the client.  Like other anonymous TLS key exchanges,

Reviewer comments:
I've restructured a little in support of this. I think that forward secrecy is more pertinent than the analogous finite-field stuff. I can make this less intrusive if you feel like the changes are gratuitous.

Revised text:
encryption/MAC keys and initialization vectors is independent of the key exchange algorithm and not impacted by the introduction of ECC.  <ins> tbl2 summarizes the new key exchange algorithms.  All of these key exchange algorithms provide forward secrecy. These key exchanges are analogous to DHE_DSS, DHE_RSA, and DH_anon, respectively. With ECDHE_RSA, a server can reuse its existing RSA certificate and easily comply with a constrained client's elliptic curve preferences (see tlsext).  However, the computational cost incurred by a server is higher for ECDHE_RSA than for the traditional RSA key exchange, which does not provide forward secrecy. </ins> The anonymous key exchange algorithm does not provide authentication of the server or the client.  Like other anonymous TLS key exchanges,
Original text:
ICE agents SHOULD use the default Ta value, 50 ms, but MAY use another value based on the characteristics of the associated media. <del> ICE agents MUST NOT use a Ta value smaller than 5 ms. </del> If an ICE agent wants to use another Ta value than the default value, the agent MUST indicate the proposed value to its peer during the ICE values.  If an agent does not propose a value, the default value is used for that agent when comparing which value is higher.  NOTE: sec-concheckbw shows examples of required bandwidth, using different Ta values.

Reviewer comments:
Annex B.1 also contain some text regarding the rate. E.g. "The definition of a "reasonable" rate is that STUN should not use more bandwidth than the RTP itself will use, once media starts flowing." I guess we should discuss whether: 1) We need to remove/modify that text 2) Whether B.1 is the place where we should talk about the global rate limit.
I'll own this issue because I'm driving discussion on the list around the transport guys' proposal for "MaxPackets+HTO+pacing".
Hopefully fixed by URL

Revised text:
ICE agents SHOULD use the default Ta value, 50 ms, but MAY use another value based on the characteristics of the associated media.  If an ICE agent wants to use another Ta value than the default value, the agent MUST indicate the proposed value to its peer during the ICE values.  If an agent does not propose a value, the default value is used for that agent when comparing which value is higher. <ins> Regardless of the Ta value chosen for each ICE agent, the combination of all transactions from all ICE agents (if a given implementation runs several concurrent ICE agents) MUST NOT be sent more often than once every 5ms (as though there were one global Ta value for pacing all ICE agents). This mechanism of a global minimum pacing interval of 5ms is not generally applicable to transport protocols, but is applicable to ICE based on the following reasoning. Start with the following rules which would be generally applicable to transport protocols: Let MaxBytes be the maximum number of bytes allowed to be outstanding in the network at start-up, which SHOULD be 14600 bytes per RFC 6928. Let HTO be the transaction timeout, which SHOULD be 2*RTT if RTT is known and 500ms otherwise.  This is based on the RTO for STUN messages from RFC 5389 and the the TCP initial RTO, which is 1 sec in RFC 6298. Let MinPacing be the minimum pacing interval between transactions, which SHOULD be 5ms. Observe that ICE agents typically do not know the RTT for ICE transactions (connectivity checks in particular), meaning that HTO will almost always be 500ms. Observe that a MinPacing of 5ms and HTO of 500ms gives at most 100 packets/HTO, which for a typical ICE check of less than 120 bytes means a maximum of 12000 outstanding bytes in the network, which is less than the maximum expressed by rule 1. Thus, for ICE, the rule set reduces down to just the MinPacing rule, which is equivalant to having a global Ta value. </ins> NOTE: sec-concheckbw shows examples of required bandwidth, using different Ta values.
Original text:
This specification makes use of the following additional terminology:  An agent is the protocol implementation involved in the ICE candidate exchange.  There are two agents involved in a typical candidate exchange.

Reviewer comments:
Not sure this is correct. ICE session is something that continues until ufrag/passwords change. The same candidates can be re-used across multiple ICE sessions.
I think better definition will be: An ICE session consists of all ICE-related actions starting with the candidate gathering, followed by the interactions (candidate exchange, connectivity checks, nominations and keep-alives) between the ICE agents until all the candidates are released or ICE-restart is initiated by ufrag/password change.
Roman's suggestion looks good.
I think the current proposed explanation (one with more details) is good. Would suggest merging this.
My suggestion is to merge, submit a new version, and then continue working on Peter's issues.
Why not just say an ICE session is all ICE activity tied to a candidate exchange with a specific ufrag/pwd? Every time you do a candidate exchange with a new ufrag/pwd, you have a new ICE session. I don't think we need to say all the rest.

Revised text:
This specification makes use of the following additional terminology: <ins> An ICE session consists of all ICE-related actions starting with the candidate gathering, followed by the interactions (candidate exchange, connectivity checks, nominations and keep-alives) between the ICE agents until all the candidates are released or ICE-restart is triggered. </ins> An agent is the protocol implementation involved in the ICE candidate exchange.  There are two agents involved in a typical candidate exchange.
Original text:
address and port) in addition to the ICE parameters. STUN connectivity checks between agents are authenticated using the <del> short-term credential mechanism defined for STUN [RFC5389].  This mechanism relies on a username and password that are exchanged through protocol machinery between the client and server.  The username part of this credential is formed by concatenating a username fragment from each agent, separated by a colon.  Each agent also provides a password, used to compute the message integrity for requests it receives.  The username fragment and password are exchanged between the peers.  In addition to providing security, the username provides disambiguation and correlation of checks to media streams.  See Appendix B.4 for motivation. </del>  If the initiating agent is a lite implementation, it MUST indicate this when sending its candidates .

Reviewer comments:
It looks like two references didn't get translated into xml2rfc xref tags when RFC 5245 got imported.
LGTM! Thanks!

Revised text:
address and port) in addition to the ICE parameters. STUN connectivity checks between agents are authenticated using the  <ins> short-term credential mechanism defined for RFC5389.  This mechanism relies on a username and password that are exchanged through protocol machinery between the client and server.  The username part of this credential is formed by concatenating a username fragment from each agent, separated by a colon.  Each agent also provides a password, used to compute the message integrity for requests it receives.  The username fragment and password are exchanged between the peers.  In addition to providing security, the username provides disambiguation and correlation of checks to media streams.  See sec-why-uname for motivation. </ins> If the initiating agent is a lite implementation, it MUST indicate this when sending its candidates .
Original text:
3.1. <del> A problem details object can have the following members: </del>  3.1.1.

Reviewer comments:
From URL : JSON objects with a null "type" are syntactically correct, but there is no information on how it should be handled. { "type": null, "status": 404, "title": "Not Found" } It makes sense to treat null as an alias of "about:blank" and that's how I think it should be documented.
Note that the errata above is only . My .02 -- if is , it's invalid, not "syntactically correct"; it's specified to be a string, and if someone assumes that has semantics, that's not currently specified behaviour. So the real question here is whether the default of is assumed when the value is invalid, or whether some other error handling comes into play. I think the safest thing to do would not be to assume that implies -- i.e., no change to the spec.
Since this is a specification of a format for error messages, I believe it is important that the processing of the error message is clear and lenient so the processing itself does not cause errors, possibly shrouding the initial error that caused the response in the first place. I therefore think the specification should be explicit that all erroneous values (such as , , , etc.) should be ignored and treated as the default value of each member, which for equals to , but for other members equal to an empty string(?).
I think I agree; changing issue title.

Revised text:
3.1.  <ins> Problem detail objects can have the following members.  If the type of a member's value does not match the specified type, the member MUST be ignored - i.e., processing will continue as if the member had not been present. </ins> 3.1.1.
Original text:
that identifies the specific occurrence of the problem.  It may or may not yield further information if dereferenced.  When "instance" contains a relative URI, it is resolved relative to the document's base URI, as per RFC3986, Section 5.  However, using relative URIs can cause confusion, and they might not be handled

Reviewer comments:
As discussed in URL, this PR expands on the dereferenceability of to clarify what the URI is expected to return, which hopefully also clarify the intended use of .
Merging, might tweak a bit further in situ. Thanks!

Revised text:
that identifies the specific occurrence of the problem.  It may or may not yield further information if dereferenced. <ins> When the "instance" URI is dereferenceable it can return the same problem response that was returned to the client which generated the problem originally.  It might also return more information about the problem occurrence in other formats (e.g., using proactive content negotiation; see HTTP, Section 12.5.1). When the "instance" URI is not dereferenceable, it serves as a unique identifier for the problem occurrence that may be of significance to the server, but is opaque to the client. </ins> When "instance" contains a relative URI, it is resolved relative to the document's base URI, as per RFC3986, Section 5.  However, using relative URIs can cause confusion, and they might not be handled
Original text:
This specification defines the HTTP Problem Type registry for common, widely-used problem type URIs, to promote reuse. <del> A Designated Expert reviews and approves registration requests, as per RFC8126, Section 4.5.  A specification document is appreciated, but not required. </del>  When evaluating requests, the Expert(s) should consider community feedback, how well-defined the problem type is, and this specification's requirements.  Vendor-specific, application-specific, <del> and deployment-specific values are not registrable. </del>  Registrations MAY use the prefix "https://iana.org/assignments/http- <del> problem-types#", and are encouraged to do so when a stable, neutral URI is desirable. </del>  Registration requests should use the following template:

Reviewer comments:
Currently: That doesn't seem like a recipe for good interop. While it doesn't need to be an RFC, some sort of reference is necessary...
I'm sorry, but I don't quite understand what is being referred to here. Is the quoted paragraph from RFC7807? Because I can't find it. Without more context I also don't quote understand what it is referring to.
NAME https://ietf-wg-URL

Revised text:
This specification defines the HTTP Problem Type registry for common, widely-used problem type URIs, to promote reuse.  <ins> The policy for this registry is Specification Required, per RFC8126, Section 4.5. </ins> When evaluating requests, the Expert(s) should consider community feedback, how well-defined the problem type is, and this specification's requirements.  Vendor-specific, application-specific,  <ins> and deployment-specific values are not registrable.  Specification documents should be published in a stable, freely available manner (ideally located with a URL), but need not be standards. </ins> Registrations MAY use the prefix "https://iana.org/assignments/http-  <ins> problem-types#" for the type URI. </ins> Registration requests should use the following template:
Original text:
The "type" member is a JSON string containing a URI reference URI that identifies the problem type.  Consumers MUST use the "type" URI <del> (after resolution, if necessary) as the problem's primary identifier. </del>  When this member is not present, its value is assumed to be "about:blank".

Reviewer comments:
It seems that saying could be read as identifying the problem instance rather than identifying the problem type. Here's a minor edit to make this more explicit: It's not quite clear to me what other identifiers could be (patterns of extension members, maybe?), but that's a different question.

Revised text:
The "type" member is a JSON string containing a URI reference URI that identifies the problem type.  Consumers MUST use the "type" URI  <ins> (after resolution, if necessary) as the problem type's primary identifier. </ins> When this member is not present, its value is assumed to be "about:blank".
Original text:
Despite the following behavior being misguided, experience has shown that some customers use the IANA registry as a checklist against which to measure an implementation's completeness, and some <del> implementers blindly implement supported group.  Therefore, IANA [SHALL add/has added] the following warning to the registry: </del>  IANA [SHALL update/has updated] the reference for this registry to <del> also refer to this document. </del>  The value 0 (0x0000) has been marked as reserved.

Reviewer comments:
Tweaks for Supported Groups. We still need to figure out what to do with curves smaller than 256.

Revised text:
Despite the following behavior being misguided, experience has shown that some customers use the IANA registry as a checklist against which to measure an implementation's completeness, and some  <ins> implementers blindly implement supported group.  Therefore, IANA has added the following warning to the registry: </ins> IANA [SHALL update/has updated] the reference for this registry to  <ins> refer to this document instead of RFC8447. </ins> The value 0 (0x0000) has been marked as reserved.
Original text:
7. <del> In order to refect the changes in the Recommended column allocation, IANA SHALL update the TLS Exporter Labels Registry as follows: </del>  <del> Update the registration procedure to include: </del>  Add a reference to this document under the reference heading. Update note on the recommended column with text in rec-note.  8. In order to refect the changes in the Recommended column allocation,

Reviewer comments:
Update exporter
NAME minor nit, but this is what I remember being discussed in Philly.
I was recently surprised to learn that the uses . This is a problem for us - we have an internal use of an exporter that we cannot release a specification for at this time. This means that our only option is to "squat" on the value instead of registering it. Since we're already making changes to these repositories and we now have a Recommended column, I propose that we instead use . Note that Expert Review is exactly the same as Specification Required, with the exception that it doesn't require a specification. We could also add a requirement that entries with have a specification.

Revised text:
7.  <ins> This document updates the registration procedure for the TLS Exporter registry and updates the Recommended column allocation.  IANA SHALL update the TLS Exporter Labels Registry as follows: </ins>  <ins> Change the registration procedure from Specification Required to Expert Review and update it to include: </ins> Add a reference to this document under the reference heading. Update note on the recommended column with text in rec-note. <ins> update the note on the role of the expert reviewer as follows. </ins> 8. In order to refect the changes in the Recommended column allocation,
Original text:
2.4.  The following terms are used across the documents specifying the WebRTC suite, in the specific meanings given here.  Not all terms are used in this document.  Other terms are used in their commonly used

Reviewer comments:
ID-nits turned up that the 2119 language section was missing. I added it as a new section, but could also see it being in the existing section 2.
I think I prefer it in section 2.4, with the rest of terminology.

Revised text:
2.4. <ins> 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. </ins> The following terms are used across the documents specifying the WebRTC suite, in the specific meanings given here.  Not all terms are used in this document.  Other terms are used in their commonly used