Draft: draft-ietf-quic-manageability

Commentary: The RFC 9000 term is " long header packet " ; I 'm not a fan of adding hyphenation 
 ah , right . should we change " long packet header " to " long header " instead ? 
 yes please ! That would be consistent with how the terms are used in RFC 9000 ( and elsewhere in this document ) 
 done ...
Paragraph (version A):
This document describes version 1 of the QUIC protocol, whose wire
image is fully defined in QUIC-TRANSPORT and QUIC-TLS.  Features of
the wire image described herein may change in future versions of the
protocol, except when specified as an invariant QUIC-INVARIANTS, and
cannot be used to identify QUIC as a protocol or to infer the
behavior of future versions of QUIC.
Paragraph (version B):
This document addresses version 1 of the QUIC protocol, whose wire
image is fully defined in QUIC-TRANSPORT and QUIC-TLS.  Features of
the wire image described herein may change in future versions of the
protocol, except when specified as an invariant QUIC-INVARIANTS, and
cannot be used to identify QUIC as a protocol or to infer the
behavior of future versions of QUIC.
Paragraph (version A):
source and destination connection ID: short and long packet
headers carry a destination connection ID, a variable-length field
that can be used to identify the connection associated with a QUIC
packet, for load-balancing and NAT rebinding purposes; see sec-
loadbalancing and rebinding.  Long packet headers additionally
carry a source connection ID.  The source connection ID
corresponds to the destination connection ID the source would like
to have on packets sent to it, and is only present on long packet
headers.  On long header packets, the length of the connection IDs
is also present; on short header packets, the length of the
destination connection ID is implicit.
Paragraph (version B):
source and destination connection ID: short and long headers carry
a destination connection ID, a variable-length field that can be
used to identify the connection associated with a QUIC packet, for
load-balancing and NAT rebinding purposes; see sec-loadbalancing
and rebinding.  Long packet headers additionally carry a source
connection ID.  The source connection ID corresponds to the
destination connection ID the source would like to have on packets
sent to it, and is only present on long headers.  On long header
packets, the length of the connection IDs is also present; on
short header packets, the length of the destination connection ID
is implicit.
Paragraph (version A):
latency spin bit: The third-most-significant bit of the first
octet in the short packet header for version 1.  The spin bit is
set by endpoints such that tracking edge transitions can be used
to passively observe end-to-end RTT.  See spin-usage for further
details.
Paragraph (version B):
latency spin bit: The third-most-significant bit of the first
octet in the short header for version 1.  The spin bit is set by
endpoints such that tracking edge transitions can be used to
passively observe end-to-end RTT.  See spin-usage for further
details.
Paragraph (version A):
packet number: All packets except Version Negotiation and Retry
packets have an associated packet number; however, this packet
number is encrypted, and therefore not of use to on-path
observers.  The offset of the packet number can be decoded in long
headers, while it is implicit (depending on destination connection
ID length) in short headers.  The length of the packet number is
cryptographically obfuscated.
Paragraph (version A):
key phase: The Key Phase bit, present in short headers, specifies
the keys used to encrypt the packet to support key rotation.  The
Key Phase bit is cryptographically obfuscated.
Paragraph (version B):
packet number: All packets except Version Negotiation and Retry
packets have an associated packet number; however, this packet
number is encrypted, and therefore not of use to on-path
observers.  The offset of the packet number can be decoded in long
headers, while it is implicit (depending on destination connection
ID length) in short headers.  The length of the packet number is
cryptographically protected.
Paragraph (version B):
key phase: The Key Phase bit, present in short headers, specifies
the keys used to encrypt the packet to support key rotation.  The
Key Phase bit is cryptographically protected.
Paragraph (version A):
A Client Initial packet exposes the version, source and destination
connection IDs without encryption.  The payload of the Initial packet
is obfuscated using the Initial secret.  The complete TLS Client
Hello, including any TLS Server Name Indication (SNI) present, is
sent in one or more CRYPTO frames across one or more QUIC Initial
packets.
Paragraph (version A):
The Server Initial datagram also exposes version number, source and
destination connection IDs in the clear; the payload of the Initial
packet(s) is obfuscated using the Initial secret.
Paragraph (version B):
A Client Initial packet exposes the version, source and destination
connection IDs without encryption.  The payload of the Initial packet
is protected using the Initial secret.  The complete TLS Client
Hello, including any TLS Server Name Indication (SNI) present, is
sent in one or more CRYPTO frames across one or more QUIC Initial
packets.
Paragraph (version B):
The Server Initial datagram also exposes version number, source and
destination connection IDs in the clear; the payload of the Initial
packet(s) is protected using the Initial secret.
Paragraph (version A):
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):
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 protected 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.