jiebi/TextFlow huggingface dataset:
Original text:
RFC5705 defines keying material exporters for TLS in terms of the TLS PRF.  This document replaces the PRF with HKDF, thus requiring a new <del> construction.  The exporter interface remains the same, however the value is computed as: </del>  8.

Reviewer comments:
No context and empty context are now declared to be the same. Add some ALL CAPS WORDS for future specifications to deprecate no context. I used SHOULD to forbid no context because, if some protocol currently uses no context, switching it to empty context is a breaking change and probably not worth it. We just want new ones to always provide a context. This affects the rules for using exporters, so RFC 5705 is added to the list of updated documents. Closes issue .

Revised text:
RFC5705 defines keying material exporters for TLS in terms of the TLS PRF.  This document replaces the PRF with HKDF, thus requiring a new  <ins> construction.  The exporter interface remains the same.  If context is provided, the value is computed as: If no context is provided, the value is computed as: Note that providing no context computes the same value as providing an empty context.  As of this document's publication, no allocated exporter label is used with both modes.  Future specifications MUST NOT provide an empty context and no context with the same label and SHOULD provide a context, possibly empty, in all exporter computations. </ins> 8.
Original text:
The key exchange and authentication modes this PSK is allowed to be used with <del> The Application-Layer Protocol Negotiation (ALPN) label(s) </del>  The Server Name Indication (SNI), if any is to be used

Reviewer comments:
1) Switches uses of ALPN label/value to "ALPN protocol" (to clarify this is referring to a single protocol, not the entire extension) 2) Remove plural from external PSK case (if there's not way for the client to select which protocol the 0-RTT data uses, it doesn't make sense for there to be multiple options) 3) Switch reference from RFC7443 to RFC7301 (I assume this is what was intended) I think this makes the intended behavior of the spec a bit more clear.

Revised text:
The key exchange and authentication modes this PSK is allowed to be used with  <ins> The Application-Layer Protocol Negotiation (ALPN) protocol, if any is to be used </ins> The Server Name Indication (SNI), if any is to be used
Original text:
handshake but reject 0-RTT, and SHOULD NOT take any other action that assumes that this ClientHello is fresh. <del> The parameters for the 0-RTT data (symmetric cipher suite, ALPN, etc.) are the same as those which were negotiated in the connection which established the PSK.  The PSK used to encrypt the early data MUST be the first PSK listed in the client's "pre_shared_key" extension. </del>  0-RTT messages sent in the first flight have the same content types as their corresponding messages sent in other flights (handshake,

Reviewer comments:
1) Switches uses of ALPN label/value to "ALPN protocol" (to clarify this is referring to a single protocol, not the entire extension) 2) Remove plural from external PSK case (if there's not way for the client to select which protocol the 0-RTT data uses, it doesn't make sense for there to be multiple options) 3) Switch reference from RFC7443 to RFC7301 (I assume this is what was intended) I think this makes the intended behavior of the spec a bit more clear.

Revised text:
handshake but reject 0-RTT, and SHOULD NOT take any other action that assumes that this ClientHello is fresh.  <ins> The parameters for the 0-RTT data (symmetric cipher suite, ALPN protocol, etc.) are the same as those which were negotiated in the connection which established the PSK.  The PSK used to encrypt the early data MUST be the first PSK listed in the client's "pre_shared_key" extension. </ins> 0-RTT messages sent in the first flight have the same content types as their corresponding messages sent in other flights (handshake,
Original text:
with a HelloRetryRequest.  A client MUST NOT include the "early_data" extension in its followup ClientHello. <del> In order to accept early data, the server server MUST have accepted a PSK cipher suite and selected the the first key offered in the client's "pre_shared_key" extension.  In addition, it MUST verify that the following values are consistent with those negotiated in the </del>  connection during which the ticket was established. The TLS version number, AEAD algorithm, and the hash for HKDF. <del> The selected ALPN RFC7443 value, if any. </del>  Future extensions MUST define their interaction with 0-RTT.

Reviewer comments:
1) Switches uses of ALPN label/value to "ALPN protocol" (to clarify this is referring to a single protocol, not the entire extension) 2) Remove plural from external PSK case (if there's not way for the client to select which protocol the 0-RTT data uses, it doesn't make sense for there to be multiple options) 3) Switch reference from RFC7443 to RFC7301 (I assume this is what was intended) I think this makes the intended behavior of the spec a bit more clear.

Revised text:
with a HelloRetryRequest.  A client MUST NOT include the "early_data" extension in its followup ClientHello.  <ins> In order to accept early data, the server MUST have accepted a PSK cipher suite and selected the first key offered in the client's "pre_shared_key" extension.  In addition, it MUST verify that the following values are consistent with those negotiated in the </ins> connection during which the ticket was established. The TLS version number, AEAD algorithm, and the hash for HKDF.  <ins> The selected ALPN RFC7301 protocol, if any. </ins> Future extensions MUST define their interaction with 0-RTT.
Original text:
application MAY opt to retransmit the data once the handshake has been completed.  TLS stacks SHOULD not do this automatically and client applications MUST take care that the negotiated parameters are <del> consistent with those it expected.  For example, if the ALPN value has changed, it is likely unsafe to retransmit the original </del>  application layer data. 4.2.9.1.

Reviewer comments:
1) Switches uses of ALPN label/value to "ALPN protocol" (to clarify this is referring to a single protocol, not the entire extension) 2) Remove plural from external PSK case (if there's not way for the client to select which protocol the 0-RTT data uses, it doesn't make sense for there to be multiple options) 3) Switch reference from RFC7443 to RFC7301 (I assume this is what was intended) I think this makes the intended behavior of the spec a bit more clear.

Revised text:
application MAY opt to retransmit the data once the handshake has been completed.  TLS stacks SHOULD not do this automatically and client applications MUST take care that the negotiated parameters are  <ins> consistent with those it expected.  For example, if the selected ALPN protocol has changed, it is likely unsafe to retransmit the original </ins> application layer data. 4.2.9.1.
Original text:
%%% Key Exchange Messages This field contains the version of TLS negotiated for this <del> session.  Servers MUST select the lower of the highest supported server version and the version offered by the client in the ClientHello.  In particular, servers MUST accept ClientHello messages with versions higher than those supported and negotiate the highest mutually supported version.  For this version of the specification, the version is 0x0304.  (See backward-compatibility for details about backward compatibility.) </del>  This structure is generated by the server and MUST be generated independently of the ClientHello.random.

Reviewer comments:
It seems section 4.1.3 Server Hello has not been updated to reflect the new version negotiation mechanism. says "servers says "servers MUST [...] negotiate the highest mutually supported version".
Thanks, I caught a few of these on my reread yesterday too, but I probably missed some too, so keep them coming!

Revised text:
%%% Key Exchange Messages This field contains the version of TLS negotiated for this  <ins> session.  Servers MUST select a version from the list in ClientHello.supported_versions extension.  A client which receives a version that was not offered MUST abort the handshake.  For this version of the specification, the version is 0x0304.  (See backward-compatibility for details about backward compatibility.) </ins> This structure is generated by the server and MUST be generated independently of the ClientHello.random.
Original text:
otherwise, a TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256 cipher <del> suites. </del>  A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for

Reviewer comments:
Just noticed that the MTI suites section didn't link to the suites, so here's a minor PR with some reference fiddling for this section: Add a link in MTI suites to the suites section, now that they're defined in this document. Nitpick ordering of extensions in MTI extensions to have them in same order as sections (so numbers in links are consistient). Change plaintext reference to appendices in Security Considerations to actual references.

Revised text:
otherwise, a TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256 cipher  <ins> suites. (see cipher-suites) </ins> A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for
Original text:
Supported Versions ("supported_versions"; supported-versions)  Signature Algorithms ("signature_algorithms"; signature- algorithms)

Reviewer comments:
Just noticed that the MTI suites section didn't link to the suites, so here's a minor PR with some reference fiddling for this section: Add a link in MTI suites to the suites section, now that they're defined in this document. Nitpick ordering of extensions in MTI extensions to have them in same order as sections (so numbers in links are consistient). Change plaintext reference to appendices in Security Considerations to actual references.

Revised text:
Supported Versions ("supported_versions"; supported-versions) <ins> Cookie ("cookie"; cookie) </ins> Signature Algorithms ("signature_algorithms"; signature- algorithms)
Original text:
Pre-Shared Key ("pre_shared_key"; pre-shared-key-extension) <del> Cookie ("cookie"; cookie) </del> Server Name Indication ("server_name"; Section 3 of RFC6066) All implementations MUST send and use these extensions when offering

Reviewer comments:
Just noticed that the MTI suites section didn't link to the suites, so here's a minor PR with some reference fiddling for this section: Add a link in MTI suites to the suites section, now that they're defined in this document. Nitpick ordering of extensions in MTI extensions to have them in same order as sections (so numbers in links are consistient). Change plaintext reference to appendices in Security Considerations to actual references.

Revised text:
Pre-Shared Key ("pre_shared_key"; pre-shared-key-extension)  Server Name Indication ("server_name"; Section 3 of RFC6066) All implementations MUST send and use these extensions when offering
Original text:
9. Security issues are discussed throughout this memo, especially in <del> Appendices B, C, and D. </del>  10.

Reviewer comments:
Just noticed that the MTI suites section didn't link to the suites, so here's a minor PR with some reference fiddling for this section: Add a link in MTI suites to the suites section, now that they're defined in this document. Nitpick ordering of extensions in MTI extensions to have them in same order as sections (so numbers in links are consistient). Change plaintext reference to appendices in Security Considerations to actual references.

Revised text:
9. Security issues are discussed throughout this memo, especially in  <ins> implementation-notes, backward-compatibility, and security-analysis. </ins> 10.
Original text:
The client uses the "signature_algorithms" extension to indicate to the server which signature algorithms may be used in digital <del> signatures.  Clients which desire the server to authenticate via a certificate MUST send this extension.  If a server is authenticating via a certificate and the client has not sent a </del>  "signature_algorithms" extension then the server MUST abort the handshake with a "missing_extension" alert (see mti-extensions).

Reviewer comments:
Adding "itself" makes the sentence much easier to understand. Actually, two Japanese, who are implementing TLS 1.3 independently, took a long time to understand this.

Revised text:
The client uses the "signature_algorithms" extension to indicate to the server which signature algorithms may be used in digital  <ins> signatures.  Clients which desire the server to authenticate itself via a certificate MUST send this extension.  If a server is authenticating via a certificate and the client has not sent a </ins> "signature_algorithms" extension then the server MUST abort the handshake with a "missing_extension" alert (see mti-extensions).
Original text:
prevents passive observers from correlating sessions unless tickets are reused.  Note: because ticket lifetimes are restricted to a week, 32 bits is enough to represent any plausible age, even <del> in milliseconds.  External tickets SHOULD use an obfuscated_ticket_age of 0; servers MUST ignore this value for external tickets. </del>  A list of the identities that the client is willing to negotiate with the server.  If sent alongside the "early_data" extension

Reviewer comments:
Ticket is a term that refers to a PSK identity established using an handshake. For out-of-band PSK, we do not use the term.

Revised text:
prevents passive observers from correlating sessions unless tickets are reused.  Note: because ticket lifetimes are restricted to a week, 32 bits is enough to represent any plausible age, even  <ins> in milliseconds.  For identities established externally an obfuscated_ticket_age of 0 SHOULD be used, and servers MUST ignore the value. </ins> A list of the identities that the client is willing to negotiate with the server.  If sent alongside the "early_data" extension
Original text:
length of the digest output.  This codepoint is also defined for use with TLS 1.2. <del> Indicates a signature algorithm using EdDSA as defined in I- D.irtf-cfrg-eddsa or its successors.  Note that these correspond to the "PureEdDSA" algorithms and not the "prehash" variants. </del>  rsa_pkcs1_sha1, dsa_sha1, and ecdsa_sha1 SHOULD NOT be offered. Clients offering these values for backwards compatibility MUST list

Reviewer comments:
draft_eddsa is now . sandj-tls-iana-registry-updates is now ietf-tls-iana-registry-updates.

Revised text:
length of the digest output.  This codepoint is also defined for use with TLS 1.2.  <ins> Indicates a signature algorithm using EdDSA as defined in RFC8032 or its successors.  Note that these correspond to the "PureEdDSA" algorithms and not the "prehash" variants. </ins> rsa_pkcs1_sha1, dsa_sha1, and ecdsa_sha1 SHOULD NOT be offered. Clients offering these values for backwards compatibility MUST list
Original text:
suites to the registry.  The "Value" and "Description" columns are taken from the table.  The "DTLS-OK" and "Recommended" columns are both marked as "Yes" for each new cipher suite.  [[This assumes I- <del> D.sandj-tls-iana-registry-updates has been applied.]] </del>  TLS ContentType Registry: Future values are allocated via Standards Action RFC5226.

Reviewer comments:
draft_eddsa is now . sandj-tls-iana-registry-updates is now ietf-tls-iana-registry-updates.

Revised text:
suites to the registry.  The "Value" and "Description" columns are taken from the table.  The "DTLS-OK" and "Recommended" columns are both marked as "Yes" for each new cipher suite.  [[This assumes I-  <ins> D.ietf-tls-iana-registry-updates has been applied.]] </ins> TLS ContentType Registry: Future values are allocated via Standards Action RFC5226.
Original text:
"encrypted_extensions", "end_of_early_data", "key_update", and "handshake_hash" values. <del> This document also uses a registry originally created in RFC4366. IANA has updated it to reference this document.  The registry and its allocation policy is listed below: </del>  IANA [SHALL update/has updated] this registry to include the "key_share", "pre_shared_key", "psk_key_exchange_modes",

Reviewer comments:
Need to be explicit say that it's the ExtensionType registry from RFC 4366.
I literally was making the same change in my editor when the notification came in! (Should it be the "TLS Extensions ExtensionType registry"?)

Revised text:
"encrypted_extensions", "end_of_early_data", "key_update", and "handshake_hash" values.  <ins> This document also uses the TLS ExtensionType Registry originally created in RFC4366.  IANA has updated it to reference this document. The registry and its allocation policy is listed below: </ins> IANA [SHALL update/has updated] this registry to include the "key_share", "pre_shared_key", "psk_key_exchange_modes",
Original text:
authorities). Servers which are authenticating with a PSK MUST NOT send the <del> CertificateRequest message. </del>  4.3.2.1.

Reviewer comments:
When we banned client auth and PSK, we only meant to do it for the main handshake, not the post-handshake phase. This reverts that change, as well as clarifies the prophibition on PSK plus cert-based auth.

Revised text:
authorities). Servers which are authenticating with a PSK MUST NOT send the  <ins> CertificateRequest message in the main handshake, though they MAY send it in post-handshake authentication (see post-handshake- authentication) provided that the client has sent the "post_handshake_auth" extension (see post_handshake_auth). </ins> 4.3.2.1.
Original text:
candidates, such as STUN and TURN. All of the candidates sent within an ICE session; these are the <del> candidates that are associated with a local/remote ufrag pair (which will change on ICE restart, if any). </del>  Any session-related (as opposed to candidate-related) attributes required to configure an ICE agent.  These include but are not

Reviewer comments:
Changed "media stream" to "media stream and component" in one place, and made some grammatical changes to the definition of an ICE generation.

Revised text:
candidates, such as STUN and TURN. All of the candidates sent within an ICE session; these are the  <ins> candidates that are associated with a specific local/remote ufrag pair (which will change on ICE restart, if any occurs). </ins> Any session-related (as opposed to candidate-related) attributes required to configure an ICE agent.  These include but are not
Original text:
Once the candidate has been sent to the remote party, the agent checks if any remote candidates are currently known for this same <del> stream.  If not, the new candidate will simply be added to the list of local candidates. </del>  Otherwise, if the agent has already learned of one or more remote candidates for this stream and component, it will begin pairing the

Reviewer comments:
Changed "media stream" to "media stream and component" in one place, and made some grammatical changes to the definition of an ICE generation.

Revised text:
Once the candidate has been sent to the remote party, the agent checks if any remote candidates are currently known for this same  <ins> stream and component.  If not, the new candidate will simply be added to the list of local candidates. </ins> Otherwise, if the agent has already learned of one or more remote candidates for this stream and component, it will begin pairing the
Original text:
The use of source control improves traceability and visibility of changes.  Issue tracking can be used to manage open issues and provide a record of their resolution.  Pull requests allow for better <del> engagement on technical and edditorial changes, and encourage </del>  contributions from a larger set of contributors.  Using GitHub can also broaden the community of contributors for a specification.

Reviewer comments:
A good start. Would you like to open another PR adding yourself as an author?
Let me know if what I created (experiences + author) needs to be something different. This is a very scary world for me. Ultra light description is next. Barbara

Revised text:
The use of source control improves traceability and visibility of changes.  Issue tracking can be used to manage open issues and provide a record of their resolution.  Pull requests allow for better  <ins> engagement on technical and editorial changes, and encourage </ins> contributions from a larger set of contributors.  Using GitHub can also broaden the community of contributors for a specification.
Original text:
Working Groups might integrate the capabilities provided by GitHub into their processes for developing Internet-Drafts. <del> This document is meant as an supplement to existing Working Group </del>  practices.  It provides guidance to Working Group chairs and participants on how they can best use GitHub within the framework <del> established RFC 2418 RFC2418.  The small number of rules in this </del>  document are there to ensure common usage patterns between working groups and to avoid issues that have been encountered in the past. A companion document, GH-CONFIG, describes administrative processes <del> that supports the practices described in this document. </del>  1.1.

Reviewer comments:
A good start. Would you like to open another PR adding yourself as an author?
Let me know if what I created (experiences + author) needs to be something different. This is a very scary world for me. Ultra light description is next. Barbara

Revised text:
Working Groups might integrate the capabilities provided by GitHub into their processes for developing Internet-Drafts.  <ins> This document is meant as a supplement to existing Working Group </ins> practices.  It provides guidance to Working Group chairs and participants on how they can best use GitHub within the framework  <ins> established by RFC 2418 RFC2418.  The small number of rules in this </ins> document are there to ensure common usage patterns between working groups and to avoid issues that have been encountered in the past. A companion document, GH-CONFIG, describes administrative processes  <ins> that support the practices described in this document. </ins> 1.1.
Original text:
the only possible choice for hosting.  There are other services that host revision control repositories and provide similar additional features to GitHub.  For instance, BitBucket [4], or GitLab [5] <del> provide a similar feature set.  In additional to a hosted service, </del>  software for custom installations exists. This document concentrates primarily on GitHub as it has a large and

Reviewer comments:
A good start. Would you like to open another PR adding yourself as an author?
Let me know if what I created (experiences + author) needs to be something different. This is a very scary world for me. Ultra light description is next. Barbara

Revised text:
the only possible choice for hosting.  There are other services that host revision control repositories and provide similar additional features to GitHub.  For instance, BitBucket [4], or GitLab [5]  <ins> provide a similar feature set.  In addition to a hosted service, </ins> software for custom installations exists. This document concentrates primarily on GitHub as it has a large and