jiebi/TextFlow huggingface dataset:
Original text:
Future analyses and specifications MAY relax confidentiality or integrity limits for an AEAD. <del> These limits were originally calculated using assumptions about the limits on TLS record size.  The maximum size of a TLS record is 2^14 bytes.  In comparison, QUIC packets can be up to 2^16 bytes.  However, it is expected that QUIC packets will generally be smaller than TLS records.  Where packets might be larger than 2^14 bytes in length, smaller limits might be needed. </del> Any TLS cipher suite that is specified for use with QUIC MUST define limits on the use of the associated AEAD function that preserves margins for confidentiality and integrity.  That is, limits MUST be

Reviewer comments:
We changed the limits listed here to be based on the maximum packet size, so the note a few paragraphs up citing the appendix is all we need here.
NAME said:
A few things here... The text in DTLS is a copy of this text, so similarities are no accident. However, the text has diverged, so drawing an analogy doesn't seem necessary (and I don't want a downref, even if it were informational). The numbers we are using from TLS is the target advantage probability. QUIC has a larger limit on packet size than TLS has on record size. Larger sizes affects the limits, which is what you see there. The note you quote is old and it should have been removed when we changed the numbers. As noted the analysis for DTLS would be helpful, but not definitive. As you say, the number of blocks in a packet can have an effect (though not for ChaCha20Poly1305 apparently). So l've a PR for the note, but I don't see any other action here.
I have an action item (to pester the DTLS 1.3 authors to reduce the divergence), but I agree there's no other action for this document.

Revised text:
Future analyses and specifications MAY relax confidentiality or integrity limits for an AEAD.  Any TLS cipher suite that is specified for use with QUIC MUST define limits on the use of the associated AEAD function that preserves margins for confidentiality and integrity.  That is, limits MUST be
Original text:
and destination addresses, source and destination UDP ports, and the Destination Connection ID field.  The flow label generation MUST be designed to minimize the chances of linkability with a previously <del> used flow label, as this would enable correlating activity on multiple paths; see migration-linkability. </del>  A possible implementation is to compute the flow label as a cryptographic hash function of the source and destination addresses,

Reviewer comments:
The text was probably backwards, but rather than invert it, remove the indirect reference to the subject of the claim and be explicit.
Erik Kline said:

Revised text:
and destination addresses, source and destination UDP ports, and the Destination Connection ID field.  The flow label generation MUST be designed to minimize the chances of linkability with a previously  <ins> used flow label, as a stable flow label would enable correlating activity on multiple paths; see migration-linkability. </ins> A possible implementation is to compute the flow label as a cryptographic hash function of the source and destination addresses,
Original text:
bytes for IPv4.  Thus, modern IPv4 and all IPv6 network paths are expected to be able to support QUIC.  Any maximum datagram size larger than 1200 bytes can be discovered using Path Maximum Transmission Unit Discovery (PMTUD; see pmtud) or Datagram Packetization Layer PMTU Discovery (DPLPMTUD; see dplpmtud). fragmented or dropped (RFC8085). If a QUIC endpoint determines that the PMTU between any pair of local <del> and remote IP addresses has fallen below the smallest allowed maximum </del>  datagram size of 1200 bytes, it MUST immediately cease sending QUIC packets, except for those in PMTU probes or those containing CONNECTION_CLOSE frames, on the affected path.  An endpoint MAY

Reviewer comments:
URL the path doesn't provide extra headroom. Includes some rewording of the text.
Éric Vyncke said:
We wanted some space for things like extension headers/options and maybe for tunnels. See which is in response to your peer Erik. And yeah, 1200 is a nice number.
Based on the discussion here and the linked issue, I don't think we need to do anything here.
Erik Kline said:
Seems reasonable to mention. Obviously many paths support a larger MTU and so will support more extensions (or options), but it's worth noting that there isn't a ton of space available.

Revised text:
bytes for IPv4.  Thus, modern IPv4 and all IPv6 network paths are expected to be able to support QUIC. <ins> This requirement to support a UDP payload of 1200 bytes limits the space available for IPv6 extension headers to 32 bytes or IPv4 options to 52 bytes if the path only supports the IPv6 minimum MTU of 1280 bytes.  This affects Initial packets and path validation. </ins> Any maximum datagram size larger than 1200 bytes can be discovered using Path Maximum Transmission Unit Discovery (PMTUD; see pmtud) or Datagram Packetization Layer PMTU Discovery (DPLPMTUD; see dplpmtud). fragmented or dropped (RFC8085). If a QUIC endpoint determines that the PMTU between any pair of local  <ins> and remote IP addresses cannot support the smallest allowed maximum </ins> datagram size of 1200 bytes, it MUST immediately cease sending QUIC packets, except for those in PMTU probes or those containing CONNECTION_CLOSE frames, on the affected path.  An endpoint MAY
Original text:
connection ID to be routed back to the endpoint and to be identified by the endpoint upon receipt.  Connection IDs MUST NOT contain any information that can be used by an external observer (that is, one that does not cooperate with the issuer) to correlate them with other connection IDs for the same

Reviewer comments:
Éric Vyncke said:
We say it, but it comes a lot later. Too late, I think.

Revised text:
connection ID to be routed back to the endpoint and to be identified by the endpoint upon receipt. <ins> Multiple connection IDs are used so that endpoints can send packets that cannot be identified by an observer as being for the same connection without cooperation from an endpoint; see migration- linkability. </ins> Connection IDs MUST NOT contain any information that can be used by an external observer (that is, one that does not cooperate with the issuer) to correlate them with other connection IDs for the same
Original text:
Abstract This document defines the properties of the QUIC transport protocol <del> that are expected to remain unchanged over time as new versions of the protocol are developed. </del>  Note to Readers

Reviewer comments:
This reconciles the abstract with the content
Éric Vyncke said:
The abstract hasn't kept pace with the text. It can be made clearer.

Revised text:
Abstract This document defines the properties of the QUIC transport protocol  <ins> that are common to all versions of the protocol. </ins> Note to Readers
Original text:
RESET_STREAM frame instead of retransmitting the data. An endpoint SHOULD copy the error code from the STOP_SENDING frame to <del> the RESET_STREAM frame it sends, but MAY use any application error </del>  code.  An endpoint that sends a STOP_SENDING frame MAY ignore the error code in any RESET_STREAM frames subsequently received for that stream. non-probing packet with a new largest packet number on its preferred address, the server begins sending non-probing packets to the client exclusively from its preferred IP address.  It SHOULD drop packets <del> for this connection received on the old IP address, but MAY continue </del>  to process delayed packets. The addresses that a server provides in the preferred_address

Reviewer comments:
Barry Leiba said:
The other reference was: — Section 3.5 — An endpoint SHOULD copy the error code from the STOPSENDING frame to the RESETSTREAM frame it sends, but MAY use any application error code. I'm OK with changing to "can".
I don't think we need to do this; I've suggested changes on the PR.
Ok, let's merge this one, and I'll make a separate PR for the second comment.

Revised text:
RESET_STREAM frame instead of retransmitting the data. An endpoint SHOULD copy the error code from the STOP_SENDING frame to  <ins> the RESET_STREAM frame it sends, but can use any application error </ins> code.  An endpoint that sends a STOP_SENDING frame MAY ignore the error code in any RESET_STREAM frames subsequently received for that stream. non-probing packet with a new largest packet number on its preferred address, the server begins sending non-probing packets to the client exclusively from its preferred IP address.  It SHOULD drop packets  <ins> for this connection received on the old IP address, but can continue </ins> to process delayed packets. The addresses that a server provides in the preferred_address
Original text:
Attackers could replay tokens to use servers as amplifiers in DDoS attacks.  To protect against such attacks, servers MUST ensure that replay of tokens is prevented or limited.  Servers SHOULD ensure that <del> tokens sent in Retry packets are only accepted for a short time. Tokens that are provided in NEW_TOKEN frames (frame-new-token) need to be valid for longer, but SHOULD NOT be accepted multiple times in a short period.  Servers are encouraged to allow tokens to be used only once, if possible; tokens MAY include additional information about clients to further narrow applicability or reuse. </del>  8.2.

Reviewer comments:
They only need to be good for one RTT. Of course, the server doesn't really know what the RTT is, so this isn't something firm, and I don't want to explain ALL of that, but this should do.
Roman Danyliw said:

Revised text:
Attackers could replay tokens to use servers as amplifiers in DDoS attacks.  To protect against such attacks, servers MUST ensure that replay of tokens is prevented or limited.  Servers SHOULD ensure that  <ins> tokens sent in Retry packets are only accepted for a short time, as they are returned immediately by clients.  Tokens that are provided in NEW_TOKEN frames (frame-new-token) need to be valid for longer, but SHOULD NOT be accepted multiple times.  Servers are encouraged to allow tokens to be used only once, if possible; tokens MAY include additional information about clients to further narrow applicability or reuse. </ins> 8.2.
Original text:
window of 10 times the maximum datagram size (max_datagram_size), limited to the larger of 14720 bytes or twice the maximum datagram size.  This follows the analysis and recommendations in RFC6928, <del> increasing the byte limit to account for the smaller 8 byte overhead of UDP compared to the 20 byte overhead for TCP. </del>  If the maximum datagram size changes during the connection, the initial congestion window SHOULD be recalculated with the new size.

Reviewer comments:
and the 20-byte overhead too. (If this is superseded, that's cool. Low hanging fruit...)
Éric Vyncke said:

Revised text:
window of 10 times the maximum datagram size (max_datagram_size), limited to the larger of 14720 bytes or twice the maximum datagram size.  This follows the analysis and recommendations in RFC6928,  <ins> increasing the byte limit to account for the smaller 8-byte overhead of UDP compared to the 20-byte overhead for TCP. </ins> If the maximum datagram size changes during the connection, the initial congestion window SHOULD be recalculated with the new size.
Original text:
Indicates that x is optional (and has length of L) <del> Indicates that x is repeated zero or more times (and that each instance is length L) </del>  This document uses network byte order (that is, big endian) values. Fields are placed starting from the high-order bits of each byte.

Reviewer comments:
Not repetitions, which might be read to mean one or more occurrences. This change will conflict, but the conflict is easy to resolve.
NAME said:
It is zero or more occurrences is correct and will adjust the text accordingly.

Revised text:
Indicates that x is optional (and has length of L)  <ins> Indicates that zero or more instances of x are present (and that each instance is length L) </ins> This document uses network byte order (that is, big endian) values. Fields are placed starting from the high-order bits of each byte.
Original text:
case where state is lost, so this approach is suboptimal. A single static key can be used across all connections to the same <del> endpoint by generating the proof using a second iteration of a preimage-resistant function that takes a static key and the connection ID chosen by the endpoint (see connection-id) as input. An endpoint could use HMAC RFC2104 (for example, HMAC(static_key, connection_id)) or HKDF RFC5869 (for example, using the static key as input keying material, with the connection ID as salt).  The output of this function is truncated to 16 bytes to produce the Stateless Reset Token for that connection. </del>  An endpoint that loses state can use the same method to generate a valid Stateless Reset Token.  The connection ID comes from the packet

Reviewer comments:
The second iteration piece is cruft and confusing.
NAME said:
I think that's an oops. I'll cut that. It's just the PRF part we need.

Revised text:
case where state is lost, so this approach is suboptimal. A single static key can be used across all connections to the same  <ins> endpoint by generating the proof using a pseudorandom function that takes a static key and the connection ID chosen by the endpoint (see connection-id) as input.  An endpoint could use HMAC RFC2104 (for example, HMAC(static_key, connection_id)) or HKDF RFC5869 (for example, using the static key as input keying material, with the connection ID as salt).  The output of this function is truncated to 16 bytes to produce the Stateless Reset Token for that connection. </ins> An endpoint that loses state can use the same method to generate a valid Stateless Reset Token.  The connection ID comes from the packet
Original text:
carry. An endpoint received transport parameters that were badly <del> formatted, included an invalid value, was absent even though it is mandatory, was present though it is forbidden, or is otherwise in error. </del>  The number of connection IDs provided by the peer exceeds the advertised active_connection_id_limit.

Reviewer comments:
Error because you were going to violate the transport parameters we negotiated. You know you were! YOU KNOW IT!
NAME said:
I guess we were missing future tense, which would have made this sentence really fun.

Revised text:
carry. An endpoint received transport parameters that were badly  <ins> formatted, included an invalid value, omitted a mandatory transport parameter, included a forbidden transport parameter, or were otherwise in error. </ins> The number of connection IDs provided by the peer exceeds the advertised active_connection_id_limit.
Original text:
discard packets that are received on a different network path. The Source and Destination Connection ID fields are the primary means <del> of protection against off-path attack during the handshake.  These are required to match those set by a peer.  Except for an Initial and stateless reset packets, an endpoint only accepts packets that include a Destination Connection ID field that matches a value the endpoint previously chose.  This is the only protection offered for Version Negotiation packets. </del>  The Destination Connection ID field in an Initial packet is selected by a client to be unpredictable, which serves an additional purpose.

Reviewer comments:
NAME said:
I believe that we are perfectly OK for the handshake. We can cite Section 8.1 (again) for this (it's the third paragraph primarily). This is deliberately not specified other places. Mostly because it is hard, but also because any definition would be unnecessarily constraining. I don't agree with Fernando that this absolutely needs specification.

Revised text:
discard packets that are received on a different network path. The Source and Destination Connection ID fields are the primary means  <ins> of protection against off-path attack during the handshake; see validate-handshake.  These are required to match those set by a peer. Except for an Initial and stateless reset packets, an endpoint only accepts packets that include a Destination Connection ID field that matches a value the endpoint previously chose.  This is the only protection offered for Version Negotiation packets. </ins> The Destination Connection ID field in an Initial packet is selected by a client to be unpredictable, which serves an additional purpose.
Original text:
IP header to influence the sender's rate.  RFC3168 discusses manipulations and their effects in more detail. <del> An on-the-side attacker can duplicate and send packets with modified ECN fields to affect the sender's rate.  If duplicate packets are discarded by a receiver, an off-path attacker will need to race the duplicate packet against the original to be successful in this </del>  attack.  Therefore, QUIC endpoints ignore the ECN field on an IP packet unless at least one QUIC packet in that IP packet is successfully processed; see ecn.

Reviewer comments:
This might conflict, but I think it supersedes the other "off-path" tweaks.
NAME said:

Revised text:
IP header to influence the sender's rate.  RFC3168 discusses manipulations and their effects in more detail.  <ins> A limited on-path attacker can duplicate and send packets with modified ECN fields to affect the sender's rate.  If duplicate packets are discarded by a receiver, an attacker will need to race the duplicate packet against the original to be successful in this </ins> attack.  Therefore, QUIC endpoints ignore the ECN field on an IP packet unless at least one QUIC packet in that IP packet is successfully processed; see ecn.
Original text:
An endpoint MAY enter the draining state from the closing state if it receives a CONNECTION_CLOSE frame, which indicates that the peer is <del> also closing or draining.  In this case, the draining state SHOULD end when the closing state would have ended.  In other words, the endpoint uses the same end time, but ceases transmission of any packets on this connection. </del>  10.2.3.

Reviewer comments:
No need for a SHOULD here. (No issue yet.)
Murray might have more choice words.

Revised text:
An endpoint MAY enter the draining state from the closing state if it receives a CONNECTION_CLOSE frame, which indicates that the peer is  <ins> also closing or draining.  In this case, the draining state ends when the closing state would have ended.  In other words, the endpoint uses the same end time, but ceases transmission of any packets on this connection. </ins> 10.2.3.
Original text:
measurement and use of the latency spin bit is further discussed in QUIC-MANAGEABILITY. <del> The spin bit is an OPTIONAL feature of this version of QUIC.  A QUIC stack that chooses to support the spin bit MUST implement it as specified in this section. </del>  Each endpoint unilaterally decides if the spin bit is enabled or disabled for a connection.  Implementations MUST allow administrators

Reviewer comments:
Rob Wilton said:
This was talked about on the IESG telechat 2020-01-07. The action item is to add clarity for what an endpoint that does not support the spin bit should do. Note that this is distinct from an endpoint that supports spin bit but chooses to disable it. The discussion leaned towards an editorial change to the text in Section 17.4, for instance in paragraph 3. IIUC no other changes are needed to resolve this discuss, but we should confirm this via email.
I don't get this. The following text seems abundantly clear: Or is it this? Where we don't say that optional == disable it? If that is all, I'm going to hold my tongue.
NAME -- this is good now. Thanks!

Revised text:
measurement and use of the latency spin bit is further discussed in QUIC-MANAGEABILITY.  <ins> The spin bit is an OPTIONAL feature of this version of QUIC.  An endpoint that does not support this feature MUST disable it, as defined below. </ins> Each endpoint unilaterally decides if the spin bit is enabled or disabled for a connection.  Implementations MUST allow administrators
Original text:
a per-connection basis.  Even when the spin bit is not disabled by the administrator, endpoints MUST disable their use of the spin bit for a random selection of at least one in every 16 network paths, or <del> for one in every 16 connection IDs.  As each endpoint disables the spin bit independently, this ensures that the spin bit signal is disabled on approximately one in eight network paths. </del>  When the spin bit is disabled, endpoints MAY set the spin bit to any value, and MUST ignore any incoming value.  It is RECOMMENDED that

Reviewer comments:
NAME notes: requiring the disabling of the spin bit on a fraction of connections is useful. This may be worth a sentence of explanation. My understanding is that this exists both to protect the ability of endpoints to opt out and to ensure that monitoring is robust when the opt-out is exercised.
Also to ensure that if the functionality is removed/changed in a future version of QUIC, we're only changing the percentage of traffic that enables it versus creating something new.

Revised text:
a per-connection basis.  Even when the spin bit is not disabled by the administrator, endpoints MUST disable their use of the spin bit for a random selection of at least one in every 16 network paths, or  <ins> for one in every 16 connection IDs, in order to ensure that QUIC connections that disable the spin bit are commonly observed on the network.  As each endpoint disables the spin bit independently, this ensures that the spin bit signal is disabled on approximately one in eight network paths. </ins> When the spin bit is disabled, endpoints MAY set the spin bit to any value, and MUST ignore any incoming value.  It is RECOMMENDED that
Original text:
Examples and a sample decoding algorithm are shown in sample-varint.  Versions (versions), packet numbers sent in the header (packet- encoding), and the length of connection IDs in long header packets (long-header) are described using integers, but do not use this

Reviewer comments:
With one exception.
Rob Wilton said:
The one case where non-optimal encodings are forbidden is URL Otherwise, there is no restriction. Yes, 3 can be encoded in 8 bytes. But it is worth noting. (I thought that we had.)

Revised text:
Examples and a sample decoding algorithm are shown in sample-varint. <ins> Values do not need to be encoded on the minimum number of bytes necessary, with the sole exception of the Frame Type field; see frames. </ins> Versions (versions), packet numbers sent in the header (packet- encoding), and the length of connection IDs in long header packets (long-header) are described using integers, but do not use this
Original text:
The next two bits (those with a mask of 0x30) of byte 0 contain a packet type.  Packet types are listed in long-packet-types. <del> The lower four bits (those with a mask of 0x0f) of byte 0 are type-specific. </del>  The QUIC Version is a 32-bit field that follows the first byte. This field indicates the version of QUIC that is in use and

Reviewer comments:
So I rewrote the sentence instead.
packet-type-specific?
Rob Wilton said:
In this case, you can simply do "type specific", since type-specific is not an adjective before a noun (like "type-specific bits"). But this is good too.

Revised text:
The next two bits (those with a mask of 0x30) of byte 0 contain a packet type.  Packet types are listed in long-packet-types.  <ins> The semantics of the lower four bits (those with a mask of 0x0f) of byte 0 are determined by the packet type. </ins> The QUIC Version is a 32-bit field that follows the first byte. This field indicates the version of QUIC that is in use and