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

Commentary: As requested , all new version number , salts , etc . for QUICv2 . Verification of the test vectors would be especially valuable . 
  . Thank you very much for quickly checking , and sorry I botched every part of that . All fixed now , I hope . 
 The new test vectors works well with my QUIC implementation in Haskell . 
 Thanks  ! 
 WFM . Not validated with a real build , but a script . See for the script that I used .
The Version field of long headers is 0x709a50c4.  This randomly
chosen value is meant to avoid creating patterns in specified version
numbers.
The Version field of long headers is 0x6b3343cf.  This was generated
by taking the first four bytes of the sha256sum of "QUICv2 version
number".
This is the first 20 bytes of the sha256sum of "QUICv2 salt".
The secret is the sha256sum of "QUICv2 retry secret".  The key and
nonce are derived from this secret with the labels "quicv2 key" and
"quicv2 iv", respectively.
Draft: draft-ietf-quic-v2

Commentary: WFM , and thank you !
QUIC version 2 endpoints MUST implement the QUIC version 1
specification as described in QUIC, QUIC-TLS, and QUIC-RECOVERY.
However, the following differences apply in version 2.
The Version field of long headers is 0x709a50c4.
Except for a few differences, QUIC version 2 endpoints MUST implement
the QUIC version 1 specification as described in QUIC, QUIC-TLS, and
QUIC-RECOVERY.  The remainder of this section lists the differences.
The Version field of long headers is 0x709a50c4.  This randomly
chosen value is meant to avoid creating patterns in specified version
numbers.
The values below were chosen randomly.
Draft: draft-ietf-quic-v2

Commentary: LGTM !
If the server sends a Retry packet, it MUST use the original version.
The client ignores Retry packets using other versions.  The client
MUST NOT use a different version in the subsequent Initial packet
that contains the Retry token.  The server MAY encode the QUIC
version in its Retry token to validate that the client did not switch
versions, and drop the packet if it switched.
If the server sends a Retry packet, it MUST use the original version.
The client ignores Retry packets using other versions.  The client
MUST NOT use a different version in the subsequent Initial packet
that contains the Retry token.  The server MAY encode the QUIC
version in its Retry token to validate that the client did not switch
versions, and drop the packet if it switched, to enforce client
compliance.
Both endpoints MUST send Handshake or 1-RTT packets using the
negotiated version.  An endpoint MUST drop packets using any other
version.  Endpoints have no need to generate the keying material that
would allow them to decrypt or authenticate these packets.
Both endpoints MUST send Handshake or 1-RTT packets using the
negotiated version.  An endpoint MUST drop packets using any other
version.  Endpoints have no need to generate the keying material that
would allow them to decrypt or authenticate such packets.
Draft: draft-ietf-quic-v2

Commentary: here ( ) it is better that we call it QUIC version 1 not just QUIC . As later it is referred as QUIC version 1.here ( ) I would add reference to VN draft instead of calling it " that document"here ( ) i would add " packet " after " Initial " just to be clear , as we have now a initial version in VN draft . 
 Thanks , fixed here
QUIC QUIC has numerous extension points, including the version number
that occupies the second through fifth bytes of every long header
(see QUIC-INVARIANTS).  If experimental versions are rare, and QUIC
version 1 constitutes the vast majority of QUIC traffic, there is the
potential for middleboxes to ossify on the version bytes always being
0x00000001.
QUIC version 1QUIC has numerous extension points, including the
version number that occupies the second through fifth bytes of every
long header (see QUIC-INVARIANTS).  If experimental versions are
rare, and QUIC version 1 constitutes the vast majority of QUIC
traffic, there is the potential for middleboxes to ossify on the
version bytes always being 0x00000001.
Note that version 2 meets that document's definition of a compatible
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.
Note that version 2 meets the QUIC-VN definition of a compatible
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.
If the server sends a Retry packet, it MUST use the original version.
The client ignores Retry packets using other versions.  The client
MUST NOT use a different version in the subsequent Initial that
contains the Retry token.  The server MAY encode the QUIC version in
its Retry token to validate that the client did not switch versions,
and drop the packet if it switched.
If the server sends a Retry packet, it MUST use the original version.
The client ignores Retry packets using other versions.  The client
MUST NOT use a different version in the subsequent Initial packet
that contains the Retry token.  The server MAY encode the QUIC
version in its Retry token to validate that the client did not switch
versions, and drop the packet if it switched.
Draft: draft-ietf-quic-v2

Commentary: verbally approved . 
 Draft currently states : Is this true ? The client sends this as its Chosen Version right ? 
 I do n't think so ? If the client receives a v1 Retry and then chooses to connect via v2 for some reason , that wo n't break the transcript . 
 The " for some reason " does n't make sense to me here . If the client follows the normative language in this document and in QUIC VN , it wo n'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 .
QUIC version 2 uses the same transport parameters to authenticate the
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
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.
QUIC version 2 uses the same transport parameters to authenticate the
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
connection IDs used in the exchange, as described in QUIC.
Draft: draft-ietf-quic-v2

Commentary: , , 
 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.    { { ? 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 wo n't be included , but there 's no note saying so . I do n'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 !
Note that "version 2" is an informal name for this proposal that
indicates it is the second standards-track QUIC version.  The
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>.
Note that "version 2" is an informal name for this proposal that
indicates it is the second standards-track QUIC version.  The
protocol specified here uses a version number other than 2 in the
wire image.
QUIC version 2 endpoints MUST implement the QUIC version 1
specification as described in QUIC, QUIC-TLS, and RFC9002.  However,
the following differences apply in version 2.
QUIC version 2 endpoints MUST implement the QUIC version 1
specification as described in QUIC, QUIC-TLS, and QUIC-LOSSRECOVERY.
However, the following differences apply in version 2.
This version number will not change in subsequent versions of this
draft, unless there is a behavior change that breaks compatibility.
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.
Draft: draft-ietf-quic-v2

Commentary: The correct term from the VN document would be " original version " but just removing the word initial avoids the confusion 
 Fewer words means fewer nits
Finally QUIC-VN provides two mechanisms for endpoints to negotiate
the QUIC version to use.  The "incompatible" version negotiation
method can support switching from any initial QUIC version to any
other version with full generality, at the cost of an additional
round-trip at the start of the connection.  "Compatible" version
negotiation eliminates the round-trip penalty but levies some
restrictions on how much the two versions can differ semantically.
Finally QUIC-VN provides two mechanisms for endpoints to negotiate
the QUIC version to use.  The "incompatible" version negotiation
method can support switching from any QUIC version to any other
version with full generality, at the cost of an additional round-trip
at the start of the connection.  "Compatible" version negotiation
eliminates the round-trip penalty but levies some restrictions on how
much the two versions can differ semantically.
Draft: draft-ietf-quic-v2

Commentary:   for RFC WG
In QUIC version 1, Initial packets are encrypted with the version-
specific salt as described in Section 5.2 of QUIC-TLS.  Protecting
Initial packets in this way allows observers to inspect their
contents, which includes the TLS Client Hello or Server Hello
messages.  Again, there is the potential for middleboxes to ossify on
the version 1 key derivation and packet formats.
In QUIC version 1, Initial packets are encrypted with the version-
specific salt as described in QUIC-TLS.  Protecting Initial packets
in this way allows observers to inspect their contents, which
includes the TLS Client Hello or Server Hello messages.  Again, there
is the potential for middleboxes to ossify on the version 1 key
derivation and packet formats.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 RFC2119.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all
capitals, as shown here.
The labels used in QUIC-TLS to derive packet protection keys
(Section Section 5.1 of QUIC-TLS), header protection keys
(Section Section 5.4 of QUIC-TLS), Retry Integrity Tag keys
(Section Section 5.8 of QUIC-TLS), and key updates
(Section Section 6.1 of QUIC-TLS) change from "quic key" to "quicv2
key", from "quic iv" to "quicv2 iv", from "quic hp" to "quicv2 hp",
and from "quic ku" to "quicv2 ku", to meet the guidance for new
versions in Section Section 9.6 of QUIC-TLS of that document.
The labels used in QUIC-TLS to derive packet protection keys
(Section QUIC-TLS), header protection keys (Section QUIC-TLS), Retry
Integrity Tag keys (Section QUIC-TLS), and key updates (Section QUIC-
TLS) change from "quic key" to "quicv2 key", from "quic iv" to
"quicv2 iv", from "quic hp" to "quicv2 hp", and from "quic ku" to
"quicv2 ku", to meet the guidance for new versions in Section QUIC-
TLS of that document.
QUIC version 2 uses the same transport parameters to authenticate the
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
connection IDs used in the exchange, as described in Section 7.3 of
QUIC.  Note that the version of the first Initial and the subsequent
Retry are not authenticated by transport parameters.
QUIC version 2 uses the same transport parameters to authenticate the
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
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.
Draft: draft-ietf-quic-v2

Commentary: Though this would likely be monstrously inadvisable , I am fairly confident that I could construct an interoperable ( or at least deployable ) extension to QUIC that works in QUICv1 but not QUICv2 or vice versa . It 's OK to establish expectations , but some softening of the statement might help . 
 This seems very accurate
All QUIC extensions defined to work with version 1 also work with
version 2.
Unless otherwise stated, all QUIC extensions defined to work with
version 1 also work with version 2.
Draft: draft-ietf-quic-v2

Commentary: 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
QUIC version 2 is meant to mitigate ossification concerns and
exercise the version negotiation mechanisms.  The only change is a
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.
QUIC version 2 is meant to mitigate ossification concerns and
exercise the version negotiation mechanisms.  The only change is a
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.
Draft: draft-ietf-quic-v2

Commentary: Though no guarantee can be made , a client with a v2 ticket ( which can not 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 . 
  . 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 sentence is the " maybe if you get a ticket you could bet the other way " . Nothing firm either way , as tickets do n't represent a commitment , they only signal intent in a way that alters probabilities . 
 Got it . On balance that seems right , we ca n't proscribe too much behaviour here . Looking forward to the research papers that analyse the effects of choice in the wild during 2023 +
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
they are incorrect.
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
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.
Draft: draft-ietf-quic-v2

Commentary: Invariants uses , let 's be consistent
QUIC QUIC has numerous extension points, including the version number
that occupies the second through fifth octets of every long header
(see RFC8999).  If experimental versions are rare, and QUIC version 1
constitutes the vast majority of QUIC traffic, there is the potential
for middleboxes to ossify on the version octets always being
0x00000001.
QUIC QUIC has numerous extension points, including the version number
that occupies the second through fifth bytes of every long header
(see RFC8999).  If experimental versions are rare, and QUIC version 1
constitutes the vast majority of QUIC traffic, there is the potential
for middleboxes to ossify on the version bytes always being
0x00000001.
Draft: draft-ietf-quic-v2

Commentary: 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
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.
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.
Draft: draft-ietf-quic-v2

Commentary: Now that DoQ is in the RFCEd queue , this draft should specifically state it is compatible with both registered ALPNs .
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.
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.  In particular, both the "h3" I-D.ietf-quic-http and "doq"
I-D.ietf-dprive-dnsoquic ALPNs can operate over QUICv2.
Draft: draft-ietf-quic-v2

Commentary: As described in , 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 .
Any QUIC endpoint that supports multiple versions MUST meet the
minimum requirements described in QUIC-VN to prevent version
downgrade attacks.
Note that version 2 meets that document's definition of a compatible
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.
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.
Note that version 2 meets that document's definition of a compatible
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.
Draft: draft-ietf-quic-v2

Commentary: The original intent was to recommend compatible VN . But that does n't make any sense : compatible VN is something that the server initiates between versions that are at least partially supported . The client does n't really have any control except that it can omit versions from the TP . Incompatible VN can not happen between mutually supported versions , and the client is in control . 
 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 !
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.
Note that version 2 meets that document's definition of a compatible
version with version 1.  Therefore, v2-capable servers MUST use
compatible version negotiation unless they do not support version 1.
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.
Note that version 2 meets that document's definition of a compatible
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.
Draft: draft-ietf-quic-v2

Commentary: Get one from IANA 
 I 'll ask for 0x70 9a 50 c4 . 
 Feedback from was that you should do that after publishing a revision with that number in it . I second that .
The version field of long headers is TBD.  Note: Unless this
document is published as an RFC, implementations should use the
provisional value 0xff020000, which might change with each edition
of this document.
The version field of long headers is 0x709a50c4.