Original text:
examine each of the datagrams in detail. The QUIC handshake can normally be recognized on the wire through at <del> 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. </del>  Packets in the handshake belong to three separate cryptographic and transport contexts ("Initial", which contains observable payload, and 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 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 </del>  handshake, and initial 1-RTT data, if present. <del> The Initial Completion datagram contains at least one Handshake packet and some also include an Initial packet. </del>  <del> Datagrams that contain a QUIC Initial Packet (Client Hello, Server Hello, and some Initial Completion) contain at least 1200 octets of UDP payload.  This protects against amplification attacks and verifies that the network path meets the requirements for the minimum QUIC IP packet size; see Section 14 of QUIC-TRANSPORT.  This is accomplished by either adding PADDING frames within the Initial </del>  packet, coalescing other packets with the Initial packet, or leaving unused payload in the UDP packet after the Initial packet.  A network path needs to be able to forward at least this size of packet for QUIC to be used. <del> The content of QUIC Initial packets are encrypted using Initial </del>  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.  They are Initial, Handshake, and the Short Header packets transmitted after the handshake belong to cryptographic and transport contexts.  The <del> 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. </del>  <del> The Client Hello datagram exposes version number, source and </del>  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> The Server Hello 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> The Initial Completion datagram does not expose any additional </del>  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. <del> Similar to Initial Completion, Handshake Completion also exposes no </del>  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 <del> 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 that can be sent in the first round is limited by the initial congestion window, </del>  typically around 10 packets (see Section 7.2 of QUIC-RECOVERY). 2.5.

Reviewer comments:
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}}. I mean, you can call them that for reference purposes, but there's no such thing as a "QUIC Client Hello" (or ClientHello). Calling something "Initial Completion" when it might not contain any Initial packets might confuse people when they go looking for more details. Maybe "Client Initial," "Server Initial," "Client Finished," and "Server Finished"? It mixes layers, but those are at least things that occur in the referenced packets.
Or, to avoid using TLS message names consistently, s/Finished/Confirmation
Should I conclude from the absence of comment since February that we are all reasonably content with "Client Initial", "Server Initial", "Client Completion", and "Server Completion"? If so I'm happy to create the PR to save Brian a job. But I don't want to do that if these are not the best names.
This was assigned to Brian has he wanted to take a stab.
That's fine I'll leave it to Brian.

Revised text:
examine each of the datagrams in detail. The QUIC handshake can normally be recognized on the wire through at  <ins> least four datagrams we'll call "Client Initial", "Server Initial", and "Client Completion", and "Server Completion", for purposes of this illustration, as shown in fig-handshake. </ins> Packets in the handshake belong to three separate cryptographic and transport contexts ("Initial", which contains observable payload, and its Client Hello, and the server can send 1-RTT data as soon as it has sent its Server Hello.  <ins> 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 Server Initial, a Handshake packet with the rest of the server's side of the TLS </ins> handshake, and initial 1-RTT data, if present.  <ins> The Client Completion datagram contains at least one Handshake packet and some also include an Initial packet. </ins>  <ins> Datagrams that contain a Client Initial Packet (Client Initial, Server Initial, and some Client Completion) contain at least 1200 octets of UDP payload.  This protects against amplification attacks and verifies that the network path meets the requirements for the minimum QUIC IP packet size; see Section 14 of QUIC-TRANSPORT.  This is accomplished by either adding PADDING frames within the Initial </ins> packet, coalescing other packets with the Initial packet, or leaving unused payload in the UDP packet after the Initial packet.  A network path needs to be able to forward at least this size of packet for QUIC to be used.  <ins> The content of Client Initial packets are encrypted using Initial </ins> 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.  They are Initial, Handshake, and the Short Header packets transmitted after the handshake belong to cryptographic and transport contexts.  The  <ins> 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. </ins>  <ins> The Client Initial datagram exposes version number, source and </ins> 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.  <ins> The Server Initial datagram also exposes version number, source and </ins> destination connection IDs in the clear; information in the TLS Server Hello message is obfuscated using the Initial secret.  <ins> The Client Completion datagram does not expose any additional </ins> 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.  <ins> Similar to Client Completion, Server Completion also exposes no </ins> 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  <ins> be seen in the Client Initial datagram, 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 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 Initial datagram, containing the rest of the 0-RTT data.  The amount of 0-RTT protected data that can be sent in the first round is limited by the initial congestion window, </ins> typically around 10 packets (see Section 7.2 of QUIC-RECOVERY). 2.5.