Draft: draft-ietf-quic-manageability

Commentary: Thanks for considering and accepting my suggestions .
Paragraph (version A):
The content of Initial packets is encrypted using Initial Secrets,
which are derived from a per-version constant and the client's
destination connection ID; they are therefore observable by any on-
path device that knows the per-version constant and considered
visible in this illustration.  The content of QUIC Handshake packets
are encrypted using keys established during the initial handshake
exchange, and are therefore not visible.
Paragraph (version B):
The content of Initial packets is encrypted using Initial Secrets,
which are derived from a per-version constant and the client's
destination connection ID.  That content is therefore observable by
any on-path device that knows the per-version constant and is
considered visible in this illustration.  The content of QUIC
Handshake packets is encrypted using keys established during the
initial handshake exchange, and is therefore not visible.
Paragraph (version A):
The connection ID in the QUIC packet headers allows association of
QUIC packets using information independent of the five-tuple.  This
allows rebinding of a connection after one of the endpoints
experienced an address change - usually the client.  Further it can
be used by in-network devices to ensure that related 5-tuple flows
are appropriately balanced together.
Paragraph (version B):
The connection ID in the QUIC packet headers allows association of
QUIC packets using information independent of the five-tuple.  This
allows rebinding of a connection after one of the endpoints - usually
the client - has experienced an address change.  Further it can be
used by in-network devices to ensure that related 5-tuple flows are
appropriately balanced together.
Paragraph (version A):
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 more
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.
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 more
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
determine whether the frame can be skipped over.  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.