Draft: draft-ietf-quic-manageability

Commentary: Follow - on to 
 Thanks 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 .
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(s) containing
the TLS ClientHello.
Paragraph (version B):
If the ClientHello is not encrypted, SNI can be derived from the
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.
Paragraph (version A):
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
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.
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.  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.
Paragraph (version B):
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
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.
Paragraph (version B):
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.