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

Commentary: Also , add structure to the " changes from v1 " section . 
 It would be a simple matter to switch around the packet type codes in long headers , e.g. 0x0 = Retry 0x1 = Handshake 0x2 = 0 - RTT 0x3 = Initial so no one ossifies on 0x0 = Initial . 
 I 'm ambivalent on this . It 's fairly trivial to have the long header parsed in version - specific fashion , so it 's easy to implement , but I 'm not sure how much value it has . It also makes reading packets slightly harder .
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.
QUIC version 2 endpoints MUST implement the QUIC version 1
specification as described in QUIC, QUIC-TLS, and RFC9002, with the
following changes.
Initial packets use a packet type field of 0b01. 0-RTT packets use a
packet type field of 0b10.  Handshake packets use a packet type field
of 0b11.  Retry packets use a packet type field of 0b00.
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.
Draft: draft-ietf-quic-v2

Commentary: fixed up IAW with your comments . PTAL 
 It is necessary to specify how retry works when a compatible upgrade is used . The easiest way to specify this is to say that Retry can be sent in version 1 , but the validation is performed as though a version 2 retry was sent . That 's what I 've seen implemented thus far . 
 Here 's the relevant text in your PR ( numbers mine ) ( 1 ) A server SHOULD produce a Retry packet in the same version as the Initial packet that the Retry packet responds to . ( 2 ) Validation of the Retry exchange uses the logic of the final negotiated version , treating the Retry as if it were sent in that version . ( 3 ) This means that the version used for Retry is not authenticated , only that it occurred and the connection ID that was used . ( 1 ) I made it a MUST in the recent merge , to make it a bit easier for clients . ( 2 ) I 'm not really sure what this means in the context of v1 / v2 -- the logic is identical in both cases . Maybe this is something for the v1 - vn text ( pending ) in the VN doc ? But yeah , anything in the client hello , including the retry TPs , are processed syntactically as v1 but the content is used for v2 purposes . Do I understand the takeaway correctly ? ( 3 ) This is a fair point to make , I guess : the Retry logic only ever measured that the CIDs matched . But , meh ? The client changing the version between connection attempts would be strange , but legal and not obviously dangerous . If you think this sentence is valuable , I can add it . 
 . , this was just a wording choice of mine . I do think that the validation is an important point to be clear on , lest people decide to skip it . I do n't think that this can be part of the VN document at least as it stands as the Retry mechanism is version - specific and so any handling of it also needs to be . is really just noting the limitations of the validation . I do n't think that it has security consequences , particularly if the client enforces the requirement that Retry use the original version ( which , presumably they are permitted to ... by dropping the packet ) . 
 is going to introduce some considerations specific to v1 . Nevertheless , I 'm happy to write something down here .
If the server elects to send a Retry packet, it MUST do so using the
original version.
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.
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.
Draft: draft-ietf-quic-v2

Commentary: This uses kramdown tricks to make real links for the section references to RFC 9001 and uses a nicer label for those .
QUIC RFC9000 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 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.
The labels used in RFC9001 to derive packet protection keys (Sec
(Sec 5.8), and key updates (Sec 6.1) 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 9.6 of that document.
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.
Draft: draft-ietf-quic-v2

Commentary: The draft should state explicitly that all v1 extensions can be applied to v2 connections .
All QUIC extensions defined to work with version 1 also work with
version 2.
Draft: draft-duke-quic-v2

Commentary: One way to 
 I have a feeling you 'll need to say that this " updates " HTTP/3 . 
 on slack some are saying we should roll a new h3 ALPN for running over  . I can not quite follow the argument but this is a better venue for the discussion . 
 You definitely need a new specification , because a different QUIC version might not be suitable . You either say : h3 can be used with QUICv2 , or h3q2 ( or whatever new string you like ) identifies HTTP/3 when running over QUICv2 . There are lots of arguments as to why you might choose to do one or the other . 
 I 'm swayed more toward a new ALP.N at the moment 
 FWIW we painted ourselves into this corner . We punting on the problem and simply tied H3 to v1 . Now we are actively trying to solve VN we might be able to pay back the tech debt . For example , a document that updates H3 to say that it can work over versions compatible with v1 . Incompatible versions could still need to defined as a new application mapping , 
 Whatever we do , I think we need to ensure that servers can give sufficient information to clients via    so that the client can pick a compatible version ( if any ) and avoid VN . This could , then , be solved via    layer or via ALPN , but I think this is any important property . 
 Well " avoiding VN " is only important to the extent that we ca n't do compatible VN . 
 I think we want to allow the existence of a server that only supports v2 and servers that only support v1 .... and clients that only support v2 and clients that only support v1 . Given this , there will be client : server pairs which do not support any mutually compatible options . It seems like it would be desirable for clients to be able to deduce this from    without needing to see the QUIC connection to the server fail ? 
 Oh , and this text from the HTTP/3 docs is probably relevant :
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.