Change:
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> <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. <del> The Initial Completion datagram contains at least one Handshake packet and some also include an Initial packet. </del> <ins> The Client Completion datagram contains at least one Handshake packet and some also include an Initial packet. </ins> <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> <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. <del> The content of QUIC Initial packets are encrypted using Initial </del> <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

Discussion:
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.