Move the retained sentence higher instead

draft-ietf-quic-transport.md

@@ -2470,21 +2470,21 @@ 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.
+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
 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}}.  After the handshake is confirmed, an endpoint MUST send
-any CONNECTION_CLOSE frames in a 1-RTT packet.
+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}