jiebi/TextFlow huggingface dataset:
Original text:
The second-to-most significant bit of the first byte in every QUIC packet is defined as having a fixed value in QUIC version 1 QUIC. <del> The purpose of having a fixed value is to allow QUIC to be efficiently distinguished from other protocols; see DEMUX for a </del>  description of a system that might use this property.  As this bit can identify a packet as QUIC, it is sometimes referred to as the "QUIC Bit". change makes the task of identifying QUIC more difficult without cooperation of endpoints.  This sometimes works counter to the security goals of network operators who rely on network <del> classification to identify threats. </del>  5.

Reviewer comments:
LGTM.
Actually, looking at a bit closer, perhaps consider: "... endpoint and cooperating intermediaries to efficiently ..." and perhaps make the Manageability reference explicitly to section 3.1 that covers identifying QUIC traffic.
Note that this is the second paragraph of the document. I'd prefer not to pile too many unrelated concepts in at this point. I think that it is OK to consider "cooperating intermediaries" to be implicit when we say "endpoint" when operating at this level of abstraction. Toward the end, where manageability is cited, is a better place for that sort of detail. I narrowed the citation to point to Section 3.1 as you suggested.
I think this update addresses NAME 's point in the telechat review.

Revised text:
The second-to-most significant bit of the first byte in every QUIC packet is defined as having a fixed value in QUIC version 1 QUIC.  <ins> The purpose of having a fixed value is to allow endpoints to efficiently distinguish QUIC from other protocols; see DEMUX for a </ins> description of a system that might use this property.  As this bit can identify a packet as QUIC, it is sometimes referred to as the "QUIC Bit". change makes the task of identifying QUIC more difficult without cooperation of endpoints.  This sometimes works counter to the security goals of network operators who rely on network  <ins> classification to identify threats; see Section 3.1 of MANAGEABILITY for a more comprehensive treatment of this topic. </ins> 5.
Original text:
The second-to-most significant bit of the first byte in every QUIC packet is defined as having a fixed value in QUIC version 1 QUIC. <del> The purpose of having a fixed value is to allow QUIC to be efficiently distinguished from other protocols; see DEMUX for a </del>  description of a system that might use this property.  As this bit can identify a packet as QUIC, it is sometimes referred to as the "QUIC Bit". change makes the task of identifying QUIC more difficult without cooperation of endpoints.  This sometimes works counter to the security goals of network operators who rely on network <del> classification to identify threats. </del>  5.

Reviewer comments:
This one says something like what Lucas said, with the caveat that the whole thing about per-connection ID is specific to spin bits, so I dropped that.
LGTM

Revised text:
The second-to-most significant bit of the first byte in every QUIC packet is defined as having a fixed value in QUIC version 1 QUIC.  <ins> The purpose of having a fixed value is to allow endpoints to efficiently distinguish QUIC from other protocols; see DEMUX for a </ins> description of a system that might use this property.  As this bit can identify a packet as QUIC, it is sometimes referred to as the "QUIC Bit". change makes the task of identifying QUIC more difficult without cooperation of endpoints.  This sometimes works counter to the security goals of network operators who rely on network  <ins> classification to identify threats; see Section 3.1 of MANAGEABILITY for a more comprehensive treatment of this topic. </ins> 5.
Original text:
specification as described in QUIC, QUIC-TLS, and RFC9002, with the following changes: <del> The version field of long headers is TBD.  Note: Unless this document is published as an RFC, implementations should use the provisional value 0xff020000, which might change with each edition of this document. </del>  The salt used to derive Initial keys in Section 5.2 of QUIC-TLS changes to: This document requests that IANA add the following entry to the QUIC version registry: <del> Value: TBD </del>  <del> Status: permanent </del>  Specification: This Document

Reviewer comments:
Get one from IANA
I'll ask for 0x70 9a 50 c4 .
Feedback from NAME was that you should do that after publishing a revision with that number in it. I second that.

Revised text:
specification as described in QUIC, QUIC-TLS, and RFC9002, with the following changes:  <ins> The version field of long headers is 0x709a50c4. </ins> The salt used to derive Initial keys in Section 5.2 of QUIC-TLS changes to: This document requests that IANA add the following entry to the QUIC version registry:  <ins> Value: 0x709a50c4 </ins>  <ins> Status: provisional </ins> Specification: This Document
Original text:
4. <del> QUIC version 2 endpoints SHOULD also support QUIC version 1.  Any QUIC endpoint that supports multiple versions MUST meet the minimum requirements described in QUIC-VN to prevent version downgrade attacks. </del>  Note that version 2 meets that document's definition of a compatible <del> version with version 1.  Therefore, v2-capable servers MUST use compatible version negotiation unless they do not support version 1. </del>  4.1.

Reviewer comments:
The original intent was to recommend compatible VN. But that doesn't make any sense: compatible VN is something that the server initiates between versions that are at least partially supported. The client doesn't really have any control except that it can omit versions from the TP. Incompatible VN cannot happen between mutually supported versions, and the client is in control.
NAME major rewrite that I think addresses your concerns. PTAL
In practice, v2 servers should also support compatible VN, as long as v1 clients are ubiquitous. To do otherwise would result in a performance penalty.
Thanks for the discussion!

Revised text:
4.  <ins> QUIC version 2 is not intended to deprecate version 1.  Endpoints that support version 2 might continue support for version 1 to maximize compatibility with clients.  In particular, HTTP clients often use Alt-Svc RFC7838 to discover QUIC support.  As this mechanism does not currently distinguish between QUIC versions, HTTP servers that support multiple versions reduce the probability of incompatibility and the cost associated with QUIC version negotiation or TCP fallback.  For example, an origin advertising support for "h3" in Alt-Svc SHOULD support QUIC version 1 as it was the original QUIC version used by HTTP/3 and therefore some clients will only support that version. Any QUIC endpoint that supports multiple versions MUST meet the minimum requirements described in QUIC-VN to prevent version downgrade attacks. </ins> Note that version 2 meets that document's definition of a compatible  <ins> version with version 1.  Therefore, servers can use compatible negotiation to switch a connection between the two versions. Endpoints that support both versions SHOULD support compatible version negotiation to avoid a round trip. </ins> 4.1.
Original text:
version used by HTTP/3 and therefore some clients will only support that version. <del> Any QUIC endpoint that supports multiple versions MUST meet the minimum requirements described in QUIC-VN to prevent version downgrade attacks. </del>  Note that version 2 meets that document's definition of a compatible <del> version with version 1.  Therefore, servers can use compatible negotiation to switch a connection between the two versions. Endpoints that support both versions SHOULD support compatible version negotiation to avoid a round trip. </del>  4.1.

Reviewer comments:
As described in URL, we're going to simply require all not-just-v1 servers to support the version-information transport parameter, even if they're v2-only servers.

Revised text:
version used by HTTP/3 and therefore some clients will only support that version.  <ins> Any QUIC endpoint that supports QUIC version 2 MUST send, process, and validate the version_information transport parameter specified in QUIC-VN to prevent version downgrade attacks. </ins> Note that version 2 meets that document's definition of a compatible  <ins> version with version 1, and version 1 is compatible with version 2. Therefore, servers can use compatible negotiation to switch a connection between the two versions.  Endpoints that support both versions SHOULD support compatible version negotiation to avoid a round trip. </ins> 4.1.
Original text:
to the capabilities available to applications.  Therefore, all Application Layer Protocol Negotiation (ALPN) (RFC7301) codepoints specified to operate over QUICv1 can also operate over this version <del> of QUIC. </del>  All QUIC extensions defined to work with version 1 also work with version 2.

Reviewer comments:
Now that DoQ is in the RFCEd queue, this draft should specifically state it is compatible with both registered ALPNs.

Revised text:
to the capabilities available to applications.  Therefore, all Application Layer Protocol Negotiation (ALPN) (RFC7301) codepoints specified to operate over QUICv1 can also operate over this version  <ins> of QUIC.  In particular, both the "h3" I-D.ietf-quic-http and "doq" I-D.ietf-dprive-dnsoquic ALPNs can operate over QUICv2. </ins> All QUIC extensions defined to work with version 1 also work with version 2.
Original text:
5. <del> TLS session tickets are specific to the QUIC version of the connection that provided them.  Clients MUST NOT use a session ticket from a QUICv1 connection to initiate a QUICv2 connection, or vice versa. Servers SHOULD validate the originating version of any session ticket and not resume from any ticket issued from a different version.  This results in falling back to a full TLS handshake, without 0-RTT. </del>  After compatible version negotiation, any resulting session ticket maps to the negotiated version rather than original one.

Reviewer comments:
Are NEW_TOKEN tokens reusable across versions? On current patterns, probably not, but we should write it down.
Agreed, we should mirror here what we did for TLS resumption tickets

Revised text:
5.  <ins> TLS session tickets and NEW_TOKEN tokens are specific to the QUIC version of the connection that provided them.  Clients SHOULD NOT use a session ticket or token from a QUICv1 connection to initiate a QUICv2 connection, or vice versa. Servers MUST validate the originating version of any session ticket or token and not accept one issued from a different version.  A rejected ticket results in falling back to a full TLS handshake, without 0-RTT.  A rejected token results in the client address remaining unverified, which limits the amount of data the server can send. </ins> After compatible version negotiation, any resulting session ticket maps to the negotiated version rather than original one.
Original text:
Clients interested in combating firewall ossification can initiate a connection using version 2 if they are either reasonably certain the server supports it, or are willing to suffer a round-trip penalty if <del> they are incorrect. </del>  7.

Reviewer comments:
Though no guarantee can be made, a client with a v2 ticket (which cannot be used with v1) might be in a good position to attempt v2 outright. Avoiding saying this creates something of a weird contradiction between sections.
Hmm. Your changes draws attention to the server expressing intent with a session ticket (but maybe not actual support), but that now seems oddly contrasting against the prior sentence that the client acts on reasonable confidence of support. So is the session ticket intent something a client can have reasonable confidence in, or not?
I thought that this was an appropriate amount of hedging on that point. The previous sentence is the "without other information, probably choose v1" side, the added sentence is the "maybe if you get a ticket you could bet the other way". Nothing firm either way, as tickets don't represent a commitment, they only signal intent in a way that alters probabilities.
Got it. On balance that seems right, we can't proscribe too much behaviour here. Looking forward to the research papers that analyse the effects of choice in the wild during 2023+

Revised text:
Clients interested in combating firewall ossification can initiate a connection using version 2 if they are either reasonably certain the server supports it, or are willing to suffer a round-trip penalty if  <ins> they are incorrect.  In particular, a server that issues a session ticket for version 2 indicates an intent to maintain version 2 support while the ticket remains valid, even if support cannot be guaranteed. </ins> 7.
Original text:
QUIC version 2 is meant to mitigate ossification concerns and exercise the version negotiation mechanisms.  The only change is a <del> tweak to the inputs of some crypto derivation functions to enforce full key separation.  Any endpoint that supports two versions needs to implement version negotiation to protect against downgrade attacks. </del>  2.

Reviewer comments:
Not only because crypto is short for cryptocurrency.
QUICv3, the web3 protocol, uses crypto the right way: the blockchain way.
You're only allowed to call it crypto in QUIC v3

Revised text:
QUIC version 2 is meant to mitigate ossification concerns and exercise the version negotiation mechanisms.  The only change is a  <ins> tweak to key derivation inputs to enforce full key separation.  Any endpoint that supports two versions needs to implement version negotiation to protect against downgrade attacks. </ins> 2.
Original text:
6.  QUIC version 2 introduces no changes to the security or privacy properties of QUIC version 1. attacks, but downgrades have no security implications, as the version properties are identical. <del> 7. </del>  This document requests that IANA add the following entry to the QUIC version registry:

Reviewer comments:
One way to
I have a feeling you'll need to say that this "updates" HTTP/3.
on slack some are saying we should roll a new h3 ALPN for running over quicv2. I cannot quite follow the argument but this is a better venue for the discussion.
You definitely need a new specification, because a different QUIC version might not be suitable. You either say: h3 can be used with QUICv2, or h3q2 (or whatever new string you like) identifies HTTP/3 when running over QUICv2. There are lots of arguments as to why you might choose to do one or the other.
I'm swayed more toward a new ALP.N at the moment
FWIW we painted ourselves into this corner. We punting on the problem and simply tied H3 to v1. Now we are actively trying to solve VN we might be able to pay back the tech debt. For example, a document that updates H3 to say that it can work over versions compatible with v1. Incompatible versions could still need to defined as a new application mapping,
Whatever we do, I think we need to ensure that servers can give sufficient information to clients via Alt-Svc so that the client can pick a compatible version (if any) and avoid VN. This could, then, be solved via Alt-Svc layer or via ALPN, but I think this is any important property.
Well "avoiding VN" is only important to the extent that we can't do compatible VN.
I think we want to allow the existence of a server that only supports v2 and servers that only support v1.... and clients that only support v2 and clients that only support v1. Given this, there will be client : server pairs which do not support any mutually compatible options. It seems like it would be desirable for clients to be able to deduce this from Alt-Svc without needing to see the QUIC connection to the server fail?
Oh, and this text from the HTTP/3 docs is probably relevant:

Revised text:
6. <ins> This version of QUIC provides no change from QUIC version 1 relating to the capabilities available to applications.  Therefore, all Application Layer Protocol Negotiation (ALPN) (RFC7301) codepoints specified to operate over QUICv1 can also operate over this version of QUIC. 7. </ins> QUIC version 2 introduces no changes to the security or privacy properties of QUIC version 1. attacks, but downgrades have no security implications, as the version properties are identical.  <ins> 8. </ins> This document requests that IANA add the following entry to the QUIC version registry:
Original text:
Retry as QUIC version 1.  After switching to a negotiated version after a Retry, the server MUST include the relevant transport parameters to validate that the server sent the Retry and the <del> connection IDs used in the exchange, as described in QUIC.  Note that the version of the first Initial and the subsequent Retry are not authenticated by transport parameters. </del>  The server SHOULD start sending its Initial packets using the negotiated version as soon as it decides to change.  Before the

Reviewer comments:
NAME verbally approved.
Draft currently states: Is this true? The client sends this as its Chosen Version right?
I don't think so? If the client receives a v1 Retry and then chooses to connect via v2 for some reason, that won't break the transcript.
The "for some reason" doesn't make sense to me here. If the client follows the normative language in this document and in QUIC VN, it won't magically switch to v2 after receiving a v1 retry - it will instead send a second v1 initial which will contain the retry token and also . Also, while we're at it, what is the "subsequent Retry" here? Can you write up a packet diagram to explain the flow you have in mind? (on this issue not in the draft)
Ah, I'd forgotten that in 4.1 we validate the version in the Retry token. I'll delete the sentence.

Revised text:
Retry as QUIC version 1.  After switching to a negotiated version after a Retry, the server MUST include the relevant transport parameters to validate that the server sent the Retry and the  <ins> connection IDs used in the exchange, as described in QUIC. </ins> The server SHOULD start sending its Initial packets using the negotiated version as soon as it decides to change.  Before the
Original text:
17.6. <del> A Handshake packet uses long headers with a type value of 0x3.  It is </del>  used to carry acknowledgments and cryptographic handshake messages from the server and client.

Reviewer comments:
Handshake and Retry have the same type number in the text; assuming the table is correct, this aligns the text with the table.

Revised text:
17.6.  <ins> A Handshake packet uses long headers with a type value of 0x2.  It is </ins> used to carry acknowledgments and cryptographic handshake messages from the server and client.
Original text:
7.7. A sender becomes idle if it ceases to send data and has no bytes in <del> flight.  A sender's congestion window MUST not increase while it is </del>  idle. When sending data after becoming idle, a sender MUST reset its

Reviewer comments:
I think "MUST NOT" was the intention of , not "MUST not".
NAME you can just merge these.

Revised text:
7.7. A sender becomes idle if it ceases to send data and has no bytes in  <ins> flight.  A sender's congestion window MUST NOT increase while it is </ins> idle. When sending data after becoming idle, a sender MUST reset its
Original text:
The key and IV for the packet are computed as described in protection-keys.  The nonce, N, is formed by combining the packet <del> protection IV with the packet number.  The 64 bits of the </del>  reconstructed QUIC packet number in network byte order are left- padded with zeros to the size of the IV.  The exclusive OR of the padded packet number and the IV forms the AEAD nonce. 12.3. <del> The packet number is an integer in the range 0 to 2^62-1.  Where present, packet numbers are encoded as a variable-length integer (see integer-encoding).  This number is used in determining the cryptographic nonce for packet protection.  Each endpoint maintains a separate packet number for sending and receiving. </del>  Version Negotiation (packet-version) and Retry packet-retry packets do not include a packet number. 17.1. <del> Packet numbers in long and short packet headers are encoded in 1 to 4 bytes.  The number of bits required to represent the packet number is reduced by including the least significant bits of the packet number. </del>  The encoded packet number is protected as described in Section 5.4 of QUIC-TLS.

Reviewer comments:
In Section 12.3, the transport specs says: But in both 17.2 (Long Header) and 17.3 (Short Header), Packet Number field in the packet is noted as the following format: which suggest it isn't variable-length integers. Can we get some clarification regarding this? Thank you!
Section 17.2/17.3 is correct -- PNs are not encoded using the varint form in Sec 16.

Revised text:
The key and IV for the packet are computed as described in protection-keys.  The nonce, N, is formed by combining the packet  <ins> protection IV with the packet number.  The 62 bits of the </ins> reconstructed QUIC packet number in network byte order are left- padded with zeros to the size of the IV.  The exclusive OR of the padded packet number and the IV forms the AEAD nonce. 12.3.  <ins> The packet number is an integer in the range 0 to 2^62-1.  This number is used in determining the cryptographic nonce for packet protection.  Each endpoint maintains a separate packet number for sending and receiving. Packet numbers are limited to this range because they need to be representable in whole in the Largest Acknowledged field of an ACK frame (frame-ack).  When present in a long or short header however, packet numbers are reduced and encoded in 1 to 4 bytes, see packet- encoding). </ins> Version Negotiation (packet-version) and Retry packet-retry packets do not include a packet number. 17.1.  <ins> Packet numbers are integers in the range 0 to 2^62-1 (packet- numbers).  When present in long or short packet headers, they are encoded in 1 to 4 bytes.  The number of bits required to represent the packet number is reduced by including the least significant bits of the packet number. </ins> The encoded packet number is protected as described in Section 5.4 of QUIC-TLS.
Original text:
setting this timer, implementations are cautioned that the new path could have a longer round-trip time than the original.  A value of three times the larger of the current Probe Timeout (PTO) or the <del> initial timeout (that is, kInitialRtt*2) as defined in QUIC-RECOVERY </del>  is RECOMMENDED.  That is: Note that the endpoint might receive packets containing other frames

Reviewer comments:
1789:Retransmittion Timeout (RTO) as defined in {{QUIC-RECOVERY}} is RECOMMENDED. 2182:(RTO) interval as defined in {{QUIC-RECOVERY}}. 2253:draining state before the packets arrive. If a peer could timeout within an RTO
Also, we have to set a minimum for the path validation timout. Suggest initial timeout(kInitiaRtt2)3 = 600ms. That makes this a design issue.
LG, one suggestion.

Revised text:
setting this timer, implementations are cautioned that the new path could have a longer round-trip time than the original.  A value of three times the larger of the current Probe Timeout (PTO) or the  <ins> initial timeout (that is, 2*kInitialRtt) as defined in QUIC-RECOVERY </ins> is RECOMMENDED.  That is: Note that the endpoint might receive packets containing other frames