jiebi/TextFlow huggingface dataset:
Original text:
the server is not overly constrained by the amplification restriction. <del> Packet loss, in particular loss of a Handshake packet from the server, can cause a situation in which the server cannot send when the client has no data to send and the anti-amplification limit is reached.  In order to avoid this causing a handshake deadlock, clients MUST send a packet upon a probe timeout, as described in QUIC-RECOVERY.  If the client has no data to retransmit and does not have Handshake keys, it MUST send an Initial packet in a UDP datagram of at least 1200 bytes.  If the client has Handshake keys, it SHOULD send a Handshake packet. </del>  A server might wish to validate the client address before starting the cryptographic handshake.  QUIC uses a token in the Initial packet

Reviewer comments:
Clarifies why a client might send a Handshake packet, as well as improving the surrounding anti-deadlock text. Changes 2 SHOULDs to MUSTs to line up with recovery.
We don't provide examples of the weird cases where you need to send Handshake packets to prevent amplification deadlock. The strangest one is where the client has all Initial data (and therefore has Handshake keys), but never receives a Handshake packet from the server. In this case, the client needs to send a Handshake packet that won't contain ACK or CRYPTO frames. We should explain this in a note. See .
I think the logic in the recovery draft misses some of these cases entirely. The rule in draft 23 is: but in your example case there is not necessarily any unacknowledged data to transmit in a probe, and a is forbidden at Handshake level, leaving no reasonable options to compose an ACK-eliciting packet.
a few suggestions

Revised text:
the server is not overly constrained by the amplification restriction.  <ins> Loss of an Initial or Handshake packet from the server can cause a deadlock if the client does not send additional Initial or Handshake packets.  A deadlock could occur when the server reaches its anti- amplification limit and the client has received acknowledgements for all the data it has sent.  In this case, when the client has no reason to send additional packets, the server will be unable to send more data because it has not validated the client's address.  To prevent this deadlock, clients MUST send a packet on a probe timeout (PTO, see Section 5.3 of QUIC-RECOVERY).  Specifically, the client MUST send an Initial packet in a UDP datagram of at least 1200 bytes if it does not have Handshake keys, and otherwise send a Handshake packet. </ins> A server might wish to validate the client address before starting the cryptographic handshake.  QUIC uses a token in the Initial packet
Original text:
6.6. During the handshake, some packet protection keys might not be <del> available when a packet arrives.  In particular, Handshake and 0-RTT packets cannot be processed until the Initial packets arrive, and 1-RTT packets cannot be processed until the handshake completes. Endpoints MAY ignore the loss of Handshake, 0-RTT, and 1-RTT packets that might arrive before the peer has packet protection keys to process those packets. </del>  6.7.

Reviewer comments:
Currently, the "Ignoring Loss of Undecryptable Packets" section indicates that some loss can be ignored, but now that we have multiple packet number spaces, I think we can constrain the set of ignorable losses to those below the smallest acknowledged packet in a packet number space. Ignoring the loss of a subsequently sent packet was not the intent.
I might have to put in a lint for HTAB...

Revised text:
6.6. During the handshake, some packet protection keys might not be  <ins> available when a packet arrives and the receiver can choose to drop the packet.  In particular, Handshake and 0-RTT packets cannot be processed until the Initial packets arrive and 1-RTT packets cannot be processed until the handshake completes.  Endpoints MAY ignore the loss of Handshake, 0-RTT, and 1-RTT packets that might have arrived before the peer had packet protection keys to process those packets. Endpoints MUST NOT ignore the loss of packets that were sent after the earliest acknowledged packet in a given packet number space. </ins> 6.7.
Original text:
layer.  By providing reliability at the stream level and congestion control across the entire connection, it has the capability to improve the performance of HTTP compared to a TCP mapping.  QUIC also <del> incorporates TLS 1.3 at the transport layer, offering comparable security to running TLS over TCP, with the improved connection setup latency of TCP Fast Open RFC7413. </del>  This document defines a mapping of HTTP semantics over the QUIC transport protocol, drawing heavily on the design of HTTP/2.  While

Reviewer comments:
It might pay to reconcile: {{vars-of-interest}}) to be larger than the congestion window, unless the packet is sent on a PTO timer expiration; see {{pto}}. And now exceeds the recently reduced congestion window. Now, you might implement the latter using PTO machinery, but that text doesn't really suggest that in any way.
Where does this second sentence come from? I'm pretty sure I haven't implemented anything like this in quic-go. Should I?
That sentence is the the definition of the . We haven't implemented that either, and I was wondering if it truly helps.
For TCP this second case if important because as long as you don't retransmit the lost packet you will not get any ACK that acknowledges new data. I guess we don't need that for QUIC.
The second sentence was added later in , and the MUST wasn't updated, so I'll fix that. Chromium currently implements PRR(RFC6937), which is a more complex variant of this which is designed to keep the ACK clock going. I thought we discussed adding an informative reference to PRR when we added this text, and I'm not sure why we didn't.
seems to be the wrong issue you are pointed to...
Good catch, it's
I've suggested some symbolic references.

Revised text:
layer.  By providing reliability at the stream level and congestion control across the entire connection, it has the capability to improve the performance of HTTP compared to a TCP mapping.  QUIC also  <ins> incorporates TLS 1.3 TLS13 at the transport layer, offering comparable security to running TLS over TCP, with the improved connection setup latency of TCP Fast Open TFO. </ins> This document defines a mapping of HTTP semantics over the QUIC transport protocol, drawing heavily on the design of HTTP/2.  While
Original text:
approach 2^(-L/2), that is, the birthday bound.  For the algorithms described in this document, that probability is one in 2^64. <del> In some cases, inputs shorter than the full size required by the packet protection algorithm might be used. </del> To prevent an attacker from modifying packet headers, the header is transitively authenticated using packet protection; the entire packet header is part of the authenticated additional data.  Protected

Reviewer comments:
Now that we require a minimum packet size, this is no longer true.
Is this no longer true for the algorithms defined in the spec, or no longer true for any packet protection algorithms for any AEAD? It might be worth moving the note to the end of 5.4.1 instead.

Revised text:
approach 2^(-L/2), that is, the birthday bound.  For the algorithms described in this document, that probability is one in 2^64.  To prevent an attacker from modifying packet headers, the header is transitively authenticated using packet protection; the entire packet header is part of the authenticated additional data.  Protected
Original text:
A client that is unable to retry requests loses all requests that are in flight when the server closes the connection.  An endpoint MAY <del> send multiple GOAWAY frames indicating different identifiers, but MUST NOT increase the identifier value they send, since clients might already have retried unprocessed requests on another connection. Receiving a GOAWAY containing a larger identifier than previously received MUST be treated as a connection error of type H3_ID_ERROR. </del>  An endpoint that is attempting to gracefully shut down a connection can send a GOAWAY frame with a value set to the maximum possible

Reviewer comments:
The endpoint sends frames, which carry -- not send -- identifier values.
The way it's intended to parse, "An endpoint ... MUST NOT increase the value they send," is probably incorrect in number or gender. But yes, changing the verb to reflect that the subject is the frames instead of the endpoint is also an option.
OK. I have no preference how this sentence is fixed -- as long as it's fixed.
This looks good. While we are at this paragraph, why say "client?" GOAWAY can be sent by either side now.
It can, but a server isn't going to retry push streams on a new connection; it's going to decide de novo whether to push there. Arguably, nothing breaks if the client increases the Push ID on the server after the fact.
BTW, thanks for catching this. I appreciate how many of these ambiguities you're winkling out.
NAME NAME OK, lgtm, then.
Maybe, given the ambiguity, the right answer is to get rid of "they" in the first place?

Revised text:
A client that is unable to retry requests loses all requests that are in flight when the server closes the connection.  An endpoint MAY  <ins> send multiple GOAWAY frames indicating different identifiers, but the identifier in each frame MUST NOT be greater than the identifier in any previous frame, since clients might already have retried unprocessed requests on another connection.  Receiving a GOAWAY containing a larger identifier than previously received MUST be treated as a connection error of type H3_ID_ERROR. </ins> An endpoint that is attempting to gracefully shut down a connection can send a GOAWAY frame with a value set to the maximum possible
Original text:
opening of either the send or receive side causes the stream to open in both directions. <del> An endpoint MUST open streams of the same type in increasing order of stream ID. </del> These states are largely informative.  This document uses stream states to describe rules for when and how different types of frames can be sent and the reactions that are expected when

Reviewer comments:
The text in 2.1 is more complete, so we don't need this.
When I read 3.0 I was a bit confused, because when the discussion of streams takes place in section 2.1, the requirement on stream ID ordering is already mentioned, but the reminder of what the types are is fresh in the mind. Perhaps this should be revised.

Revised text:
opening of either the send or receive side causes the stream to open in both directions.  These states are largely informative.  This document uses stream states to describe rules for when and how different types of frames can be sent and the reactions that are expected when
Original text:
a PATH_CHALLENGE frame is not adequate validation, since the acknowledgment can be spoofed by a malicious peer. <del> Note that receipt on a different local address does not result in path validation failure, as it might be a result of a forwarded packet (see off-path-forward) or misrouting.  It is possible that a valid PATH_RESPONSE might be received in the future. </del> 8.6. Path validation only fails when the endpoint attempting to validate

Reviewer comments:
In early versions of path validation, there was a requirement that PATH_CHALLENGE be sent on the same path. This is, for various reasons, either unnecessary or harmful, so we no longer have that requirement. But there was some residual text that assumed that property. This removes a paragraph citing symmetry directly, and rewords text that assumes return reachability - a property that QUIC no longer provides mechanisms for.
In , we removed the requirement that PATHRESPONSE be sent/received on the same path that PATHCHALLENGE was sent. However, there is still text in the document that relies on this assumption. In 8.5, it explains that receipt of the PATHRESPONSE on another interface doesn't cause validation to fail, because "It is possible that a valid PATHRESPONSE might be received in the future." But receipt of the PATHRESPONSE, over any interface is valid, and causes the validation to succeed. In 9.2, it suggests using path validation to demonstrate return reachability, but since PATHRESPONSE need not be sent on the same path, path validation doesn't demonstrate that.
Note that sending the response on the old path can lead to failures in "break before make" scenarios. Shall we mention that?

Revised text:
a PATH_CHALLENGE frame is not adequate validation, since the acknowledgment can be spoofed by a malicious peer.  8.6. Path validation only fails when the endpoint attempting to validate
Original text:
Receiving acknowledgments for data sent on the new path serves as proof of the peer's reachability from the new address.  Note that since acknowledgments may be received on any path, return <del> reachability on the new path is not established.  To establish return </del>  reachability on the new path, an endpoint MAY concurrently initiate <del> path validation migrate-validate on the new path or it MAY choose to wait for the peer to send the next non-probing frame to its new address. </del>  9.3.

Reviewer comments:
In early versions of path validation, there was a requirement that PATH_CHALLENGE be sent on the same path. This is, for various reasons, either unnecessary or harmful, so we no longer have that requirement. But there was some residual text that assumed that property. This removes a paragraph citing symmetry directly, and rewords text that assumes return reachability - a property that QUIC no longer provides mechanisms for.
In , we removed the requirement that PATHRESPONSE be sent/received on the same path that PATHCHALLENGE was sent. However, there is still text in the document that relies on this assumption. In 8.5, it explains that receipt of the PATHRESPONSE on another interface doesn't cause validation to fail, because "It is possible that a valid PATHRESPONSE might be received in the future." But receipt of the PATHRESPONSE, over any interface is valid, and causes the validation to succeed. In 9.2, it suggests using path validation to demonstrate return reachability, but since PATHRESPONSE need not be sent on the same path, path validation doesn't demonstrate that.
Note that sending the response on the old path can lead to failures in "break before make" scenarios. Shall we mention that?

Revised text:
Receiving acknowledgments for data sent on the new path serves as proof of the peer's reachability from the new address.  Note that since acknowledgments may be received on any path, return  <ins> reachability on the new path is not established.  No method is provided to establish return reachability, as endpoints independently determine reachability on each direction of a path.  To establish </ins> reachability on the new path, an endpoint MAY concurrently initiate  <ins> path validation migrate-validate on the new path.  An endpoint MAY defer path validation until after a peer sends the next non-probing frame to its new address. </ins> 9.3.
Original text:
4.1.4. <del> As keys for new encryption levels become available, TLS provides QUIC with those keys.  Separately, as keys at a given encryption level become available to TLS, TLS indicates to QUIC that reading or writing keys at that encryption level are available.  These events are not asynchronous; they always occur immediately after TLS is provided with new handshake bytes, or after TLS produces handshake bytes. </del>  TLS provides QUIC with three items as a new encryption level becomes available:

Reviewer comments:
These two statements are - to the extent that I can best determine - redundant. One is better.
The first two sentences of QUIC-TLS, Section 4.1.4 clearly intend to say different things, but I can't figure out the distinction. Is there a way we could reword them to make them clearer?
I think that this is not separately at all. Let's reduce that to a single statement.

Revised text:
4.1.4.  <ins> As keys at a given encryption level become available to TLS, TLS indicates to QUIC that reading or writing keys at that encryption level are available.  These events are not asynchronous; they always occur immediately after TLS is provided with new handshake bytes, or after TLS produces handshake bytes. </ins> TLS provides QUIC with three items as a new encryption level becomes available:
Original text:
CONNECTION_CLOSE in response to any UDP datagram that is received. However, an endpoint without the packet protection keys cannot identify and discard invalid packets.  To avoid creating an unwitting <del> amplification attack, such endpoints MUST reduce the frequency with which it sends packets containing a CONNECTION_CLOSE frame.  To minimize the state that an endpoint maintains for a closing </del>  connection, endpoints MAY send the exact same packet. Allowing retransmission of a closing packet is an exception to the

Reviewer comments:
We weren't very concrete in saying how endpoints generate packets with CONNECTIONCLOSE, particularly those that throw away keys. We have a rather vague requirement. In short, follow the same rules we established for the handshake. Wording this as an aggregate number allows for stochastic reactions and larger CONNECTIONCLOSE frames. This way, if you get a 25-byte packet and respond with a 200-byte packet, you can do that, but you have to respond to 3 in 8 or fewer in that way. Note that this limit only applies if the endpoint throws away decryption keys. Endpoints with keys aren't blind amplifiers.
closing period ({{draining}}) and send a packet containing a CONNECTIONCLOSE in response to any UDP datagram that is received. However, an endpoint without the packet protection keys cannot identify and discard invalid packets. To avoid creating an unwitting amplification attack, such endpoints MUST reduce the frequency with which it sends packets containing a CONNECTIONCLOSE frame. To This seems like a pretty vague requirement for a 2119 MUST. Like, I could only send it 9999/10000 packets and that would be compliant.
I think that it would be good to follow the 3x rule here also, but that's a non-editorial change.
Do folks agree the PR resolves this?
I think the PR resolves this and is a sensible choice.
Yup, the PR resolves this.
OK, labelling as such.

Revised text:
CONNECTION_CLOSE in response to any UDP datagram that is received. However, an endpoint without the packet protection keys cannot identify and discard invalid packets.  To avoid creating an unwitting  <ins> amplification attack, such endpoints MUST limit the cumulative size of packets containing a CONNECTION_CLOSE frame to 3 times the cumulative size of the packets that cause those packets to be sent. To minimize the state that an endpoint maintains for a closing </ins> connection, endpoints MAY send the exact same packet. Allowing retransmission of a closing packet is an exception to the
Original text:
likely the receiver will be able to process all the packets in a single pass.  A packet with a short header does not include a length, so it can only be the last packet included in a UDP datagram.  An <del> endpoint SHOULD NOT coalesce multiple packets at the same encryption level. </del>  Receivers MAY route based on the information in the first packet contained in a UDP datagram.  Senders MUST NOT coalesce QUIC packets

Reviewer comments:
This uses positive framing for the recommendation to use frames rather than packets. And it makes that recommendation directly, rather than implying it.
Here are three quasi-nits about S 12.2. Handshake, 1-RTT; see Section 4.1.4 of {{QUIC-TLS}}) makes it more likely the receiver will be able to process all the packets in a single pass. A packet with a short header does not include a length, so it can only be the last packet included in a UDP datagram. An endpoint SHOULD NOT coalesce multiple packets at the same encryption level. Is the implication here that you should instead pack all the frames into one packet? UDP datagram. Senders MUST NOT coalesce QUIC packets for different connections into a single UDP datagram. Receivers SHOULD ignore any subsequent packets with a different Destination Connection ID than the first packet in the datagram. Is there a valid reason to have different SCIDs? ({{packet-version}}), and packets with a short header ({{short-header}}) do not contain a Length field and so cannot be followed by other packets in the same UDP datagram. Note also that there is no situation where a Retry or Version Negotiation packet is coalesced with another packet. Should this be a MUST NOT?
Yes. See . I don't see why. It's just a fact, not a conformance requirement.
For (1) I think it would be helpful to say that.
LGTM, one suggestion.

Revised text:
likely the receiver will be able to process all the packets in a single pass.  A packet with a short header does not include a length, so it can only be the last packet included in a UDP datagram.  An  <ins> endpoint SHOULD include multiple frames in a single packet if they are to be sent at the same encryption level, instead of coalescing multiple packets at the same encryption level. </ins> Receivers MAY route based on the information in the first packet contained in a UDP datagram.  Senders MUST NOT coalesce QUIC packets
Original text:
the PTO expiry, subject to address validation limits; see Section 8.1 of QUIC-TRANSPORT. <del> Peers can also use coalesced packets to ensure that each datagram elicits at least one acknowledgement.  For example, clients can </del>  coalesce an Initial packet containing PING and PADDING frames with a 0-RTT data packet and a server can coalesce an Initial packet containing a PING frame with one or more packets in its first flight.

Reviewer comments:
This should resolve some parts of .
NAME If you wish, I will split this PR into small ones.
I have dropped the commit of "in flight".
I also changed into .
NAME The commit for "towards" has been dropped.
Thanks. BTW, that thing is an another odd English quirk.
Unfortunately, this PR bundles a bunch of unrelated changes. Some of them I like, some of them I don't.Thanks for the PR, NAME !

Revised text:
the PTO expiry, subject to address validation limits; see Section 8.1 of QUIC-TRANSPORT.  <ins> Endpoints can also use coalesced packets to ensure that each datagram elicits at least one acknowledgement.  For example, a client can </ins> coalesce an Initial packet containing PING and PADDING frames with a 0-RTT data packet and a server can coalesce an Initial packet containing a PING frame with one or more packets in its first flight.