jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-quic-version-negotiation

Commentary: indicates that the address tuple used for the first flight remain stable . This is probably OK , but I think that this is unnecessary . What seems particularly risky here is anticipating the rules about connection IDs that might apply to both versions : My preference here is to drop this text entirely and leave it to the negotiated version to specify these rules . Once you have performed whatever mapping / transformation that is defined , then the first flight complies with the requirements of the negotiated version and you are subject to the rules of that version . Trying to manage the intersection of both sets of rules is complicated . Better not to chase down that rabbit hole ( I 've been there ) . FWIW , I fully expect v2 to also specify address tuple stability during the handshake . However , if it does not and a client can send a v2 first flight on multiple tuples ( leaving aside the implausibility of expecting those datagrams to arrive at the same place ) , then that wo n't be naturally compatible with v1 and you wo n't be able to start with v2 in that way and expect to be able to negotiate v1 out of that . This is no different than your new , optional frame example . 
 I think we need to state something about 5 - tuple stability here , because if version A requires 5 - tuple stability and version B requires 5 - tuple stability , neither of those documents specifies that the two halves of the handshake ( the first half using A , and the second half using B ) need 5 - tuple stability between them . 
 I do n't think that you need to say anything about that specifically . You might use it as an example in a sentence like : 
 Fair enough , that works for me .
For the duration of the compatible version negotiation process,
clients MUST use the same 5-tuple (source and destination IP
addresses and UDP port numbers).  During that time, clients MUST also
use the same Destination Connection ID, except if the server
explicitly instructs the client to use a different Destination
Connection ID (for example, a QUIC version 1 server can accomplish
this by sending an INITIAL packet with a Source Connection ID that
differed from the client's Destination Connection ID).  This allows
load balancers to ensure that packets for a given connection are
routed to the same server.
Note that, after the first flight is converted to the negotiated
version, the handshake completes in the negotiated version.  The
entire handshake (including the converted first flight) needs to
conform to the rules of the negotiated version.  For instance, if the
negotiated version requires that the 5-tuple remain stable for the
entire handshake (as QUIC version 1 does), then this applies to the
entire handshake, including the first flight.
Draft: draft-ietf-quic-version-negotiation

Commentary: I think that the answer is " no " ( see also Betteridge 's Law ) in that the format is version - specific , but is pretty obtuse about this : The first sentence reads as an absolute ; the second is clearly narrowly scoped . But then nothing is said about other versions . As I mentioned with error codes in , I think that the way this needs to be phrased is as a requirement on QUIC versions that support version negotiation . The requirement is that those protocols need to define a way to carry certain information . You can then define that information in the abstract when articulating that requirement ; again see . The concrete form you choose for v1 then only needs to apply to v1 . 
 The intention was for the handshake version information to be invariant , and for how it is conveyed to be version - specific . But I agree that we should state that versions need an authenticated way to exchange handshake version information . 
 It needs to go further than that . I think that you need to list , concretely , what information is being authenticated . And you need to explain the consequences , namely : And then in Section 4 , say precisely what information needs to be authenticated in order to achieve this goal , with a concrete definition for how the information is carried in QUIC version 1 transport parameters . 
 That works for me .
During the handshake, endpoints will exchange Version Information,
which consists of a chosen version and a list of other versions.  Any
version of QUIC that supports this mechanism MUST provide a mechanism
to exchange Version Information in both directions during the
handshake, such that this data is authenticated.
Draft: draft-ietf-quic-version-negotiation

Commentary: In : This is not an issue . If v2 defines a new frame type that can appear in Initial - equivalent packets , then to be compatible with v1 ( in both directions ) that frame type could simply be optional in v2 . The lack of a self - describing encoding is not an issue as the parsing of the v2 packet is done with knowledge of all the core frame types in v2 . Sure , you ca n't introduce an extension frame here , but that 's true of v1 on its own . The only way in which a version might become incompatible is if it includes new information that ca n't be inferred from the other version or does n't have a valid default . I think that the intent of this was to say that if there is any need for the Initial flight to carry new information that is only consumed by a compatible version , then there is no way for QUIC version 1 to carry that new information by using new frames . Instead , it has to use a field in v1 that would be ignored by a v1 endpoint . As v1 defines no real extension points of this sort , the options in this case are limited . I think that this text can be removed . Maybe you could talk about the problem of carrying version - specific information in other versions . 
 This makes sense . This text was somewhat vestigial from earlier designs of this mechanism .
In order to facilitate the deployment of future versions of QUIC,
designers of future versions SHOULD attempt to design their new
version such that commonly deployed versions are compatible with it.
For example, a successor to QUIC version 1 may wish to design its
transport parameters in a way that does not preclude compatibility.
Additionally, frames in QUIC version 1 do not use a self-describing
encoding, so unrecognized frame types cannot be parsed or ignored
(see the Extension Frames section of QUIC); this means that new
versions that wish to be very similar to QUIC version 1 and
compatible with it should avoid introducing new frames in initial
packets.
In order to facilitate the deployment of future versions of QUIC,
designers of future versions SHOULD attempt to design their new
version such that commonly deployed versions are compatible with it.
For example, a successor to QUIC version 1 may wish to design its
transport parameters in a way that does not preclude compatibility.
Draft: draft-ietf-quic-version-negotiation

Commentary: 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 do n'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 do n't currently support that ) . 
 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 do n'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 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 should n't define the API , but it would be good to say , " hey , dummy , do n'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 does n't affect this draft per se , but I do hope we do n't paint ourselves into that particular corner again .
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.
Draft: draft-ietf-quic-version-negotiation

Commentary: 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 ?
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
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.
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.
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
client MUST close the connection with a version negotiation error.
If the client received and acted on a Version Negotiation packet, the
client MUST validate the server's Other Versions field.  The Other
Versions field is validated by confirming that the client would have
attempted the same version with knowledge of the versions the server
supports.  That is, the client would have selected the same version
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
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.
If the client received and acted on a Version Negotiation packet, the
client MUST validate the server's Other Versions field.  The Other
Versions field is validated by confirming that the client would have
attempted the same version with knowledge of the versions the server
supports.  That is, the client would have selected the same version
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
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.
Draft: draft-ietf-quic-version-negotiation

Commentary: The draft says explicitly that receiving Version Negotiation terminates a connection attempt . This is n't consistent with that . This probably needs to say something like this instead : 
 That sounds good to me , can you make this a PR ?
Clients MUST ignore any received Version Negotiation packets that
contain the version that they initially attempted.  Once a client has
reacted to a Version Negotiation packet, it MUST drop all subsequent
Version Negotiation packets on that connection.
Clients MUST ignore any received Version Negotiation packets that
contain the version that they initially attempted.  A client that
makes a connection attempt based on information received from a
Version Negotiation packet MUST ignore any Version Negotiation
packets it receives in response to that connection attempt.
Draft: draft-ietf-quic-version-negotiation

Commentary: 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 was n't clear from the draft . I wrote in to make it clearer .
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.
Draft: draft-ietf-quic-version-negotiation

Commentary: Retry packets have a capital R protocols are n't " who " paragraphs are good minor edits for brevity
QUIC version 1 features retry packets, which the server can send to
validate the client's IP address before parsing the client's first
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
negotiation (both compatible and incompatible) interacts with retry
during a handshake that requires both.  For example, that could be
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).
QUIC version 1 features Retry packets, which the server can send to
validate the client's IP address before parsing the client's first
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
negotiation (both compatible and incompatible) interacts with retry
during a handshake that requires both.  For example, that could be
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.
Draft: draft-ietf-quic-version-negotiation

Commentary: Though it might be the oldest version that is compatible with the most - preferred version , it is n't just " oldest " .
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).
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.
Draft: draft-ietf-quic-version-negotiation

Commentary: The " single round trip " thing is n'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
The version-invariant properties of QUIC INV define a version
negotiation (VN) packet but do not specify how an endpoint reacts
when it receives one.  QUIC version 1 QUIC allows the server to use a
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
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.
The version-invariant properties of QUIC INV define a version
negotiation (VN) packet but do not specify how an endpoint reacts
when it receives one.  QUIC version 1 QUIC allows the server to use a
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
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.
Draft: draft-ietf-quic-version-negotiation

Commentary: 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 ?
Both endpoints MUST parse their peer's Version Information during the
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".
Both endpoints MUST parse their peer's Version Information during the
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".
Draft: draft-ietf-quic-version-negotiation

Commentary: Bijective should be symmetric . We 're describing a relation not a function . This is a very minor comment , will send a PR hopefully soon . 
 Indeed , my math is pretty rusty :) Totally agree with you , and thanks for offering to write the PR ! 
 any luck with the PR ? 
 I completely forgot about this ! 
 opened 
 Closing now that has been merged .
Version compatibility is not bijective: it is possible for version A
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.
Version compatibility is not symmetric: it is possible for version A
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.
Draft: draft-ietf-quic-version-negotiation

Commentary: This construction directly undermines greasing by privileging the handling of greased versions . Please do n't do this . As I alluded to in , this does n't need to match the Version Negotiation packet / datagram contents . What is important here is that the list does n'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 do n'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 do n'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 . )
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
negotiation (see the Versions section of QUIC), and MUST be ignored
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
version from that list.
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
negotiation (see the Versions section of QUIC), and will be ignored
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
version from that list.