Change:
Follow-on to
Thanks NAME As there are clarifications/editorial, I think we will wait for the AD review and take this PR up with a next revision before or after IETF last call. But I think it's ready to merge!
You're welcome. Agreed they're editorial, so merge whenever it makes sense.

Discussion:
3.4.1. If the ClientHello is not encrypted, SNI can be derived from the <del> 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. </del> <ins> client's Initial packet(s) by calculating the Initial secret to decrypt the packet payload and parsing the QUIC CRYPTO frame(s) containing the TLS ClientHello. </ins> As both the derivation of the Initial secret and the structure of the Initial packet itself are version-specific, the first step is always

above might fail unless the Initial secret is retained by the observer. <del> To determine the end of the header and find the start of the payload, the packet number length, the source connection ID length, and the token length need to be extracted.  The packet number length is defined by the seventh and eight bits of the header as described in Section 17.2 of QUIC-TRANSPORT, but is obfuscated as described in </del> <ins> To determine the end of the packet header and find the start of the payload, the packet number length, the source connection ID length, and the token length need to be extracted.  The packet number length is defined by the seventh and eight bits of the header as described in Section 17.2 of QUIC-TRANSPORT, but is obfuscated as described in </ins> Section 5.4 of QUIC-TLS.  The source connection ID length is specified in the byte after the destination connection ID.  The token length, which follows the source connection ID, is a variable-length integer as specified in Section 16 of QUIC-TRANSPORT. <del> 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. </del> <ins> After decryption, the client's Initial packet(s) 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 spread out over one or mor Initial packets, 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(s) 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. </ins> 3.5.