Draft: draft-ietf-quic-manageability

Commentary: The mentions . This makes the assumption that INITIAL packets carry a single CRYPTO frame . That assumption might not always hold in modern browsers , so the text should clarify that any middlebox that wishes to extract the SNI MUST perform reconstruction of the crypto stream from one or more CRYPTO frames in one or more INITIAL packets . The current assumption might lead middlebox vendors to write deploy software that does n't work if there are multiple CRYPTO frames . The section correctly states but that comes late in the section and does n't detail what middlebox vendors should do about it . That section also contains another incorrect assumption : . There are other frame types that are legal in INITIAL packets and may be sent by browsers . 
 I think this is pretty similar to , though that one is a bit more broad . Thanks for noticing the statement about Initials only containing CRYPTO and PADDING , I missed that . 
 The text already says the following now : Not sure when exactly this got but I assume this is sufficient to address this issue ? ? 
 I do n't think the new text fully addresses this issue . In the new text , this statement is incorrect : What about PING frames for example ? Additionally , the client 's first flight wo n't contain extension frames because the client has no way of knowing whether the server supports them so this statement is somewhat misleading : What are middleboxes supposed to do if they see an unknown frame type , we should provide guidance there . I think we should just tell middlebox implementors to refer to that section of RFC 9000 and expect to parse all frame types , and fail parsing if they see a frame type they do n't recognize . And while we 're at it , we should also mention that CRYPTO frames might be out of order . 
 I would expect ping frame in the initial ... so that sentence might still be fine . I think there could actually be extension frame in the first flight , e.g. if information was cached about the support of the extension . In any case , can you maybe propose text ? 
 Extension caching does n't work for initials because the server can still reject 0 - RTT at this point . How about this text : 
 was copy - pasted from and is no longer correct . In particular it assumes that the packet only contains PADDING frames and a single CRYPTO frame with offset 0 . That assumption is not guaranteed to hold with modern browsers , so this text will do more harm than good when it becomes an immutable RFC . Since we also have , I 'd suggest removing Appendix A entirely . 
 By the time this document is published , old(ie : Q043 ) versions of gQUIC that are n't compatible with the IETF QUIC invariants should be gone from the internet or very close , so I 'd suggest removing any text specific to it . It 's possible some new text on distinguishing IETF QUIC version 1 is still useful , since two sections reference this appendix .
Paragraph (version A):
sec-google-version provides non-normative guidance on the
identification of QUIC version 1 packets compared to some pre-
standard versions.
Paragraph (version A):
Note that proprietary QUIC versions, that have been deployed before
standardization, might not set the first bit in a QUIC long header
packet to 1.  To parse these versions, example code is provided in
the appendix (see sec-google-version).  However, it is expected that
these versions will gradually disappear over time.
Paragraph (version B):
Note that proprietary QUIC versions, that have been deployed before
standardization, might not set the first bit in a QUIC long header
packet to 1.  However, it is expected that these versions will
gradually disappear over time.
Paragraph (version A):
After decryption, the client's Initial packet can be parsed to detect
the CRYPTO frame that contains the TLS ClientHello, which then can be
parsed similarly to TLS over TCP connections.  The client's Initial
packet may contain other frames, so the first bytes of each frame
need to be checked to identify the frame type, and if needed skip
over it.  Note that the length of the frames is dependent on the
frame type.  In QUIC version 1, the packet is expected to contain
only CRYPTO frames and optionally PADDING frames.  PADDING frames,
each consisting of a single zero byte, may occur before, after, or
between CRYPTO frames.  There might be multiple CRYPTO frames.
Finally, an extension might define additional frame types which could
be present.
Paragraph (version B):
After decryption, the client's Initial packet can be parsed to detect
the CRYPTO frame(s) that contains the TLS ClientHello, which then can
be parsed similarly to TLS over TCP connections.  The client's
Initial packet may contain other frames, so the first bytes of each
frame need to be checked to identify the frame type, and if needed
skip over it.  Note that the length of the frames is dependent on the
frame type.  In QUIC version 1, the packet is expected to contain
only CRYPTO frames and optionally PADDING frames.  PADDING frames,
each consisting of a single zero byte, may occur before, after, or
between CRYPTO frames.  There might be multiple CRYPTO frames.
Finally, an extension might define additional frame types which could
be present.