Change:
present. The long header exposes more information.  It is used during <del> connection establishment, including version negotiation, server retry, and 0-RTT data.  It contains a version number, as well as source and destination connection IDs for grouping packets belonging to the same flow.  The definition and location of these fields in the QUIC long header are invariant for future versions of QUIC, although future versions of QUIC may provide additional fields in the long header QUIC-INVARIANTS. Short headers are used after connection establishment.  The only information they contain for inspection on the path is an optional, variable-length destination connection ID. As of draft version 13 of the QUIC transport document, the following information may be exposed in QUIC packet headers: header type: the long header has a 7-bit packet type field </del> <ins> connection establishment, including version negotiation, retry, and 0-RTT data.  It contains a version number, as well as source and destination connection IDs for grouping packets belonging to the same flow.  The definition and location of these fields in the QUIC long header are invariant for future versions of QUIC, although future versions of QUIC may provide additional fields in the long header QUIC-INVARIANTS. Short headers are used after connection establishment, and contain only an optional destination connection ID and the spin bit for RTT measurement. The following information is exposed in QUIC packet headers: demux bit: the second most significant bit of the first octet every QUIC packet of the current version is set to 1, for demultiplexing with other UDP-encapsulated protocols. header type: the long header has a 2 bit packet type field </ins> following the Header Form bit.  Header types correspond to stages <del> of the handshake; see Section 4.1 of QUIC-TRANSPORT. </del> <ins> of the handshake; see Section 17.2 of QUIC-TRANSPORT. </ins> <del> version number: The version number is present in the long header, and identifies the version used for that packet.  Note that during Version Negotiation (see version, and Section 4.3 of QUIC- </del> <ins> version number: the version number present in the long header, and identifies the version used for that packet.  Note that during Version Negotiation (see version, and Section 17.2.1 of QUIC- </ins> TRANSPORT, the version number field has a special value (0x00000000) that identifies the packet as a Version Negotiation packet. <del> source and destination connection ID: The source and destination connection IDs are variable-length fields 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.  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.  The destination connection ID, if present, is present on both long and short header packets.  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 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. </ins> length: the length of the remaining quic packet after the length field, present on long headers.  This field is used to implement coalesced packets during the handshake (see coalesced). <del> packet number: Every packet has an associated packet number; </del> <ins> spin bit: the spin bit supports passive measurement of RTT, and is present on QUIC short packet headers.  See sec-rtt. token: Initial packets may contain a token, a variable-length opaque value optionally sent from client to server, used for validating the client's address.  Retry packets also contain a token, which can be used by the client in an Initial packet on a subsequent connection attempt.  The length of the token is explicit in both cases. Retry and Version Negotiation packets are not encrypted or obfuscated in any way.  For other kinds of packets, other information in the packet headers is cryptographically obfuscated: packet number: Most packets (with the exception of Version Negotiation and Retry packets) have an associated packet number; </ins> however, this packet number is encrypted, and therefore not of use <del> to on-path observers.  This packet number has a fixed location and length in long headers, and an implicit location and encrypted variable length in short headers. </del> <ins> to on-path observers.  The offset of the packet number is encoded in the header for packets with long headers, while it is implicit (depending on Destination Connection ID length) in short header packets.  The length of the packet number is cryptographically obfuscated. </ins> <del> key phase: The Key Phase bit, present in short headers identifies the key used to encrypt the packet during key rotation. </del> <ins> key phase: The Key Phase bit, present in short headers, specifies the keys used to encrypt the packet, supporting key rotation.  The Key Phase bit is cryptographically obfuscated. </ins> 2.2.

Discussion:
Review the text of the -manageability draft to ensure that changes to headers in the latest version of -transport are correctly tracked.
on review CIDs are mostly okay but there are other header changes to track.