Original text:
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>  following the Header Form bit.  Header types correspond to stages <del> of the handshake; see Section 4.1 of QUIC-TRANSPORT. </del>  <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>  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>  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>  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>  <del> key phase: The Key Phase bit, present in short headers identifies the key used to encrypt the packet during key rotation. </del>  2.2. connection ID for the lifetime of the connection.  Connection IDs for either endpoint may change during the lifetime of a connection, with the new connection ID being negotiated via encrypted frames.  See <del> Section 6.1 of QUIC-TRANSPORT. </del>  2.7. flow is using QUIC based upon a UDP port number may therefore not hold; see also RFC7605 section 5.  3.1.1. An in-network observer assuming that a set of packets belongs to a 0-RTT Protected packets directly after the Initial packet containing the TLS Client Hello.  Since these packets may be reordered in the network, note that 0-RTT Protected data packets may be seen before <del> the Initial packet.  Note that only clients send Initial packets, so the sides of a connection can be distinguished by QUIC packet type in the handshake. </del>  3.3. when when observing a packet sharing a connection ID and one endpoint address (IP address and port) with the known flow. <del> The connection ID to be used for a long-running flow is chosen by the server (see QUIC-TRANSPORT section 5.6) during the handshake.  This value should be treated as opaque; see sec-loadbalancing for caveats regarding connection ID selection at servers. </del>  3.5. Round-trip time of QUIC flows can be inferred by observation once per flow, during the handshake, as in passive TCP measurement; this requires parsing of the QUIC packet header and recognition of the <del> handshake, as illustrated in handshake. </del>  In the common case, the delay between the Initial packet containing the TLS Client Hello and the Handshake packet containing the TLS necessarily includes any transport and application layer delay at both sides. <del> The spin bit experiment, detailed in QUIC-SPIN, provides an additional method to measure intraflow per-flow RTT.  When a QUIC flow is sending at full rate (i.e., neither application nor flow control limited), the latency spin bit described in that document changes value once per round-trip time (RTT).  An on-path observer can observe the time difference between edges in the spin bit signal in a single direction to measure one sample of end-to-end RTT.  Note that this measurement, as with passive RTT measurement for TCP, includes any transport protocol delay (e.g., delayed sending of acknowledgements) and/or application layer delay (e.g., waiting for a request to complete).  It therefore provides devices on path a good instantaneous estimate of the RTT as experienced by the application. A simple linear smoothing or moving minimum filter can be applied to the stream of RTT information to get a more stable estimate. </del>  An on-path observer that can see traffic in both directions (from client to server and from server to client) can also use the spin bit

Reviewer comments:
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.

Revised text:
present. The long header exposes more information.  It is used during  <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  <ins> of the handshake; see Section 17.2 of QUIC-TRANSPORT. </ins>  <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.  <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).  <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  <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>  <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. connection ID for the lifetime of the connection.  Connection IDs for either endpoint may change during the lifetime of a connection, with the new connection ID being negotiated via encrypted frames.  See  <ins> Section 5.1 of QUIC-TRANSPORT. </ins> 2.7. flow is using QUIC based upon a UDP port number may therefore not hold; see also RFC7605 section 5. <ins> While the second most significant bit (0x40) of the first octet is always set to 1 in QUIC packets of the current version, this is not a recommended method of recognizing QUIC traffic, as it only provides one bit of information and is quite prone to collide with UDP-based protocols other than those that this static bit is meant to allow multiplexing with. </ins> 3.1.1. An in-network observer assuming that a set of packets belongs to a 0-RTT Protected packets directly after the Initial packet containing the TLS Client Hello.  Since these packets may be reordered in the network, note that 0-RTT Protected data packets may be seen before  <ins> the Initial packet. Note that clients send Initial packets before servers do, servers send Handshake packets before clients do, and only clients send Initial packets with tokens, so the sides of a connection can be generally be confirmed by an on-path observer.  An attempted connection after Retry can be detected by correlating the token on the Retry with the token on the subsequent Initial packet. </ins> 3.3. when when observing a packet sharing a connection ID and one endpoint address (IP address and port) with the known flow.  <ins> However, since the connection ID may change multiple times during the lifetime of a flow, and the negotiation of connection ID changes is encrypted, packets with the same 5-tuple but different connection IDs may or may not belong to the same connection. The connection ID value should be treated as opaque; see sec- loadbalancing for caveats regarding connection ID selection at servers. </ins> 3.5. Round-trip time of QUIC flows can be inferred by observation once per flow, during the handshake, as in passive TCP measurement; this requires parsing of the QUIC packet header and recognition of the  <ins> handshake, as illustrated in handshake.  It can also be inferred during the flow's lifetime, if the endpoints use the spin bit facility described below and in QUIC-SPIN. </ins> In the common case, the delay between the Initial packet containing the TLS Client Hello and the Handshake packet containing the TLS necessarily includes any transport and application layer delay at both sides.  <ins> The spin bit provides an additional method to measure intraflow per- flow RTT.  When a QUIC flow is sending at full rate (i.e., neither application nor flow control limited), the latency spin bit on short header packets changes value once per round-trip time (RTT).  An on- path observer can observe the time difference between edges in the spin bit signal in a single direction to measure one sample of end- to-end RTT.  Note that this measurement, as with passive RTT measurement for TCP, includes any transport protocol delay (e.g., delayed sending of acknowledgements) and/or application layer delay (e.g., waiting for a request to complete).  It therefore provides devices on path a good instantaneous estimate of the RTT as experienced by the application.  A simple linear smoothing or moving minimum filter can be applied to the stream of RTT information to get a more stable estimate. </ins> An on-path observer that can see traffic in both directions (from client to server and from server to client) can also use the spin bit