Original text:
2.3. <del> As soon as the cryptographic context is established, all information in the QUIC header, including those exposed in the packet header, is integrity protected.  Further, information that were sent and exposed in previous packets when the cryptographic context was established yet, e.g. for the cryptographic initial handshake itself, will be validated later during the cryptographic handshake.  Therefore, devices on path MUST NOT change any information or bits in QUIC packet headers, since alteration of header information will lead to a failed integrity check at the receiver, and can even lead to connection termination. </del>  2.4.  The connection ID in the QUIC packet headers allows routing of QUIC packets at load balancers on other than five-tuple information, ensuring that related flows are appropriately balanced together; and the new connection ID being negotiated via encrypted frames.  See Section 6.1 of QUIC-TRANSPORT. <del> 2.5. </del>  The packet number field is always present in the QUIC packet header; however, it is always encrypted.  The encryption key for packet end-to-end cryptographic context.  Packet numbers are therefore not part of the wire image that is useful to on-path observers. <del> 2.6. </del>  Version negotiation is not protected, given the used protection mechanism can change with the version.  However, the choices provided 3.2. Connection establishment uses Initial, Handshake, and Retry packets <del> containing a TLS handshake on Stream 0.  Connection establishment can therefore be detected using heuristics similar to those used to detect TLS over TCP.  A client using 0-RTT connection may also send data packets in 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 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. Round-trip time of QUIC flows can be inferred by observation once per flow, during the handshake, as in passive TCP measurement; this <del> requires parsing of the QUIC packet header and the cleartext TLS handshake on stream 0. </del>  In the common case, the delay between the Initial packet containing the TLS Client Hello and the Handshake packet containing the TLS

Reviewer comments:
The manageability document should illustrate all the various packet sequences in a handshake, preferably with pretty pictures.
Now the transport draft has these illustrations as well. However, I think we should still at them in manageability as well. Actually I would like to try the SVG format here. Anybody in for that?
The handshake illustrations here should only concern themselves with the wire image, unlike those in the transport draft, but yes we should derive them from the transport draft. Happy to do these in ASCII as well as SVG.
The problem with examples is that they might be typical, but they rarely capture the breadth of options well. Maybe you should purposefully diverge from established practice in these to avoid certain illusions from being formed. For instance, put PADDING first.

Revised text:
2.3.  <ins> New QUIC connections are established using a handshake, which is distinguishable on the wire and contains some information that can be passively observed. To illustrate the information visible in the QUIC wire image during the handshake, we first show the general communication pattern visible in the UDP datagams containing the QUIC handshake, then examine each of the datagrams in detail. In the nominal case, the QUIC handshake can be recognized on the wire through at least four datagrams we'll call "QUIC Client Hello", "QUIC Server Hello", and "Initial Completion", and "Handshake Completion", for purposes of this illustration, as shown in fig-handshake. Packets in the handshake belong to three separate cryptographic and transport contexts ("Initial", which contains observable payload, and "Handshake" and "1-RTT", which do not).  QUIC packets in separate contexts during the handshake are generally coalesced (see coalesced) in order to reduce the number of UDP datagrams sent during the handshake. As shown here, the client can send 0-RTT data as soon as it has sent its Client Hello, and the server can send 1-RTT data as soon as it has sent its Server Hello. A typical handshake starts with the client sending of a QUIC Client Hello datagram as shown in fig-client-hello, which elicits a QUIC Server Hello datagram as shown in fig-server-hello typically containing three packets: an Initial packet with the Server Hello, a Handshake packet with the rest of the server's side of the TLS handshake, and initial 1-RTT data, if present. The content of QUIC Initial packets are 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; we therefore consider these as visible in our illustration.  The content of QUIC Handshake packets are encrypted using keys established during the initial handshake exchange, and are therefore not visible. Initial, Handshake, and the Short Header packets transmitted after the handshake belong to cryptographic and transport contexts.  The Initial Completion fig-init-complete and the Handshake Completion fig-hs-complete datagrams finish these first two contexts, by sending the final acknowledgment and finishing the transmission of CRYPTO frames. The Client Hello datagram exposes version number, source and destination connection IDs, and information in the TLS Client Hello message, including any TLS Server Name Indication (SNI) present, in the clear.  The QUIC PADDING frame is present to ensure the Client Hello datagram has a minumum size of 1200 octets, to mitigate the possibility of handshake amplification. The Server Hello datagram exposes version number, source and destination connection IDs, and information in the TLS Server Hello message. The Initial Completion datagram does not expose any additional information; however, recognizing it can be used to determine that a handshake has completed (see sec-confirm), and for three-way handshake RTT estimation as in sec-rtt. Similar to Initial Competion, Handshake Completion also exposes no additional information; observing it serves only to determine that the handshake has completed. When the client uses 0-RTT connection resumption, 0-RTT data may also be seen in the QUIC Client Hello datagram, as shown in fig-client- hello-0rtt. In a 0-RTT QUIC Client Hello datagram, the PADDING frame is only present if necessary to increase the size of the datagram with 0RTT data to at least 1200 bytes.  Additional datagrams containing only 0-RTT protected long header packets may be sent from the client to the server after the Client Hello datagram, containing the rest of the 0-RTT data.  The amount of 0-RTT protected data is limited by the initial congestion window, typically around 10 packets RFC6928. </ins> 2.4. <ins> As soon as the cryptographic context is established, all information in the QUIC header, including information exposed in the packet header, is integrity protected.  Further, information that was sent and exposed in handshake packets sent before the cryptographic context was established are validated later during the cryptographic handshake.  Therefore, devices on path MUST NOT change any information or bits in QUIC packet headers, since alteration of header information will lead to a failed integrity check at the receiver, and can even lead to connection termination. 2.5. </ins> The connection ID in the QUIC packet headers allows routing of QUIC packets at load balancers on other than five-tuple information, ensuring that related flows are appropriately balanced together; and the new connection ID being negotiated via encrypted frames.  See Section 6.1 of QUIC-TRANSPORT.  <ins> 2.6. </ins> The packet number field is always present in the QUIC packet header; however, it is always encrypted.  The encryption key for packet end-to-end cryptographic context.  Packet numbers are therefore not part of the wire image that is useful to on-path observers.  <ins> 2.7. </ins> Version negotiation is not protected, given the used protection mechanism can change with the version.  However, the choices provided 3.2. Connection establishment uses Initial, Handshake, and Retry packets  <ins> containing a TLS handshake.  Connection establishment can therefore be detected using heuristics similar to those used to detect TLS over TCP.  A client using 0-RTT connection may also send data packets in 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 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. </ins> 3.3. Round-trip time of QUIC flows can be inferred by observation once per flow, during the handshake, as in passive TCP measurement; this  <ins> requires parsing of the QUIC packet header and recognition of the handshake, as illustrated in handshake. </ins> In the common case, the delay between the Initial packet containing the TLS Client Hello and the Handshake packet containing the TLS