jiebi/CodeConvo huggingface dataset:
Change:
Instead of creating separate issues for each minor editorial comments I will put them all in this issue - I am not a fan of having normative language in the definitions. I feel those normative languages are out of context and hard to reason. It is the case for MSL definition. I would suggest that besides definition, we have some description where MSL is used and put the recommended value there. What is the difference between the initial version and original version ? if there is none why do we need to use two different call sign for the same thing? What is Tubes? we need to explain it. otherwise use other example.
I personally disagree. Mentioning the recommended value when defining the term makes it easier to understand and implement. Agreed, there was only one mention of "initial version" so I replaced that with original in It's a hypothetical example. That doesn't make it unhelpful.
:-) hmm, the example makes little sense if one does not understand the terms used in the example. If "Tube" is a hypothetical term here, then let's just mention that.
There was no reasoning, this was pulled out of a hat just like the original MSL from RFC 793. Can you send us a PR describing the reasoning you'd like to see added? Fair enough, I've added the word "hypothetical" to PR

Discussion:
all versions, and one "compatible" that allows saving the round trip but only applies when the versions are compatible. <del> The client initiates a QUIC connection by choosing an initial version and sending a first flight of QUIC packets with a long header to the server QUIC-INVARIANTS.  The client's first flight includes Version Information (see vers-info) which will be used to optionally enable compatible version negotiation (see compat-vn), and to prevent </del> <ins> The client initiates a QUIC connection by choosing an original version and sending a first flight of QUIC packets with a long header to the server QUIC-INVARIANTS.  The client's first flight includes Version Information (see vers-info) which will be used to optionally enable compatible version negotiation (see compat-vn), and to prevent </ins> version downgrade attacks (see downgrade). Upon receiving this first flight, the server verifies whether it

to be compatible with version B and for B not to be compatible with A.  This could happen for example if version B is a strict superset of version A: if version A includes the concept of streams and STREAM <del> frames, and version B includes the concepts of streams and tubes along with STREAM and TUBE frames, then A would be compatible with B but B would not be compatible with A. </del> <ins> frames, and version B includes the concept of streams and the hypothetical concept of tubes along with STREAM and TUBE frames, then A would be compatible with B but B would not be compatible with A. </ins> Note that version compatibility does not mean that every single possible instance of a first flight will succeed in conversion to the
Change:
URL here, it feel lacking normative language. The current text gives feel like there are other options the client can do and these are examples. if that is true what are those other options? if the client behave differently than described here as there is no normative language will that not cause interoperability issues?
The normative language already exists in . That said, the QUIC-VN draft is written in terms of QUIC invariants so we should tweak this.
we should or we should not?
We should
takes care of this

Discussion:
defined in QUIC) in Supported Version fields. Clients will ignore a Version Negotiation packet if it contains the <del> original version attempted by the client.  The client also ignores a Version Negotiation packet that contains incorrect connection ID fields; see QUIC-INVARIANTS. </del> <ins> original version attempted by the client; see downgrade.  The client also ignores a Version Negotiation packet that contains incorrect connection ID fields; see QUIC-INVARIANTS. </ins> Upon receiving the Version Negotiation packet, the client will search for a version it supports in the list provided by the server.  If it
Change:
Add a short text in the introduction section to define how this document updates RFC 8999.
Thanks for taking the time, Christian! I appreciate it.
We have agreed to mark this document as updating RFC 8999. Fine, but this lacks a bit of discipline. We should have a statement inside the text (not just the abstract) explaining in which way RFC 8999 is updated.
Can someone propose text here? Based on our discussion in , there is no agreement inside the IETF on what "updates" means so I'm not sure what text would be helpful for readers.
NAME see PR

Discussion:
Version Negotiation packet to indicate that the version the client chose is unacceptable, but doesn't allow the client to safely make use of that information to create a new connection with a mutually <del> supported version. </del> <ins> supported version.  This document updates QUIC-INVARIANTS by defining version negotiation mechanisms that leverage the Version Negotiation packet. </ins> With proper safety mechanisms in place, the Version Negotiation packet can be part of a mechanism to allow two QUIC implementations
Change:
No real complaint with what existed before, but I thought that this might be clearer.
Approved with one nit

Discussion:
QUIC connections are shared state between a client and a server INV. The compatible version negotiation mechanism defined in this document <del> (see compat-vn) operates inside of a QUIC connection; i.e., the packets with the original version are part of the same connection as the packets with the negotiated version.  On the other hand, the incompatible version negotiation mechanism, which leverages QUIC Version Negotiation packets (see incompat-vn) conceptually operates across two QUIC connections: one before the Version Negotiation packet, and a distinct connection after. </del> <ins> (see compat-vn) is performed as part of a single QUIC connection; that is, the packets with the original version are part of the same connection as the packets with the negotiated version. In comparison, the incompatible version negotiation mechanism, which leverages QUIC Version Negotiation packets (see incompat-vn) conceptually operates across two QUIC connections: the connection attempt prior to receiving the Version Negotiation packet is distinct from the connection with the incompatible version that follows. </ins> 4.2.
Change:
This construction directly undermines greasing by privileging the handling of greased versions. Please don't do this. As I alluded to in , this doesn't need to match the Version Negotiation packet/datagram contents. What is important here is that the list doesn't include a version that the client would have preferred to attempt over the current one. If you validate the server values that way, then you never have to worry about greased versions being different in the two different places. Indeed, you can have the server offer Version Negotiation packets that include more versions than they claim in their handshake (this being beneficial during the rollout of a fancy new version of the protocol).
Can you elaborate on how this undermines greasing? All we say is that you can add grease to version lists, but the Received Negotiation Version list needs to be transmitted as an opaque blob. We don't treat greased versions differently on receipt anywhere.
Well, the second MUST NOT pertains to something that I think should be removed. But you say "[reserved versions] MUST be ignored when parsing these fields". That tells implementations to train themselves to recognize greased versions. At that point, they are no longer treating these as versions that they just don't understand, but something special. The whole point of using an odd pattern was to ensure that this never happened.
Fair enough, if we replaced with: Would that be OK?
That's all I'm asking for. (Along with striking the echo of the VN packet, but we'll pursue that separately. The requirement there is reasonable if you assume that echoing the bits is necessary.)

Discussion:
Clients MAY include versions following the pattern "0x?a?a?a?a" in their "Compatible Version" list, and the server in their "Supported Version" list.  Those versions are reserved to exercise version <del> negotiation (see the Versions section of QUIC), and MUST be ignored </del> <ins> negotiation (see the Versions section of QUIC), and will be ignored </ins> when parsing these fields.  On the other hand, the "Received Negotiation Version" list MUST be identical to the received Version Negotiation packet, so clients MUST NOT add or remove reserved
Change:
Section 5 describes Version Downgrade Prevention. If a client receives a VN packet and selects a new attempted version, it will format the "compatible VN" extension and document in it the previously attempted version and the VN parameters. The server who understands the extension will then verify that the VN was not a downgrade attack. This supposes that the server supports the extension. If it does not, the server will ignore the parameter, and will not verify anything. It also will not include that parameter in its parameter set. What should the client do in that scenario? Should it just close the connection with versionnegotiation error?

Discussion:
Version Negotiation packets on that connection. Both endpoints MUST parse their peer's Version Information during the <del> handshake.  If the Version Information was missing or if parsing it failed (for example, if it is too short or if its length is not divisible by four), then the endpoint MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of type "TRANSPORT_PARAMETER_ERROR". </del> <ins> handshake.  If parsing the Version Information failed (for example, if it is too short or if its length is not divisible by four), then the endpoint MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of type "TRANSPORT_PARAMETER_ERROR". If the Version Information was missing, the endpoints MAY complete the handshake if they have reason to believe the peer might not support this extension.  However, if a client has reacted to a Version Negotiation packet and the Version Information was missing, the client MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of type "VERSION_NEGOTIATION_ERROR". </ins> If a client has reacted to a Version Negotiation packet, it MUST validate that the server's "Other Versions" field does not contain
Change:
The "single round trip" thing isn't really a guarantee given various factors. Setting this up as additional round trips is cleaner and more accurate. I adjusted the paragraph structure to match.
The introduction reads like the draft only defines compatible version negotiation. It probably needs to be written to be more general.
Fair enough.
Thanks, that is a lot clearer

Discussion:
VN packet to indicate that the version the client offered is unacceptable, but doesn't allow the client to safely make use of that information to create a new connection with a mutually supported <del> version.  With proper safety mechanisms in place, the VN packet can be part of a mechanism to allow two QUIC implementations to negotiate between two totally disjoint versions of QUIC, at the cost of an extra round trip.  However, it is beneficial to avoid that cost whenever possible, especially given that most incremental versions are broadly similar to the the previous version. This specification describes a simple version negotiation mechanism which optionally leverages similarities between versions and can negotiate between the set of "compatible" versions in a single round trip. </del> <ins> version. With proper safety mechanisms in place, the VN packet can be part of a mechanism to allow two QUIC implementations to negotiate between two totally disjoint versions of QUIC.  This document specifies version negotiation using VN packets, which adds an extra round trip to connection establishment if needed. It is beneficial to avoid additional round trips whenever possible, especially given that most incremental versions are broadly similar to the the previous version.  This specification also defines a simple version negotiation mechanism which leverages similarities between versions and can negotiate between the set of "compatible" versions without additional round trips. </ins> 1.1.
Change:
Though it might be the oldest version that is compatible with the most-preferred version, it isn't just "oldest".

Discussion:
7. <del> The client's first flight SHOULD be sent using the version that the server is most likely to support (in the absence of other information, this will often be the oldest version the client supports). </del> <ins> The client's first connection attempt SHOULD be made using the version that the server is most likely to support.  The client selects the version it believes to be best supported from the versions that are compatible with the client's most preferred version.  Without additional information this could mean selecting the oldest version that the client supports. </ins> 8.
Change:
Retry packets have a capital R protocols aren't "who" paragraphs are good minor edits for brevity

Discussion:
8. <del> QUIC version 1 features retry packets, which the server can send to </del> <ins> QUIC version 1 features Retry packets, which the server can send to </ins> validate the client's IP address before parsing the client's first <del> flight.  This impacts compatible version negotiation because a server who wishes to send a retry packet before parsing the client's first flight won't have parsed the client's Version Information yet.  If a future document wishes to define compatibility between two versions that support retry, that document MUST specify how version </del> <ins> flight.  A server that sends a Retry packet can do so before parsing the client's first flight.  A server that sends a Retry packet therefore might not have processed the client's Version Information before doing so. If a future document wishes to define compatibility between two versions that support retry, that document MUST specify how version </ins> negotiation (both compatible and incompatible) interacts with retry during a handshake that requires both.  For example, that could be <del> accomplished by having the server send a retry packet first and validating the client's IP address before starting version negotiation and deciding whether to use compatible version negotiation on that connection (in that scenario the retry packet would be sent using the original version). </del> <ins> accomplished by having the server send a Retry packet first and validating the client's IP address before attempting compatible version negotiation.  In that scenario the Retry packet would be sent using the original version. </ins> 9.
Change:
I just saw a provisional registration for the 0xff73db value (from the current draft). This contains a note suggesting that the value might become permanent. Given how crucial version negotiation could be, I think we should seriously consider taking a codepoint from the 0-63 range.
Agreed, that was the intent but it wasn't clear from the draft. I wrote in to make it clearer.

Discussion:
version_information <del> permanent (if this document is approved) </del> <ins> provisional </ins> This document <ins> When this document is approved, it will request permanent allocation of a codepoint in the 0-63 range to replace the provisional codepoint described above. </ins> 12.2. This document registers a new value in the QUIC Transport Error Codes

Error negotiating version <del> permanent (if this document is approved) </del> <ins> provisional </ins> This document <ins> When this document is approved, it will request permanent allocation of a codepoint in the 0-63 range to replace the provisional codepoint described above. </ins>
Change:
This draft talks about clients and servers "thinking" and "believing" things. Those verbs don't necessarily apply to protocol implementations, no matter what new frontiers we're exploring in the machine learning space. Might be worth a pass to rephrase these in terms of client or server capabilities and information. "Know" is a little fuzzier, since an endpoint does in fact possess information at certain points in the process.
So... when my computer says "thinking ...", are you saying it's lying to me?
URL

Discussion:
When the server can parse the client's first flight using the original version, it can extract the client's Version Information structure (see vers-info).  This contains the list of versions that <del> the client thinks its first flight is compatible with. </del> <ins> the client knows its first flight is compatible with. </ins> If the server supports one of the client's compatible versions, and <del> the server also believes that the original version is compatible with </del> <ins> the server also knows that the original version is compatible with </ins> this version, then the server converts the client's first flight to that version and replies to the client as if it had received the converted first flight.  The version used by the server in its reply

type TRANSPORT_PARAMETER_ERROR. If the Version Information was missing, the endpoints MAY complete <del> the handshake if they have reason to believe the peer might not support this extension.  However, if a client has reacted to a Version Negotiation packet and the Version Information was missing, the client MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of type VERSION_NEGOTIATION_ERROR. </del> <ins> the handshake.  However, if a client has reacted to a Version Negotiation packet and the Version Information was missing, the client MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of type VERSION_NEGOTIATION_ERROR. </ins> If the client received and acted on a Version Negotiation packet, the client MUST validate the server's Other Versions field.  The Other

The client's first connection attempt SHOULD be made using the version that the server is most likely to support.  The client <del> selects the version it believes to be best supported from the versions that are compatible with the client's most preferred version.  Without additional information this could mean selecting the oldest version that the client supports. </del> <ins> selects the version most likely to be supported from the versions that are compatible with the client's most preferred version. Without additional information this could mean selecting the oldest version that the client supports. </ins> 8.
Change:
Defining an error code for QUICv1 is good, but I think that you need to frame this differently. It probably needs to be framed in terms of a requirement on all QUIC versions. So rather than: You might say something like:
I like this. Can you make it a PR?

Discussion:
QUIC version 1, that connection closure MUST use a transport error of type TRANSPORT_PARAMETER_ERROR. <ins> Every QUIC version that supports version negotiation MUST define a method for closing the connection with a version negotiation error. For QUIC version 1, version negotiation errors are signaled using a transport error of type VERSION_NEGOTIATION_ERROR; see iana-error. </ins> If the Version Information was missing, the endpoints MAY complete the handshake.  However, if a client has reacted to a Version Negotiation packet and the Version Information was missing, the <del> client MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of type VERSION_NEGOTIATION_ERROR. </del> <ins> client MUST close the connection with a version negotiation error. </ins> If the client received and acted on a Version Negotiation packet, the client MUST validate the server's Other Versions field.  The Other

if it received a Version Negotiation packet that listed the versions in the server's Other Versions field, plus the negotiated version. If the client would have selected a different version, the client <del> MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of type VERSION_NEGOTIATION_ERROR.  This connection closure prevents an attacker from being able to use forged Version Negotiation packets to force a version downgrade. </del> <ins> MUST close the connection with a version negotiation error.  This connection closure prevents an attacker from being able to use forged Version Negotiation packets to force a version downgrade. </ins> This validation of Other Versions is not sufficient to prevent downgrade.  Downgrade prevention also depends on the client ignoring
Change:
Two versions might be compatible in the sense that one can convert the Initial Packet from one into the other. But one version might not have the features necessary for an application. There are two ways to mediate this that I can see: 1) The client excludes compatible versions that are inadequate for the app from its TP. This means the QUIC API will need a way for applications to control the advertised versions. 2) Servers understand what capabilities are needed and will not select an advertised compatible version that does not support them. For incompatible VN, if the server can identify the application based on IP and port, it might scrub irrelevant versions from its VN packet, though I don't know if that's a good idea or not.
When MsQuic implemented this extension, we exposed a configuration option to the app for it to specify its "desired version list". My expectation is that a client would include all acceptable QUIC versions here, and then adapt (if necessary) their protocol layer accordingly. Though, this might get harry, for instance, if they need to then choose a different ALPN based on the negotiated QUIC version (we don't currently support that).
NAME you're describing an implicit assumption of the draft: the list of supported versions are specific to an application, not just to an implementation. Perhaps we can add a sentence to make that more obvious, such as Servers don't need to do anything here, it's the client's responsibility to know what it wants to do with a given connection, not the server's.
Yes NAME that works for me. The real issue is that this not totally internal to the QUIC implementation and there needs to be an API for the application to manage this.
I agree that such an API is reasonable (Google QUICHE provides one for example) but I think that's out of scope for this document though.
I agree you shouldn't define the API, but it would be good to say, "hey, dummy, don't just advertise every compatible version the QUIC implementation supports"
Note that the relationship between version selection and ALPN is similar to the aftereffects of HTTP/2, which made the cipher selection and ALPN selection within TLS interdependent. That was a pain. It doesn't affect this draft per se, but I do hope we don't paint ourselves into that particular corner again.

Discussion:
much later - in that scenario one endpoint might be aware of the compatibility document while the other may not. <ins> When a client creates a QUIC connection, its goal is to use an application layer protocol.  Therefore, when considering which versions are compatible, clients will only consider versions that support the intended application layer protocol. </ins> 4. This document specifies two means of performing version negotiation: