jiebi/CodeConvo huggingface dataset:
Change:
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!

Discussion:
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> <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 <del> version with version 1.  Therefore, v2-capable servers MUST use compatible version negotiation unless they do not support version 1. </del> <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.
Change:
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.

Discussion:
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> <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 <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> <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.
Change:
Now that DoQ is in the RFCEd queue, this draft should specifically state it is compatible with both registered ALPNs.

Discussion:
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> <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.
Change:
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

Discussion:
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> <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.
Change:
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+

Discussion:
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> <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.
Change:
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

Discussion:
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> <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.
Change:
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:

Discussion:
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. <del> 7. </del> <ins> 8. </ins> This document requests that IANA add the following entry to the QUIC version registry:
Change:
, ,
It would be nice to have the references use a consistent format (e.g. all having a name instead of the RFC number for some)
OK, I've only left document number references where the subject is indicated beforehand, e.g. Alt-Svc {{?RFC7838}}
fixed by
Draft currently states: This repeats the QUIC VN document, should we remove it?
Yes, good catch.
fixed by
The draft currently says: Could we add a note to be removed by the RFC editor that clarifies whether or not we're going to change the version number before publication or not?
fixed by
The abstract currently contains: I'm pretty sure the second one won't be included, but there's no note saying so. I don't know if the first one is meant to stay. Can we add a note to make this explicit? Markdown can do it for you for the second one.
Actually the second note can be removed entirely because it repeats the paragraph that's autogenerated.
Thanks!

Discussion:
Note that "version 2" is an informal name for this proposal that indicates it is the second standards-track QUIC version.  The <del> protocol specified here will receive a version number other than 2 from IANA. Discussion of this work is encouraged to happen on the QUIC IETF mailing list <quic@ietf.org> or on the GitHub repository which contains the draft: <https://github.com/quicwg/quic-v2>. </del> <ins> protocol specified here uses a version number other than 2 in the wire image. </ins> 1.

3. QUIC version 2 endpoints MUST implement the QUIC version 1 <del> specification as described in QUIC, QUIC-TLS, and RFC9002.  However, the following differences apply in version 2. </del> <ins> specification as described in QUIC, QUIC-TLS, and QUIC-LOSSRECOVERY. However, the following differences apply in version 2. </ins> 3.1. The Version field of long headers is 0x709a50c4. <ins> This version number will not change in subsequent versions of this draft, unless there is a behavior change that breaks compatibility. </ins> 3.2. All version 2 long header packet types are different.  The Type field

version.  Endpoints have no need to generate the keying material that would allow them to decrypt or authenticate these packets. <del> If the server's version_information transport parameter does not contain a Chosen Version field equivalent to the version in the server's Handshake packet headers, the client MUST terminate the connection with a VERSION_NEGOTIATION_ERROR. </del> The client MUST NOT send 0-RTT packets using the negotiated version, even after processing a packet of that version from the server. Servers can apply original version 0-RTT packets to a connection
Change:
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.

Discussion:
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> <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
Change:
Handshake and Retry have the same type number in the text; assuming the table is correct, this aligns the text with the table.

Discussion:
17.6. <del> A Handshake packet uses long headers with a type value of 0x3.  It is </del> <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.
Change:
I think "MUST NOT" was the intention of , not "MUST not".
NAME you can just merge these.

Discussion:
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> <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
Change:
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.

Discussion:
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> <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. <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> <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. <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> <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.
Change:
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.

Discussion:
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> <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
Change:
How could this happen? The recipient knows if a given tuple is unique, so it shouldn't issue zero-length DCIDs for that tuple.
Yeah, it is more like recipients MUST not issue 0-length CID's in that case. And MUST drop non-issued CID's.
I remember why was added. If you had one connection on those addresses, time passes and a NAT rebinding moves another connection to that same path, then you get problems. That a nonsensical situation and better addressed as suggested.

Discussion:
If the Destination Connection ID is zero length and the packet matches the address/port tuple of a connection where the host did not require connection IDs, QUIC processes the packet as part of that <del> connection.  Endpoints MUST drop packets with zero-length Destination Connection ID fields if they do not correspond to a single connection. </del> <ins> connection.  Endpoints SHOULD either reject connection attempts that use the same addresses as existing connections, or use a non-zero- length Destination Connection ID so that packets can be correctly attributed to connections. </ins> Endpoints can send a Stateless Reset (stateless-reset) for any packets that cannot be attributed to an existing connection.  A
Change:
This doesn't need normative text. This adds NAME recommendation about only sending flow control frames when there are other frames to send. Though I added another note about the peer being explicitly blocked, which I think is a useful transition to the next paragraph.
I don't think so. Flow control credits can go out with acknowledgments. The advice is there so that you don't have the MAX_DATA frame go out immediately, with a delayed ACK going out 20ms later. They can both go out together.
Bundling frames definitely makes sense, but I don’t think we need the “or when a peer is blocked” part.
Your assertion being that a blocked peer will already have to live with being blocked for a round trip, so the gain isn't worth documenting?
I’m saying that you shouldn’t let your peer become blocked under normal circumstances. I just noticed that in the corner case where the peer is blocked because the application is consuming data too slowly, it actually makes sense to not bundle the flow control update. So I guess the text is fine as is.
The text just says that sending more packets causes more packets to be sent. That is kind of obvious. Also, sending flow control with other frames isn't working if there isn't anything to ACK or anything to send once the application gets around to drain its buffer and inform transport about more credits.
Looks fine, one suggestion.
In light of the first paragraph which says that I can do whatever I want, what is the purpose of this MAY? It seems like you should either recommend that people do this or just remove the normative language.
I agree the MAY isn't doing anything here. The one thing I think should be encouraged is bundling flow control updates with other data instead of sending them in their own packets, since the frames themselves are very small.
It takes one RTT for the sender to learn that the receiver is blocked and to grant additional flow control credit, so this will lead to frequent stalls of the connection, if one receiver has nothing else to send.

Discussion:
off between resource commitment and overhead when determining how large a limit is advertised. <del> A receiver MAY use an autotuning mechanism to tune the frequency and </del> <ins> A receiver can use an autotuning mechanism to tune the frequency and </ins> amount of advertised additional credit based on a round-trip time estimate and the rate at which the receiving application consumes <del> data, similar to common TCP implementations. </del> <ins> data, similar to common TCP implementations.  As an optimization, sending frames related to flow control only when there are other frames to send or when a peer is blocked ensures that flow control doesn't cause extra packets to be sent. </ins> If a sender runs out of flow control credit, it will be unable to send new data and is considered blocked.  It is generally considered