Change:
As noted in the "The QUIC Handshake" is written in a way that could cause readers to assume things such as there's only one datagram containing a Client Initial. This PR changes the naming from 'Client/Server Initial/Finished datagram' to 'Client/Server Initial/Finished flight' and makes related changes to make it read correctly. The diagrams have not been fully updated yet.
QUIC handshakes may or may not coalesce packets, which is stated, but I'm worried it could be missed by a reader. I think it'd be good to clarify that any portion of the server or client flight could span multiple datagrams. In particular, I'm worried this paragraph could mislead people, because unless the connection is resumed, the Handshake CRYPTO data typically spans multiple datagrams. Similarly, the client or server's Initial can span multiple datagrams, though that's not currently common:
I think some clarity about multiple packets/datagrams would be helpful in the Extracting SNI section as well: URL Specifically: 1) Client initial data can span multiple datagrams, and the SNI could be in any of them. 2) A single client Initial packet can contain multiple CRYPTO frames, and there's no strict requirement they're in order of offset.
NAME can you maybe propose a PR? :-)
Yes, possibly later today after I finish reviewing the draft.
NAME are you still planning to do a PR here?
I will unless someone beats me to it, but I've been on paternity leave for 10 days. NAME had some suggested text for the SNI section, but I can try to fix "The QUIC Handshake" and assume David's text is a good start for SNI.
While writing the PR, I discovered a problem I'm not sure how to fix, which is how does an observer know when the handshake is complete for the server, given the server can start using 1-RTT keys immediately after receiving the client hello? Receipt of the client's 1-RTT packet doesn't guarantee anything, because the server can't process it if it doesn't have keys.
lgtm, one potential diagram nit.

Discussion:
visible in the UDP datagrams containing the QUIC handshake, then examine each of the datagrams in detail. <del> The QUIC handshake can normally be recognized on the wire through at least four datagrams labelled "Client Initial", "Server Initial", and "Client Completion", and "Server Completion", in the illustration shown in fig-handshake. </del> <ins> The QUIC handshake can normally be recognized on the wire through four flights of datagrams labelled "Client Initial", "Server Initial", "Client Completion", and "Server Completion", in the illustration shown in fig-handshake. </ins> 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 <del> contexts during the handshake are generally coalesced (see coalesced) in order to reduce the number of UDP datagrams sent during the handshake. </del> <ins> contexts during the handshake can be coalesced (see coalesced) in order to reduce the number of UDP datagrams sent during the handshake.  QUIC packets can be lost and reordered, so packets within a flight might not be sent close in time, though the sequence of the flights will not change, because one flight depends upon the peer's previous flight. </ins> 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. <del> A typical handshake starts with the client sending of a Client Initial datagram as shown in fig-client-initial, which elicits a Server Initial datagram as shown in fig-server-initial typically containing three packets: an Initial packet with the beginning of the server's side of the TLS handshake, a Handshake packet with the rest of the server's side of the TLS handshake, and 1-RTT data, if present. </del> <ins> A handshake starts with the client sending one or more datagrams containing Initial packets as shown in fig-client-initial, which elicits the Server Initial response as shown in fig-server-initial typically containing three types of packets: Initial packet(s) with the beginning of the server's side of the TLS handshake, Handshake packet(s) with the rest of the server's portion of the TLS handshake, and 1-RTT packet(s), if present. </ins> <del> The Client Completion datagram contains at least one Handshake packet </del> <ins> The Client Completion flight contains at least one Handshake packet </ins> and could also include an Initial packet. Datagrams that contain an Initial packet (Client Initial, Server

The content of Initial packets is 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- <del> path device that knows the per-version constant.  They are therefore considered visible in this 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 1-RTT packets transmitted after the handshake belong to cryptographic and transport contexts.  The Client Completion fig-init-complete and the Server Completion fig-hs- complete datagrams finish these first two contexts, by sending the final acknowledgment and finishing the transmission of CRYPTO frames. The Client Initial datagram exposes version number, source and destination connection IDs without encryption.  Information in the TLS Client Hello frame, including any TLS Server Name Indication (SNI) present, is obfuscated using the Initial secret.  Note that the location of PADDING is implementation-dependent, and PADDING frames might not appear in a coalesced Initial packet. </del> <ins> path device that knows the per-version constant and considered visible in this 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 1-RTT packets belong to different cryptographic and transport contexts.  The Client Completion fig- init-complete and the Server Completion fig-hs-complete flights conclude the Initial and Handshake contexts, by sending final acknowledgments and CRYPTO frames. 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. </ins> The Server Initial datagram also exposes version number, source and <del> destination connection IDs in the clear; information in the TLS Server Hello message is obfuscated using the Initial secret. </del> <ins> destination connection IDs in the clear; the payload of the Initial packet(s) is obfuscated using the Initial secret. </ins> <del> The Client Completion datagram does not expose any additional </del> <ins> The Client Completion flight does not expose any additional </ins> information; however, as the destination connection ID is server- <del> selected, it usually is not the same ID than in the Client Initial datagram.  Client Completion datagram can be used to determine that a handshake has completed (see sec-confirm), and for three-way handshake RTT estimation as in sec-rtt. </del> <ins> selected, it usually is not the same ID than in the Client Initial. Client Completion flights contain 1-RTT packets which indicate the handshake has completed (see sec-confirm) on the client, and for three-way handshake RTT estimation as in sec-rtt. </ins> Similar to Client Completion, Server 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, the Client Initial <del> datagram can also carry 0-RTT data, as shown in fig-client-initial- 0rtt. In a 0-RTT Client Initial datagram, the PADDING frame is only present if necessary to increase the size of the datagram with 0-RTT data to at least 1200 bytes.  Additional datagrams containing only 0-RTT packets with long headers could be sent from the client to the server after the Client Initial datagram, containing the rest of the 0-RTT data.  The amount of 0-RTT protected data that can be sent in the first flight is limited by the initial congestion window, typically to around 10 packets (see Section 7.2 of QUIC-RECOVERY). </del> <ins> flight can also include one or more 0-RTT packets, as shown in fig- client-initial-0rtt. When a 0-RTT packet is coalesced with an Initial packet, the datagram will be padded to 1200 byes.  Additional datagrams containing only 0-RTT packets with long headers can be sent after the client Initial packet(s), containing more 0-RTT data.  The amount of 0-RTT protected data that can be sent in the first flight is limited by the initial congestion window, typically to around 10 packets (see Section 7.2 of QUIC-RECOVERY). </ins> 2.5.