Change:
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...

Discussion:
Negotiation Packet, are both inspectable and invariant QUIC- INVARIANTS. <del> This document describes version 1 of the QUIC protocol, whose wire </del> <ins> This document addresses version 1 of the QUIC protocol, whose wire </ins> 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

All deployed versions are maintained in an IANA registry (see Section 22.2 of QUIC-TRANSPORT). <del> 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. </del> <ins> 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. </ins> In version 1 of QUIC, the following additional information is exposed:

observers cannot reliably use it as an identifier for QUIC. latency spin bit: The third-most-significant bit of the first <del> 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 </del> <ins> 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 </ins> details. header type: The long header has a 2 bit packet type field

Retry (Section 17.2.5 of QUIC-TRANSPORT) and Version Negotiation (Section 17.2.1 of QUIC-TRANSPORT) packets are not encrypted or <del> obfuscated in any way.  For other kinds of packets, version 1 of QUIC </del> <ins> protected in any way.  For other kinds of packets, version 1 of QUIC </ins> cryptographically obfuscates other information in the packet headers: packet number: All packets except Version Negotiation and Retry

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 <del> cryptographically obfuscated. </del> <ins> cryptographically protected. </ins> key phase: The Key Phase bit, present in short headers, specifies the keys used to encrypt the packet to support key rotation.  The <del> Key Phase bit is cryptographically obfuscated. </del> <ins> Key Phase bit is cryptographically protected. </ins> 2.2.

A Client Initial packet exposes the version, source and destination connection IDs without encryption.  The payload of the Initial packet <del> is obfuscated using the Initial secret.  The complete TLS Client </del> <ins> is protected using the Initial secret.  The complete TLS Client </ins> Hello, including any TLS Server Name Indication (SNI) present, is sent in one or more CRYPTO frames across one or more QUIC Initial packets. The Server Initial datagram also exposes version number, source and destination connection IDs in the clear; the payload of the Initial <del> packet(s) is obfuscated using the Initial secret. </del> <ins> packet(s) is protected using the Initial secret. </ins> The Client Completion flight does not expose any additional information; however, as the destination connection ID is server-

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 <del> in Section 17.2 of QUIC-TRANSPORT, but is obfuscated as described in </del> <ins> in Section 17.2 of QUIC-TRANSPORT, but is protected 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