Draft: draft-ietf-quic-v2

Commentary: , , , , , . 
 Just a style thing ( and something we should try an capture in a QUIC style guide ) . 
 There a bit of inconsistency through the document . Personally I prefer the QUIC version N style . 
 is there a missing word here ? 
 Nope , extra word , thanks 
 I find this awkward to read in isolation , it requires converting the RFC 9000 types definition format into a different encoding to realize there is a change . A clearer alternative could be " All version 2 Long Packet Types are different : Initial : 0b01 0 - RTT : 0b10 Handshake 0b11 Retry : 0b00 
 Starting with This might be a matter of style but to me the term " changes " imply that you 're modifying the original , not creating something new . How about we term these as differences instead ? The the opening paragraph of Section 3 could be something like " QUIC version 2 endpoints MUST implement the QUIC version 1 specification as described in ] , ] , and ] . However , the following differences apply in version 2 . " 
 This might have been important earlier in the document lifetime but it seems to stick out now . 
 This could be misread to imply the salt is universally known and universally applicable , which I do n't think is your intention . In fact , I find the construction of this entire paragraph a bit awkward . Can we rephrase this for better clarity ? Something like " 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 Clent Hello or Server Hello messages . Again , there is the potential for middleboxes to ossify on the 1 key derivation and packet formats . " 
 Couple of nits but otherwise LGTM
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.
Furthermore, version 1 Initial packets are encrypted with keys
derived from a universally known salt, which allow observers to
inspect the contents of these packets, which include the TLS Client
Hello and Server Hello messages.  Again, middleboxes may ossify on
the version 1 key derivation and packet formats.
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.
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.
I-D.duke-quic-version-aliasing is a more robust, but much more
complicated, proposal to address these ossification problems.  By
design, it requires incompatible version negotiation.  QUICv2 enables
exercise of compatible version negotiation mechanism.
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.
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.
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.
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 QUIC version 1 connection to
initiate a QUIC version 2 connection, or vice versa.
QUIC version 2 provides protection against some forms of
ossification.  Devices that assume that all long headers will contain
encode version 1, or that the version 1 Initial key derivation
formula will remain version-invariant, will not correctly process
version 2 packets.
QUIC version 2 provides protection against some forms of
ossification.  Devices that assume that all long headers will encode
version 1, or that the version 1 Initial key derivation formula will
remain version-invariant, will not correctly process version 2
packets.
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.
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 QUIC version 1 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 QUIC version 2.