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

Commentary: See 
 This matches the registry . 17 !
This document registers a new value in the "QUIC Transport
Parameters" registry maintained at
<<https://www.iana.org/assignments/quic>>.
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.
This document registers a new value in the "QUIC Transport Error
Codes" registry maintained at <<https://www.iana.org/assignments/
quic>>.
IANA has registered the following value in the "QUIC Transport
Parameters" registry maintained at
<<https://www.iana.org/assignments/quic>>.
Draft: draft-ietf-quic-version-negotiation

Commentary: This was raised during the
Only servers can start incompatible version negotiation: clients MUST
NOT send Version Negotiation packets and servers MUST ignore all
received Version Negotiation packets.
Draft: draft-ietf-quic-version-negotiation

Commentary: This was raised during the 
 With my comment .
A version downgrade is an attack where a malicious entity manages to
make the QUIC endpoints negotiate a QUIC version different from the
one they would have negotiated in the absence of the attack.  The
mechanism described in this document is designed to prevent downgrade
attacks.
Draft: draft-ietf-quic-version-negotiation

Commentary: 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 . 
 see PR
The version-invariant properties of QUIC QUIC-INVARIANTS define a
Version Negotiation packet but do not specify how an endpoint reacts
when it receives one.  QUIC version 1 QUIC allows the server to use a
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
supported version.
The version-invariant properties of QUIC QUIC-INVARIANTS define a
Version Negotiation packet but do not specify how an endpoint reacts
when it receives one.  QUIC version 1 QUIC allows the server to use a
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
supported version.  This document updates QUIC-INVARIANTS by defining
version negotiation mechanisms that leverage the Version Negotiation
packet.
Draft: draft-ietf-quic-version-negotiation

Commentary: 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
Clients will ignore a Version Negotiation packet if it contains the
original version attempted by the client.  The client also ignores a
Version Negotiation packet that contains incorrect connection ID
fields; see QUIC-INVARIANTS.
Clients will ignore a Version Negotiation packet if it contains the
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.
Draft: draft-ietf-quic-version-negotiation

Commentary: Instead of creating separate issues for each minor editorial comments I will put them all in this issue - 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 . 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 ? is  ? 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 does n'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 ? Fair enough , I 've the word " hypothetical " to PR
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
version downgrade attacks (see downgrade).
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
version downgrade attacks (see downgrade).
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: if version A includes the concept of streams and STREAM
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.
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: if version A includes the concept of streams and STREAM
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.
Draft: draft-ietf-quic-version-negotiation

Commentary: editorial nit : for consitency with RFC 9000 , consider changing you reference name from [ INV ] -[QUIC - INVARIANTS ]
The version-invariant properties of QUIC INV define a Version
Negotiation packet but do not specify how an endpoint reacts when it
receives one.  QUIC version 1 QUIC allows the server to use a 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 supported
version.
The version-invariant properties of QUIC QUIC-INVARIANTS define a
Version Negotiation packet but do not specify how an endpoint reacts
when it receives one.  QUIC version 1 QUIC allows the server to use a
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
supported version.
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 INV.  The client's first flight includes Version Information
(see vers-info) which will be used to optionally enable compatible
version negotation (see compat-vn), and to prevent version downgrade
attacks (see downgrade).
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 negotation (see compat-vn), and to prevent version
downgrade attacks (see downgrade).
Clients will ignore a Version Negotiation packet if it contains the
original version attempted by the client.  The client also ignores a
Version Negotiation packet that contains incorrect connection ID
fields; see INV.
Clients will ignore a Version Negotiation packet if it contains the
original version attempted by the client.  The client also ignores a
Version Negotiation packet that contains incorrect connection ID
fields; see QUIC-INVARIANTS.
QUIC connections are shared state between a client and a server INV.
The compatible version negotiation mechanism defined in this document
(see compat-vn) is performed as part of a single QUIC connection;
that is, the packets with the client's chosen version are part of the
same connection as the packets with the negotiated version.
QUIC connections are shared state between a client and a server QUIC-
INVARIANTS.  The compatible version negotiation mechanism defined in
this document (see compat-vn) is performed as part of a single QUIC
connection; that is, the packets with the client's chosen version are
part of the same connection as the packets with the negotiated
version.
Draft: draft-ietf-quic-version-negotiation

Commentary: Section 2.5 says unconditionally that the client chooses the most compatible version . This is n't right , because the most compatible version is n't what it is looking to end up on . What the client should choose is probably the most compatible version of those that are compatible ( directionality ? ) with its most preferred version . 
  this , I think the directionality is correct in the existing text . But perhaps we could figure out better wording . 
 LGTM with the following edits .
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 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.
The server knows how to parse first flights from the original
version.
The original version is compatible with the client's preferred
version.
Without additional information, this could mean selecting the oldest
version that the client supports.
Draft: draft-ietf-quic-version-negotiation

Commentary: I am not sure that I agree with this as some state carries across from the first connection attempt to the second ( and hopefully successfully completed ) connection . ( Also , I 've implemented this within the same connection object . I know that other implementations differ here , so what I 'm looking for is a little finesse in how this is framed . )
Note that this separation across two connections is conceptual: it
applies to normative requirements on QUIC connections, but does not
require implementations to internally use two distinct connection
objects.
Draft: draft-ietf-quic-version-negotiation

Commentary: LGTM . 
 This is a very important section , but I found it to be a little muddy . In particular , the directionality of the phrase A is compatible with B was unclear . An example would help here , I think .
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.
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: if version A includes the concept of streams and STREAM
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.
Draft: draft-ietf-quic-version-negotiation

Commentary: Can an ALPN label be used for multiple QUIC versions ? I think that the text should say something like : adds ( and I wholly agree ): 
 I 'm merging into this one where said " The point is that your ALPN offer when you offer QUICvX should n't be dependent on if you did VN or not . " 
 LGTM
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 one of the intended application layer protocols.  For
example, if the client's first flight advertises multiple Application
Layer Protocol Negotiation (ALPN) ALPN tokens and multiple compatible
versions, the server needs to ensure that the ALPN token that it
selects can run over the QUIC version that it selects.
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 one of the intended application layer protocols.  If the
client's first flight advertises multiple Application Layer Protocol
Negotiation (ALPN) ALPN tokens and multiple compatible versions, it
is possible for some application layer protocols to not be able to
run over some of the offered compatible versions.  It is the server's
responsibility to only select an ALPN token that can run over the
compatible QUIC version that it selects.
The new QUIC version supports the transport features required by
the application protocol.
The new QUIC version supports ALPN.
The version of QUIC for which the ALPN token was originally
defined is compatible with the new QUIC version.
When incompatible version negotiation is in use, the second
connection which is created in response to the received version
negotiation packet MUST restart its application layer protocol
negotiation process without taking into account the original version.
Draft: draft-ietf-quic-version-negotiation

Commentary: Should an endpoint be required to reject a transport parameter that contains 0 ? 
 Sure . 
 CC with ? 
 That 's what I currently have in my implementation :) 
 Off topic but what if version 0 is included in Supported Version of a VN packet ? 
 That would make the VN packet malformed . I 'd suggest either dropping such packets or ignoring the zero . 
 OK . I modified my client to drop such packets as same as the case of the original version included . 
 I considered treating it as an error , but as it is an unauthenticated packet , it 's better to drop it . I 've done the same for ours .
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.
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 an endpoint receives a Chosen
Version equal to zero, or any Other Version equal to zero, it MUST
treat it as a parsing failure.
Draft: draft-ietf-quic-version-negotiation

Commentary: Mix recommendations of and 
 LGTM 
 The document currently says : However , as we see with HTTP over TCP , clients routinely offer " h2 " , " http/1.1 " and are content with either selection . Particularly if ALPN tokens map 1:1 to QUIC versions as specified in H3 , the client 's goal might be to use any of a collection of application - layer protocols . Perhaps tweak this to " ... support one of the intended application layer protocols . " ? The first statement might or might not need to be expanded as well . 
 Perhaps we add a sentence after the ones you quoted along the lines of " For example , if the client 's first flight advertises multiple ALPN tokens and multiple compatible versions , the server needs to ensure that the ALPN token that it selects can run over the QUIC version that it selects . "
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.
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 one of the intended application layer protocols.  For
example, if the client's first flight advertises multiple Application
Layer Protocol Negotiation (ALPN) RFC7301 tokens and multiple
compatible versions, the server needs to ensure that the ALPN token
that it selects can run over the QUIC version that it selects.
Draft: draft-ietf-quic-version-negotiation

Commentary: This is 's proposed text to fix this issue . 
 LGTM . I am going to merge this on the basis of it being  's text and my approval . 
 LGTM 
 Section 9 is pretty clear that ' compatible versions ' might not have commonly usable 0 - RTT packets . But Section 3 defines ' compatible ' as a translatable first flight . 0 - RTT is part of the first flight , so one of these definitions has to change . 
 That does n't necessarily follow . You can translate a first flight in a way that 0 - RTT is rejected and the 0 - RTT packets are just dropped and the handshake will still succeed . I 'm not sure I see an inconsistency here . 
 Having read sec 3 a few times now , I see the subtlety in your point . 0 - RTT could fall under the third paragraph as something that ca n't be included to be compatible . I still do n't really like the definition . I 'll think on it some more , but I 'd prefer something like " A is said to be ' compatible ' with B if the first flight of A contains all the information minimally necessary to complete a first flight of B. " So to be compatible with v1 , vx needs to contain a TLS 1.3 client hello including TPs for version negotiation and all the other required v1 TPs . For v1 to be compatible with vx , v_x must not have any additional information to complete its first fligth besides the client hello at the v1 TPs . Whether or not there 's 0 - RTT in the flight does n't matter . We are drifting into the editorial , but if you like that definition I 'm happy to write a PR . 
 I 'm not sure " minimally necessary " is well - defined . How about something like :
If A and B are two distinct versions of QUIC, A is said to be
"compatible" with B if it is possible to take a first flight of
packets from version A and convert it into a first flight of packets
from version B.  As an example, if versions A and B are absolutely
equal in their wire image and behavior during the handshake but
differ after the handshake, then A is compatible with B and B is
compatible with A.
If A and B are two distinct versions of QUIC, A is said to be
"compatible" with B if it is possible to take a first flight of
packets from version A and convert it into a first flight of packets
from version B.  As an example, if versions A and B are absolutely
equal in their wire image and behavior during the handshake but
differ after the handshake, then A is compatible with B and B is
compatible with A.  Note that the conversion of the first flight can
be lossy: some data such as QUICv1 0-RTT packets could be ignored
during conversion and retransmitted later.
Draft: draft-ietf-quic-version-negotiation

Commentary: After pushback from I think this covers the main point with a whole lot less text . 
 As discussed in , there are various levels of partial support for this standard , different for client and server , and there ought to be normative language around these capabilities . There are certain modes that MUST be supported along with multiple versions , and others that are just performance improvements . AFAICT , for any server that supports 1 versions , there are two possible levels of support : the TP and support incompatible negotiation compatible negotiation For a client , it 's more complicated : proposes : support : do not the send nor parse the TP . If you get a VN packet , fail the QUIC connection prevention only : send the TP with only one other version , also parse and validate the TP . If you get a VN packet , fail the QUIC connection . This protects against intermediaries that are rewriting the version field on Initial packets . In v1 / v2 , these attacks will be detected by the authenticated version field in subsequent handshake packets , but that is not generalizable to all versions of QUIC . only : downgrade prevention and be prepared to accept an upgrade only : advertise only one version , so there 's downgrade prevention when trying again with new version after a VN packet . : downgrade prevention , compatible VN and incompatible VN 
 LGTM
Note also that the client can disable compatible version negotiation
by only including the Chosen Version in the Other Versions field of
the Version Information Transport Parameter.
Draft: draft-ietf-quic-version-negotiation

Commentary: The draft says : Server - Sent Other Versions : When sent by a server , the Other  field lists all the Fully - Deployed Versions of this server deployment , see Section 2 . Note that the version in the Chosen Version field is not necessarily included in this list , because the server operator could be in the process of removing support for this version . For the same reason , this field MAY be empty . But the syntax is : What does the draft exactly mean by " this field MAY be empty " ? 
 The " Other Versions " field contains a list of versions , whose length can be zero . That text exists to remind people that the list of Fully - Deployed Versions can be empty , and that should n't cause handshake failures . 
 The text is far from clear , because the sentence mixes references to " Other Versions " and " Chosen version " . Stating " For the same reason , the Other Versions field MAY be empty " would remove the ambiguity . 
 Thanks for clarifying , I 've written that up as .
When sent by a server, the Other Versions field lists all the
Fully-Deployed Versions of this server deployment, see server-
fleet.  Note that the version in the Chosen Version field is not
necessarily included in this list, because the server operator
could be in the process of removing support for this version.  For
the same reason, this field MAY be empty.
When sent by a server, the Other Versions field lists all the
Fully-Deployed Versions of this server deployment, see server-
fleet.  Note that the version in the Chosen Version field is not
necessarily included in this list, because the server operator
could be in the process of removing support for this version.  For
the same reason, the Other Versions field MAY be empty.