diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md
index 8c3b8b7243..0e71d7d690 100644
--- a/draft-ietf-quic-transport.md
+++ b/draft-ietf-quic-transport.md
@@ -2470,16 +2470,12 @@ signal closure.
 
 When sending CONNECTION_CLOSE, the goal is to ensure that the peer will process
 the frame.  Generally, this means sending the frame in a packet with the highest
-level of packet protection to avoid the packet being discarded.  However, during
-the handshake, it is possible that more advanced packet protection keys are not
-available to the peer, so the frame MAY be replicated in a packet that uses a
-lower packet protection level.
-
-After the handshake is confirmed, an endpoint MUST send any CONNECTION_CLOSE
-frames in a 1-RTT packet.  Prior to handshake confirmation, the peer might not
-have 1-RTT keys, so the endpoint SHOULD send CONNECTION_CLOSE frames in a
-Handshake packet.  If the endpoint does not have Handshake keys, it SHOULD send
-CONNECTION_CLOSE frames in an Initial packet.
+level of packet protection to avoid the packet being discarded.  After the
+handshake is confirmed (see Section 4.1.2 of {{QUIC-TLS}}), an endpoint MUST
+send any CONNECTION_CLOSE frames in a 1-RTT packet.  However, prior to
+confirming the handshake, it is possible that more advanced packet protection
+keys are not available to the peer, so the frame MAY be replicated in a packet
+that uses a lower packet protection level.
 
 A client will always know whether the server has Handshake keys (see
 {{discard-initial}}), but it is possible that a server does not know whether the
@@ -2487,9 +2483,8 @@ client has Handshake keys.  Under these circumstances, a server SHOULD send a
 CONNECTION_CLOSE frame in both Handshake and Initial packets to ensure that at
 least one of them is processable by the client.  Similarly, a peer might be
 unable to read 1-RTT packets, so an endpoint SHOULD send CONNECTION_CLOSE in
-Handshake and 1-RTT packets prior to confirming the handshake; see Section 4.1.2
-of {{QUIC-TLS}}.  These packets can be coalesced into a single UDP datagram; see
-{{packet-coalesce}}.
+Handshake and 1-RTT packets prior to confirming the handshake.  These packets
+can be coalesced into a single UDP datagram; see {{packet-coalesce}}.
 
 
 ## Stateless Reset {#stateless-reset}