jiebi/TextFlow huggingface dataset:
Original text:
output of AEAD_AES_128_GCM AEAD used with the following inputs: The secret key, K, is 128 bits equal to <del> 0xf5ed4642e0e4c8d878bbbc8a828821c9. </del>  <del> The nonce, N, is 96 bits all set to zero. </del>  The plaintext, P, is empty. The associated data, A, is the contents of the Retry Pseudo- Packet, as illustrated in retry-pseudo:  The Retry Pseudo-Packet is not sent over the wire.  It is computed by taking the transmitted Retry packet, removing the Retry Integrity Tag and prepending the two following fields:

Reviewer comments:
Just to set expectations, I think that I want to reserve the ability to pick new values for these. Just as there will be a new value for the Initial salt when we publish an RFC, this probably needs a new value at the same time.
Retry integrity protection () specifies the AES-GCM key and IV directly. While that works fine for people using TLS stacks that provide direct access to AES-GCM, it does not for people using TLS stacks that only provides access to TLS AEAD API. Previously, we have been consistent in using HKDF-Expand-Label in a specific way so that people could rely on the "TLS" stack generating AEAD contexts. I think we can resolve the concern by simply changing the hard-coded AES-GCM key and IV we specify in the TLS draft to a set of values that can be derived by using the TLS AEAD API.
It would be easier for me to do as NAME suggested, but the overall effort is small. I can live with either answer. Note that the additional indirection can be hard-coded out if people find they want to prime their AES directly. Of course, you don't need to run AES at all if you want to go that far.
I agree that this is not a must, even though it's about helping some of the implementations. I would highly appreciate it if you could merge the PR before -25 ships, as I think changing the default key before shipping the first draft that adopts the GCM-based Retry protection would have the least friction.
This is useful, and we should merge this. I don't think this needs to be design.
If this is the outcome, then this seems fine.I think this is useful -- we should merge this.

Revised text:
output of AEAD_AES_128_GCM AEAD used with the following inputs: The secret key, K, is 128 bits equal to  <ins> 0x4d32ecdb2a2133c841e4043df27d4430. </ins>  <ins> The nonce, N, is 96 bits equal to 0x4d1611d05513a552c587d575. </ins> The plaintext, P, is empty. The associated data, A, is the contents of the Retry Pseudo- Packet, as illustrated in retry-pseudo: <ins> The secret key and the nonce are values derived by calling HKDF- Expand-Label using 0x656e61e336ae9417f7f0edd8d78d461e2aa7084aba7a14c1e9f726d55709169a as the secret, with labels being "quic key" and "quic iv" (protection- keys). </ins> The Retry Pseudo-Packet is not sent over the wire.  It is computed by taking the transmitted Retry packet, removing the Retry Integrity Tag and prepending the two following fields:
Original text:
receiver within the maximum ack delay and are called ack-eliciting packets. <del> Packets that do not increase the largest received packet number for its packet number space by exactly one.  Packets arrive out of order when earlier packets are lost or delayed. </del> 3. All transmissions in QUIC are sent with a packet-level header, which CONNECTION_CLOSE.  These cause a recipient to send an acknowledgment (see sending-acknowledgements).  An entity that can participate in a QUIC connection by generating, receiving, and processing QUIC packets.  There are only two types of endpoint in QUIC: client and server.

Reviewer comments:
From recovery to transport.
currently states: NAME notes that nowhere do we define precisely how a receiver might do this detection. Specifically a receiver could implement this as when a newly received packet is smaller than the largest acked, or as when the packet is larger than largest acked plus one. Doing the former would actually not help with loss detection, since the receiver would not ack immediately on a gap. We should add some text codifying the latter.
That section used to be in recovery, where we have a definition already(which is now unused), so I'd suggest we move it over. "Out-of-order Packets: : Packets that do not increase the largest received packet number for its packet number space by exactly one. Packets arrive out of order when earlier packets are lost or delayed."
Isn't this supposed to be "Packets that increase the largest received packet number ... by more than one." in this case?
Thinking about this some more, there are three possible definitions here for out-of-order: a newly received packet is greater than largest received by more than one, a newly received packet is smaller than the largest received, both (1) and (2). (1) is the obvious case where a loss happens and a subsequent packet is received. (2) is the reordering case, where an earlier packet is delivered later, and while it does not indicate loss, it does indicate that a gap was filled. It's useful to signal (2) as well immediately to prevent a sender from unnecessarily retransmitting what it believes to be a missing packet. The definition we want for "out-of-order" is the one that is most useful for determining when to send an immediate ack. The definition in the PR captures both (1) and (2), and is probably the one we want.
NAME : If you believe we ought to change the definition, please re-open, and we can continue this discussion.
Thank you for working on this.

Revised text:
receiver within the maximum ack delay and are called ack-eliciting packets.  3. All transmissions in QUIC are sent with a packet-level header, which CONNECTION_CLOSE.  These cause a recipient to send an acknowledgment (see sending-acknowledgements). <ins> A packet that does not increase the largest received packet number for its packet number space by exactly one.  A packet can arrive out of order if it is delayed or if earlier packets are lost or delayed. </ins> An entity that can participate in a QUIC connection by generating, receiving, and processing QUIC packets.  There are only two types of endpoint in QUIC: client and server.
Original text:
All QUIC packets except Version Negotiation packets use authenticated encryption with additional data (AEAD) RFC5116 to provide <del> confidentiality and integrity protection.  Retry packets use an AEAD to provide integrity protection.  Details of packet protection are found in QUIC-TLS; this section includes an overview of the process. </del>  Initial packets are protected using keys that are statically derived. This packet protection is not effective confidentiality protection.

Reviewer comments:
Is "AEAD" a thing, or a descriptor? I read the original as "an AEAD [algorithm]", but this change seems to consider AEAD as a technique which can be applied.
I modeled this on the previous sentence that says (italics added): Note the absence of "an" in front of the italicized text. The "AEAD" in the second sentence is simply another way to write "authenticated encryption with additional data."

Revised text:
All QUIC packets except Version Negotiation packets use authenticated encryption with additional data (AEAD) RFC5116 to provide  <ins> confidentiality and integrity protection.  Retry packets use AEAD to provide integrity protection.  Details of packet protection are found in QUIC-TLS; this section includes an overview of the process. </ins> Initial packets are protected using keys that are statically derived. This packet protection is not effective confidentiality protection.
Original text:
the token provided in a Retry for future connections.  Servers MAY discard any Initial packet that does not carry the expected token. <del> Unlike the token that is created for a Retry packet, there might be some time between when the token is created and when the token is subsequently used.  Thus, a token SHOULD have an expiration time, which could be either an explicit expiration time or an issued timestamp that can be used to dynamically calculate the expiration time.  A server can store the expiration time or include it in an encrypted form in the token. </del>  A token issued with NEW_TOKEN MUST NOT include information that would allow values to be linked by an on-path observer to the connection on 13.2.5. <del> An endpoint measures the delays intentionally introduced between when the packet with the largest packet number is received and an acknowledgment is sent.  The endpoint encodes this delay in the Ack Delay field of an ACK frame (see frame-ack).  This allows the </del>  receiver of the ACK to adjust for any intentional delays, which is important for getting a better estimate of the path RTT when acknowledgments are delayed.  A packet might be held in the OS kernel

Reviewer comments:
Fixes issue .
The wording "between when ... and when..." or "between when ... and ..." is odd. There are two instances of this in .
Fixed by .
Not critical, perhaps, but I agree that this is less awkward.

Revised text:
the token provided in a Retry for future connections.  Servers MAY discard any Initial packet that does not carry the expected token.  <ins> Unlike the token that is created for a Retry packet, which is used immediately, the token sent in the NEW_TOKEN frame might be used after some period of time has passed.  Thus, a token SHOULD have an expiration time, which could be either an explicit expiration time or an issued timestamp that can be used to dynamically calculate the expiration time.  A server can store the expiration time or include it in an encrypted form in the token. </ins> A token issued with NEW_TOKEN MUST NOT include information that would allow values to be linked by an on-path observer to the connection on 13.2.5.  <ins> An endpoint measures the delays intentionally introduced between the time the packet with the largest packet number is received and the time an acknowledgment is sent.  The endpoint encodes this delay in the Ack Delay field of an ACK frame (see frame-ack).  This allows the </ins> receiver of the ACK to adjust for any intentional delays, which is important for getting a better estimate of the path RTT when acknowledgments are delayed.  A packet might be held in the OS kernel
Original text:
1. <del> QUIC is a new multiplexed and secure transport atop UDP.  QUIC builds on decades of transport and security experience, and implements mechanisms that make it attractive as a modern general-purpose transport.  The QUIC protocol is described in QUIC-TRANSPORT. QUIC implements the spirit of existing TCP congestion control and </del>  loss recovery mechanisms, described in RFCs, various Internet-drafts, <del> and also those prevalent in the Linux TCP implementation.  This document describes QUIC congestion control and loss recovery, and where applicable, attributes the TCP equivalent in RFCs, Internet- drafts, academic papers, and/or TCP implementations. </del>  2.

Reviewer comments:
Just a proposal but I would prefer to remove the advertising slang ("decades of transport and security experience" and "makes it attractive").
Isn't the introduction the right place for ad copy, though? It describes what the document hopes to achieve and why it's worth doing. I think some of the rewording you've done here is an improvement, but I'm not convinced we should edit out the fact that we're trying to incorporate many years of work that hasn't been universally deployable.
I'm fine with this new language.

Revised text:
1.  <ins> QUIC is a new multiplexed and secure transport protocol atop UDP, specified in QUIC-TRANSPORT.  This document describes congestion control and loss recovery for QUIC.  Mechanisms described in this document follow the spirit of existing TCP congestion control and </ins> loss recovery mechanisms, described in RFCs, various Internet-drafts,  <ins> or academic papers, and also those prevalent in TCP implementations. </ins> 2.
Original text:
Definitions of terms that are used in this document: <del> Any packet containing only one or more ACK frame(s). Packets are considered in-flight when they have been sent and are not ACK-only, and they are not acknowledged, declared lost, or abandoned along with old keys. </del> All frames other than ACK, PADDING, and CONNECTION_CLOSE are considered ack-eliciting. receiver within the maximum ack delay and are called ack-eliciting packets.  3. All transmissions in QUIC are sent with a packet-level header, which

Reviewer comments:
ACK-only was only even used in the definition part and in-flight can also be defined using ack-eliciting.
I just realised that padding is the "complicating" thing here. I still don't think we need to define "act-only" just for that but can rather be explicit about padding frames because otherwise this is easy to miss (as I did initially).
While the defined term is not used elsewhere, the phrases "Packets containing only ACK frames" and "Packets only containing ACK frames" are used. We should either eliminate the definition or explicitly use the defined term in those places.
Of Mike's options, I think that this makes sense. Fewer defined terms means lower fixed cognitive load when reading this. Less jargon = good.I re-read the other spots NAME mentioned and I believe the text is still correct, so I'm going to accept this. Thanks for the simplification.

Revised text:
Definitions of terms that are used in this document:  All frames other than ACK, PADDING, and CONNECTION_CLOSE are considered ack-eliciting. receiver within the maximum ack delay and are called ack-eliciting packets. <ins> Packets are considered in-flight when they are ack-eliciting or contain a PADDING frame, and they have been sent but are not acknowledged, declared lost, or abandoned along with old keys. </ins> 3. All transmissions in QUIC are sent with a packet-level header, which
Original text:
An RTT sample MUST NOT be generated on receiving an ACK frame that does not newly acknowledge at least one ack-eliciting packet.  A peer <del> does not send an ACK frame on receiving only non-ack-eliciting packets, so an ACK frame that is subsequently sent can include an arbitrarily large Ack Delay field.  Ignoring such ACK frames avoids </del>  complications in subsequent smoothed_rtt and rttvar computations. A sender might generate multiple RTT samples per RTT when multiple

Reviewer comments:
So here is an alternative proposal. However I also wonder why this paragraph is a MUST requirement while the previous statement (avoiding multiple samples of the same packet) is only a SHOULD? I would see it rather the other way around or both MUSTs.
This is a great improvement, thanks. One additional suggestion (for existing text) below.

Revised text:
An RTT sample MUST NOT be generated on receiving an ACK frame that does not newly acknowledge at least one ack-eliciting packet.  A peer  <ins> usually does not send an ACK frame when only non-ack-eliciting packets are received.  Therefore an ACK frame that contains acknowledgements for only non-ack-eliciting packets could include an arbitrarily large Ack Delay value.  Ignoring such ACK frames avoids </ins> complications in subsequent smoothed_rtt and rttvar computations. A sender might generate multiple RTT samples per RTT when multiple
Original text:
When an ack-eliciting packet is transmitted, the sender schedules a timer for the PTO period as follows: <del> kGranularity, smoothed_rtt, rttvar, and max_ack_delay are defined in ld-consts-of-interest and ld-vars-of-interest. </del> The PTO period is the amount of time that a sender ought to wait for an acknowledgement of a sent packet.  This time period includes the estimated network roundtrip-time (smoothed_rtt), the variation in the

Reviewer comments:
I proposed to remove this sentence here because all these values have actually been just defined in the previous sections. If a pointer to the appendix is desired, I think that should be mentioned earlier (e.g. in the intro already) that these lists existing in the appendix.
This seems fine to me, but I'd like NAME opinion as well.

Revised text:
When an ack-eliciting packet is transmitted, the sender schedules a timer for the PTO period as follows:  The PTO period is the amount of time that a sender ought to wait for an acknowledgement of a sent packet.  This time period includes the estimated network roundtrip-time (smoothed_rtt), the variation in the
Original text:
The life of a connection that is experiencing consecutive PTOs is limited by the endpoint's idle timeout. <del> The probe timer is not set if the time threshold time-threshold loss detection timer is set.  The time threshold loss detection timer is expected to both expire earlier than the PTO and be less likely to </del>  spuriously retransmit data. 5.3.

Reviewer comments:
I think this statement should be normative. Not sure if this is a design issue or not.
I'm comfortable with this being editorial.

Revised text:
The life of a connection that is experiencing consecutive PTOs is limited by the endpoint's idle timeout.  <ins> The probe timer MUST NOT be set if the time threshold time-threshold loss detection timer is set.  The time threshold loss detection timer is expected to both expire earlier than the PTO and be less likely to </ins> spuriously retransmit data. 5.3.
Original text:
packet; the client has to rely on the exchange that included the Retry packet for that property. <del> test-vectors-initial contains test vectors for the initial packet encryption. </del>  5.3.

Reviewer comments:
Can someone please verify my work? I've written two implementations here and the values match, but I value independent validation.
NAME The value matches what quic-go is calculating. Will add this test vector as a unit test to my implementation.
Woo! I'm not as bad at this as I thought. Thanks NAME
I can also confirm that it verifies in Wireshark. (Likewise for the samples in Appendix A.)
The Retry integrity check is different than the protection for other packets, so it would make sense to include an example in the document. We need code for it in addition to the sample so that it can be updated more readily.
I also tested these vectors and it works fine. Thanks!

Revised text:
packet; the client has to rely on the exchange that included the Retry packet for that property.  <ins> test-vectors contains test vectors for packet encryption. </ins> 5.3.
Original text:
17.2. Long headers are used for packets that are sent prior to the <del> establishment of 1-RTT keys.  Once both conditions are met, a sender </del>  switches to sending packets using the short header (short-header). The long form allows for special packets - such as the Version Negotiation packet - to be represented in this uniform fixed-length

Reviewer comments:
URL What are these "both conditions"? Also, can there be made a clear statement such that: all packets prior to Application PN space use long headers, and all packets in application PN space uses short headers? And, the table of frames with section references, would it make sense to add PN space columns with an X where a frame is applicable?
Multiple issues listed here. Please consider opening separate issues rather than lumping them all together. (1) This is old language we agreed to in Chicago. The requirement to shift to short headers was 1-RTT key availability and version agreement, to accommodate versions where the final keys might be available immediately (i.e. out-of-band agreement) but version negotiation still had to complete. However, that's a principle for the invariants or such a version, not a requirement of this QUIC version -- and the version negotiation language this referenced is gone now. (2) What is "Application PN space"? 0-RTT and 1-RTT? If so, then no -- 0-RTT packets carry application data but are long-header packets. (3) Unrelated editorial suggestion -- please open a separate issue.
(3) see

Revised text:
17.2. Long headers are used for packets that are sent prior to the  <ins> establishment of 1-RTT keys.  Once 1-RTT keys are available, a sender </ins> switches to sending packets using the short header (short-header). The long form allows for special packets - such as the Version Negotiation packet - to be represented in this uniform fixed-length
Original text:
which can allow for better stream prioritization. The sending part of a bidirectional stream initiated by a peer (type <del> 0 for a server, type 1 for a client) enters the "Ready" state then immediately transitions to the "Send" state if the receiving part enters the "Recv" state (stream-recv-states). </del>  In the "Send" state, an endpoint transmits - and retransmits as necessary - stream data in STREAM frames.  The endpoint respects the

Reviewer comments:
The description here was a little over enthusiastic: it only enters the "Send" state when something is sent.
From -transport section 3.1: The event causing transition Ready->Send is the host initially having data to send on the stream, which is not the case when the receiving part has just been created in its initial Recv state. I think the send stream should stay in Ready until it has data. This also aligns better with similar text in 3.2. I suggest: p.s. see also , but which is more about being explicit about frames that cause stream creation... rather than this issue, which is about the state the new sending part starts in.
This issue can be closed -- see NAME commit above.
That commit hasn't been merged, and is sitting in a branch that doesn't appear to have an associated PR.
Oh -- sorry about that. I should have checked.
Wow, that sat there for ages. I made a PR.

Revised text:
which can allow for better stream prioritization. The sending part of a bidirectional stream initiated by a peer (type  <ins> 0 for a server, type 1 for a client) starts in the "Ready" state when the receiving part is created. </ins> In the "Send" state, an endpoint transmits - and retransmits as necessary - stream data in STREAM frames.  The endpoint respects the
Original text:
encoded in network byte order.  The CID Length field contains the length of the Connection ID field. <del> The maximum number of connection IDs from the peer that an endpoint is willing to store.  This value includes the connection ID received during the handshake, that received in the preferred_address transport parameter, and those received in NEW_CONNECTION_ID frames.  Unless a zero-length connection ID is being used, the value of the active_connection_id_limit parameter MUST be no less than 2.  If this transport parameter is absent, a default of 2 is assumed.  When a zero-length connection ID is being used, the active_connection_id_limit parameter MUST NOT be sent. </del>  If present, transport parameters that set initial flow control limits (initial_max_stream_data_bidi_local,

Reviewer comments:
Unlike the other transport parameter definitions, there is no type specified for the parameter. I will assume that the type is an integer (like the other numeric-like transport parameters) and submit a PR to adjust the wording so that it is in line with the other transport parameter descriptions, if that's ok? Thanks for all the great work that you are all doing on getting QUIC specified!
Good catch! Looks like all the other values have a type either implicitly or explicitly stated. is indeed intended to be an integer, a PR to that effect would be great.
Thanks NAME

Revised text:
encoded in network byte order.  The CID Length field contains the length of the Connection ID field.  <ins> The active connection ID limit is an integer value specifying the maximum number of connection IDs from the peer that an endpoint is willing to store.  This value includes the connection ID received during the handshake, that received in the preferred_address transport parameter, and those received in NEW_CONNECTION_ID frames.  Unless a zero-length connection ID is being used, the value of the active_connection_id_limit parameter MUST be no less than 2.  If this transport parameter is absent, a default of 2 is assumed.  When a zero-length connection ID is being used, the active_connection_id_limit parameter MUST NOT be sent. </ins> If present, transport parameters that set initial flow control limits (initial_max_stream_data_bidi_local,