Draft: draft-ietf-quic-manageability

Commentary: I think there are still a few potentially misleading statements left in the text . I 'll send out a PR . 
 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 :
Paragraph (version A):
If the ClientHello is not encrypted, SNI can be derived from the
client's Initial packet by calculating the Initial secret to decrypt
the packet payload and parsing the QUIC CRYPTO Frame containing the
TLS ClientHello.
Paragraph (version B):
If the ClientHello is not encrypted, SNI can be derived from the
client's Initial packet by calculating the Initial secret to decrypt
the packet payload and parsing the QUIC CRYPTO frame(s) containing
the TLS ClientHello.
Paragraph (version A):
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.
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.  Note that there can
be multiple CRYPTO frames, and they might not be in order, so
reassembling the CRYPTO stream by parsing offsets and lengths is
required.  Further, 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 skipped over it.  Note that
the length of the frames is dependent on the frame type; see
Section 18 of QUIC-TRANSPORT.  E.g.  PADDING frames, each consisting
of a single zero byte, may occur before, after, or between CRYPTO
frames.  However, extensions might define additional frame types.  If
an unknown frame type is encountered, it is impossible to know the
length of that frame which prevents skipping over it, and therefore
parsing fails.