jiebi/TextFlow huggingface dataset:
Original text:
Upon receipt of a HelloRetryRequest, the client MUST verify that the extensions block is not empty and otherwise MUST abort the handshake <del> with a "decode_error" alert.  Clients SHOULD abort the handshake with an "unexpected message" if the HelloRetryRequest would not result in any change in the ClientHello or in response to any second HelloRetryRequest which was sent in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest). </del>  Otherwise, the client MUST process all extensions in the HelloRetryRequest and send a second updated ClientHello.  The

Reviewer comments:
On Tuesday, October 11, 2016 08:14:32 pm Martin Thomson wrote: or missing_extension
I think that missingextension would be OK, but we would hit the lower-level decodeerror first, since HRR is defined with:

Revised text:
Upon receipt of a HelloRetryRequest, the client MUST verify that the extensions block is not empty and otherwise MUST abort the handshake  <ins> with a "decode_error" alert.  Clients MUST abort the handshake with an "illegal_parameter" alert if the HelloRetryRequest would not result in any change in the ClientHello.  If a client receives a second HelloRetryRequest in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest), it MUST abort the handshake with an "unexpected_message" alert. </ins> Otherwise, the client MUST process all extensions in the HelloRetryRequest and send a second updated ClientHello.  The
Original text:
Fields and variables may be assigned a fixed value using "=", as in: <del> 3.7.1. </del>  Defined structures may have variants based on some knowledge that is available within the environment.  The selector must be an enumerated

Reviewer comments:
Variants is not a subsection of Constants; just have them all be subsections of same depth within Presentation Language URL

Revised text:
Fields and variables may be assigned a fixed value using "=", as in:  <ins> 3.8. </ins> Defined structures may have variants based on some knowledge that is available within the environment.  The selector must be an enumerated
Original text:
For example: <del> 3.8. </del>  TLS defines two generic alerts (see alert-protocol) to use upon failure to parse a message.  Peers which receive a message which

Reviewer comments:
Variants is not a subsection of Constants; just have them all be subsections of same depth within Presentation Language URL

Revised text:
For example:  <ins> 3.9. </ins> TLS defines two generic alerts (see alert-protocol) to use upon failure to parse a message.  Peers which receive a message which
Original text:
The certificate and signing key to be used. <del> A Handshake Context based on the hash of the handshake messages </del>  A base key to be used to compute a MAC key.

Reviewer comments:
The handshake context here is just the transcript of the handshake messages, not the hash of the transcript. The language makes it seem like the authentication messages are Hash(Hash(handshake messages) + Certificate), etc.

Revised text:
The certificate and signing key to be used.  <ins> A Handshake Context based on the transcript of the handshake messages </ins> A base key to be used to compute a MAC key.
Original text:
in the cookie, rather than requiring it to export the entire intermediate hash state (see cookie).  In general, implementations can implement the transcript by keeping a running transcript hash value based on the negotiated hash.  Note, however, that subsequent post-handshake authentications do not

Reviewer comments:
Move the list to the new transcript hash section. Note that EndOfEarlyData goes in the client Handshake Context.
lgtm

Revised text:
in the cookie, rather than requiring it to export the entire intermediate hash state (see cookie). <ins> For concreteness, the transcript hash is always taken from the following sequence of handshake messages, starting at the first ClientHello and including only those messages that were sent: ClientHello, HelloRetryRequest, ClientHello, ServerHello, EncryptedExtensions, Server CertificateRequest, Server Certificate, Server CertificateVerify, Server Finished, EndOfEarlyData, Client Certificate, Client CertificateVerify, Client Finished. </ins> In general, implementations can implement the transcript by keeping a running transcript hash value based on the negotiated hash.  Note, however, that subsequent post-handshake authentications do not
Original text:
Secret is called with four distinct transcripts; in a 1-RTT-only exchange with three distinct transcripts. <del> The complete transcript passed to Derive-Secret is always taken from the following sequence of handshake messages, starting at the first ClientHello and including only those messages that were sent: ClientHello, HelloRetryRequest, ClientHello, ServerHello, EncryptedExtensions, Server CertificateRequest, Server Certificate, Server CertificateVerify, Server Finished, EndOfEarlyData, Client Certificate, Client CertificateVerify, Client Finished. </del> If a given secret is not available, then the 0-value consisting of a string of Hash.length zero bytes is used.  Note that this does not mean skipping rounds, so if PSK is not in use Early Secret will still

Reviewer comments:
Move the list to the new transcript hash section. Note that EndOfEarlyData goes in the client Handshake Context.
lgtm

Revised text:
Secret is called with four distinct transcripts; in a 1-RTT-only exchange with three distinct transcripts.  If a given secret is not available, then the 0-value consisting of a string of Hash.length zero bytes is used.  Note that this does not mean skipping rounds, so if PSK is not in use Early Secret will still
Original text:
Add "post_handshake_auth" extension to negotiate post-handshake authentication (*).  draft-19 Hash context_value input to Exporters (*)

Reviewer comments:
Per mailing list discussion, this allows us to have every HKDF-Expand just have one hash block of info. NAME would love your feedback.
Shouldn't "TLS 1.3, " be shortened to "tls13 "? Without that, several of the labels would seem to blow blocks. Also, "derived secret" seems unchanged, and is too long to fit into a block, even with "tls13 " prefix.
Oops. Good catch. Script fail.
NAME fixed?
Yeah, I'll add a note. I still have an issue for the ChangeLog so I will add this as well
Also, minimum label size looks to be still 10, presumably should be 7 with 6-byte prefix (as it 10 with 9-byte prefix).

Revised text:
Add "post_handshake_auth" extension to negotiate post-handshake authentication (*). <ins> Shorten labels for HKDF-Expand-Label so that we can fit within one compression block (*). </ins> draft-19 Hash context_value input to Exporters (*)
Original text:
layer headers.  Note that in some cases a zero-length HashValue (indicated by "") is passed to HKDF-Expand-Label.  Given a set of n InputSecrets, the final "master secret" is computed by iteratively invoking HKDF-Extract with InputSecret_1, InputSecret_2, etc.  The initial secret is simply a string of

Reviewer comments:
Per mailing list discussion, this allows us to have every HKDF-Expand just have one hash block of info. NAME would love your feedback.
Shouldn't "TLS 1.3, " be shortened to "tls13 "? Without that, several of the labels would seem to blow blocks. Also, "derived secret" seems unchanged, and is too long to fit into a block, even with "tls13 " prefix.
Oops. Good catch. Script fail.
NAME fixed?
Yeah, I'll add a note. I still have an issue for the ChangeLog so I will add this as well
Also, minimum label size looks to be still 10, presumably should be 7 with 6-byte prefix (as it 10 with 9-byte prefix).

Revised text:
layer headers.  Note that in some cases a zero-length HashValue (indicated by "") is passed to HKDF-Expand-Label. <ins> Note: with common hash functions, any label longer than 12 characters requires an additional iteration of the hash function to compute. The labels in this specification have all been chosen to fit within this limit. </ins> Given a set of n InputSecrets, the final "master secret" is computed by iteratively invoking HKDF-Extract with InputSecret_1, InputSecret_2, etc.  The initial secret is simply a string of
Original text:
mean skipping rounds, so if PSK is not in use Early Secret will still be HKDF-Extract(0, 0).  For the computation of the binder_secret, the label is "external psk binder key" for external PSKs (those <del> provisioned outside of TLS) and "resumption psk binder key" for resumption PSKs (those provisioned as the resumption master secret of a previous handshake).  The different labels prevent the substitution of one type of PSK for the other. </del>  There are multiple potential Early Secret values depending on which PSK the server ultimately selects.  The client will need to compute

Reviewer comments:
Per mailing list discussion, this allows us to have every HKDF-Expand just have one hash block of info. NAME would love your feedback.
Shouldn't "TLS 1.3, " be shortened to "tls13 "? Without that, several of the labels would seem to blow blocks. Also, "derived secret" seems unchanged, and is too long to fit into a block, even with "tls13 " prefix.
Oops. Good catch. Script fail.
NAME fixed?
Yeah, I'll add a note. I still have an issue for the ChangeLog so I will add this as well
Also, minimum label size looks to be still 10, presumably should be 7 with 6-byte prefix (as it 10 with 9-byte prefix).

Revised text:
mean skipping rounds, so if PSK is not in use Early Secret will still be HKDF-Extract(0, 0).  For the computation of the binder_secret, the label is "external psk binder key" for external PSKs (those  <ins> provisioned outside of TLS) and "res binder" for resumption PSKs (those provisioned as the resumption master secret of a previous handshake).  The different labels prevent the substitution of one type of PSK for the other. </ins> There are multiple potential Early Secret values depending on which PSK the server ultimately selects.  The client will need to compute
Original text:
Organizations are a way of forming groups of contributors on GitHub. Each Working Group SHOULD create a new organization for the working <del> group. A working group organization SHOULD be named consistently so that it can be found.  For instance, the name could be ietf-<wgname> or ietf- <wgname>-wg. </del>  A single organization SHOULD NOT be used for all IETF activity, or all activity within an area.  Large organizations create too much

Reviewer comments:
I was tempted to remove the entire section on administrative policies, though left it as is. NAME what do you think?
Yeah, I figured it best to start small. Let me know if you need anything else before merging!
NAME Interesting that the circle CI build ran on the merge, but not the PR. I didn't see any build failures reported before it merged, but I just got the email reporting a missed reference. Maybe there are some tweaks you need to apply over there as owner of the org.
Yeah, I'll fix it. Thanks for letting me know!
I was thinking of being a little more aggressive about removing some of the text, with matching PRs for the other work, but this works.

Revised text:
Organizations are a way of forming groups of contributors on GitHub. Each Working Group SHOULD create a new organization for the working  <ins> group.  A working group organization SHOULD be named consistently so that it can be found.  For instance, the name could be ietf-<wgname> or ietf-<wgname>-wg. </ins> A single organization SHOULD NOT be used for all IETF activity, or all activity within an area.  Large organizations create too much
Original text:
to all repositories and ownership does not grant any other significant privileges. <del> When Area Directors or Working Group Chairs change, teams MUST be updated to reflect the new membership status. When a Working Group is closed, the responsible Area Director is responsible for removing existing members from teams in the organization.  Repositories MUST be updated along to indicate that they are no longer under development. </del>  2.2. <del> When an IETF Working Group is closed or when associated mailing lists are closed, mail archives and datatracker information from that work is backed up and accessible.  The same applies to GitHub repositories. Any repositories including issues and discussion SHOULD be backed up on IETF resources.  It is desirable for those to be accessible via the Working Group's datatracker page.  For example, this might be via URLs listed in the More Info section on the Working Group Charter page. The IETF MAY decide to backup information associated with a Working Group's organization periodically.  This decision can be made differently per Working Group in consultation with the responsible Area Director. 2.3. </del> Each Working Group MAY set its own policy as to whether and how it uses GitHub.  It is important that occasional participants in the WG and others accustomed to IETF tools be able to determine this and

Reviewer comments:
I was tempted to remove the entire section on administrative policies, though left it as is. NAME what do you think?
Yeah, I figured it best to start small. Let me know if you need anything else before merging!
NAME Interesting that the circle CI build ran on the merge, but not the PR. I didn't see any build failures reported before it merged, but I just got the email reporting a missed reference. Maybe there are some tweaks you need to apply over there as owner of the org.
Yeah, I'll fix it. Thanks for letting me know!
I was thinking of being a little more aggressive about removing some of the text, with matching PRs for the other work, but this works.

Revised text:
to all repositories and ownership does not grant any other significant privileges.  <ins> Details about creating organizations adhering to these guidelines can be found in GIT-CONFIG. </ins> 2.2.  Each Working Group MAY set its own policy as to whether and how it uses GitHub.  It is important that occasional participants in the WG and others accustomed to IETF tools be able to determine this and
Original text:
to those mailing lists should be given.  An example of this is at https://datatracker.ietf.org/wg/quic/charter/. <del> 2.3.1. One important policy is the IETF IPR policy (see RFC5378, RFC3979, and RFC4879).  Part of this policy requires making contributors aware of the policy. The IETF Trust license file for open source repositories [5] MUST be included prominently in any document repository. Including this information in the CONTRIBUTING file is sufficient. In addition to the boilerplate text there can be a benefit to including pointers to other working group materials, the IETF datatracker, specific drafts, or websites.  Adding such text is at the discretion of the Working Group Chairs. </del> 3. A Working Group Chairs are responsible for determining how to best

Reviewer comments:
I was tempted to remove the entire section on administrative policies, though left it as is. NAME what do you think?
Yeah, I figured it best to start small. Let me know if you need anything else before merging!
NAME Interesting that the circle CI build ran on the merge, but not the PR. I didn't see any build failures reported before it merged, but I just got the email reporting a missed reference. Maybe there are some tweaks you need to apply over there as owner of the org.
Yeah, I'll fix it. Thanks for letting me know!
I was thinking of being a little more aggressive about removing some of the text, with matching PRs for the other work, but this works.

Revised text:
to those mailing lists should be given.  An example of this is at https://datatracker.ietf.org/wg/quic/charter/.  3. A Working Group Chairs are responsible for determining how to best
Original text:
An alternative is to rely on periodic email summaries of activity, such as those produced by a notification tool like github-notify-ml <del> [6].  This tool has been used effectively in several working groups, </del>  though it requires server infrastructure. A working group that uses GitHub MAY provide either facility at the

Reviewer comments:
I was tempted to remove the entire section on administrative policies, though left it as is. NAME what do you think?
Yeah, I figured it best to start small. Let me know if you need anything else before merging!
NAME Interesting that the circle CI build ran on the merge, but not the PR. I didn't see any build failures reported before it merged, but I just got the email reporting a missed reference. Maybe there are some tweaks you need to apply over there as owner of the org.
Yeah, I'll fix it. Thanks for letting me know!
I was thinking of being a little more aggressive about removing some of the text, with matching PRs for the other work, but this works.

Revised text:
An alternative is to rely on periodic email summaries of activity, such as those produced by a notification tool like github-notify-ml  <ins> [5].  This tool has been used effectively in several working groups, </ins> though it requires server infrastructure. A working group that uses GitHub MAY provide either facility at the
Original text:
[4] https://about.gitlab.com/ <del> [5] https://trustee.ietf.org/license-for-open-source- repositories.html [6] https://github.com/dontcallmedom/github-notify-ml </del> 

Reviewer comments:
I was tempted to remove the entire section on administrative policies, though left it as is. NAME what do you think?
Yeah, I figured it best to start small. Let me know if you need anything else before merging!
NAME Interesting that the circle CI build ran on the merge, but not the PR. I didn't see any build failures reported before it merged, but I just got the email reporting a missed reference. Maybe there are some tweaks you need to apply over there as owner of the org.
Yeah, I'll fix it. Thanks for letting me know!
I was thinking of being a little more aggressive about removing some of the text, with matching PRs for the other work, but this works.

Revised text:
[4] https://about.gitlab.com/  <ins> [5] https://github.com/dontcallmedom/github-notify-ml </ins>
Original text:
much later - in that scenario one endpoint might be aware of the compatibility document while the other may not. <del> When a client creates a QUIC connection, its goal is to use an application layer protocol.  Therefore, when considering which versions are compatible, clients will only consider versions that support one of the intended application layer protocols.  For example, if the client's first flight advertises multiple Application Layer Protocol Negotiation (ALPN) ALPN tokens and multiple compatible versions, the server needs to ensure that the ALPN token that it selects can run over the QUIC version that it selects. </del> 2.3. When the server can parse the client's first flight using the

Reviewer comments:
Can an ALPN label be used for multiple QUIC versions? I think that the text should say something like: NAME adds (and I wholly agree):
I'm merging into this one where NAME said "The point is that your ALPN offer when you offer QUICvX shouldn't be dependent on if you did VN or not."
LGTM

Revised text:
much later - in that scenario one endpoint might be aware of the compatibility document while the other may not.  2.3. When the server can parse the client's first flight using the
Original text:
6.  In order to facilitate the deployment of future versions of QUIC, designers of future versions SHOULD attempt to design their new version such that commonly deployed versions are compatible with it.

Reviewer comments:
Can an ALPN label be used for multiple QUIC versions? I think that the text should say something like: NAME adds (and I wholly agree):
I'm merging into this one where NAME said "The point is that your ALPN offer when you offer QUICvX shouldn't be dependent on if you did VN or not."
LGTM

Revised text:
6. <ins> When a client creates a QUIC connection, its goal is to use an application layer protocol.  Therefore, when considering which versions are compatible, clients will only consider versions that support one of the intended application layer protocols.  If the client's first flight advertises multiple Application Layer Protocol Negotiation (ALPN) ALPN tokens and multiple compatible versions, it is possible for some application layer protocols to not be able to run over some of the offered compatible versions.  It is the server's responsibility to only select an ALPN token that can run over the compatible QUIC version that it selects. A given ALPN token MUST NOT be used with a new QUIC version different from the version for which the ALPN token was originally defined, unless all the following requirements are met: The new QUIC version supports the transport features required by the application protocol. The new QUIC version supports ALPN. The version of QUIC for which the ALPN token was originally defined is compatible with the new QUIC version. When incompatible version negotiation is in use, the second connection which is created in response to the received version negotiation packet MUST restart its application layer protocol negotiation process without taking into account the original version. 7. </ins> In order to facilitate the deployment of future versions of QUIC, designers of future versions SHOULD attempt to design their new version such that commonly deployed versions are compatible with it.
Original text:
widely deployed, this section discusses considerations for future versions to help with compatibility with QUIC version 1. <del> 6.1. </del>  QUIC version 1 features Retry packets, which the server can send to validate the client's IP address before parsing the client's first

Reviewer comments:
Can an ALPN label be used for multiple QUIC versions? I think that the text should say something like: NAME adds (and I wholly agree):
I'm merging into this one where NAME said "The point is that your ALPN offer when you offer QUICvX shouldn't be dependent on if you did VN or not."
LGTM

Revised text:
widely deployed, this section discusses considerations for future versions to help with compatibility with QUIC version 1.  <ins> 7.1. </ins> QUIC version 1 features Retry packets, which the server can send to validate the client's IP address before parsing the client's first
Original text:
handshake even though the Retry itself was sent using the original version. <del> 6.2. </del>  QUIC version 1 uses TLS 1.3, which supports session resumption by sending session tickets in one connection that can be used in a later

Reviewer comments:
Can an ALPN label be used for multiple QUIC versions? I think that the text should say something like: NAME adds (and I wholly agree):
I'm merging into this one where NAME said "The point is that your ALPN offer when you offer QUICvX shouldn't be dependent on if you did VN or not."
LGTM

Revised text:
handshake even though the Retry itself was sent using the original version.  <ins> 7.2. </ins> QUIC version 1 uses TLS 1.3, which supports session resumption by sending session tickets in one connection that can be used in a later
Original text:
of QUIC; i.e., require that clients not use them across multiple version and that servers validate this client requirement. <del> 6.3. </del>  QUIC version 1 allows sending data from the client to the server during the handshake, by using 0-RTT packets.  If a future document

Reviewer comments:
Can an ALPN label be used for multiple QUIC versions? I think that the text should say something like: NAME adds (and I wholly agree):
I'm merging into this one where NAME said "The point is that your ALPN offer when you offer QUICvX shouldn't be dependent on if you did VN or not."
LGTM

Revised text:
of QUIC; i.e., require that clients not use them across multiple version and that servers validate this client requirement.  <ins> 7.3. </ins> QUIC version 1 allows sending data from the client to the server during the handshake, by using 0-RTT packets.  If a future document