diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md
index 71767ec27f..2eedd70962 100644
--- a/draft-ietf-quic-recovery.md
+++ b/draft-ietf-quic-recovery.md
@@ -663,9 +663,13 @@ in Initial packets, or the client's estimated RTT is too small. When a
 client receives Handshake or 1-RTT packets prior to obtaining Handshake keys,
 it may assume some or all of the server's Initial packets were lost.
 
-To speed up handshake completion under these conditions, an endpoint MAY send
-a packet containing unacknowledged CRYPTO data earlier than the PTO expiry,
-subject to the address validation limits in Section 8.1 of {{QUIC-TRANSPORT}}.
+To speed up handshake completion under these conditions, an endpoint MAY, for a
+limited number of occasions per each connection, send a packet containing
+unacknowledged CRYPTO data earlier than the PTO expiry, subject to the address
+validation limits in Section 8.1 of {{QUIC-TRANSPORT}}. Doing so at most once
+for each connection is adequate to quickly recover from a single packet loss.
+Endpoints that do not cease retransmitting packets in response to
+unauthenticated data risk creating an infinite exchange of packets.
 
 Endpoints can also use coalesced packets (see Section 12.2 of
 {{QUIC-TRANSPORT}}) to ensure that each datagram elicits at least one
diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md
index 4d5a5bf244..3fd345267b 100644
--- a/draft-ietf-quic-transport.md
+++ b/draft-ietf-quic-transport.md
@@ -4084,20 +4084,24 @@ fragmentation on the path.
 A client MUST expand the payload of all UDP datagrams carrying Initial packets
 to at least the smallest allowed maximum packet size (1200 bytes) by adding
 PADDING frames to the Initial packet or by coalescing the Initial packet; see
-{{packet-coalesce}}.  Sending a UDP datagram of this size ensures that the
-network path from the client to the server supports a reasonable Path Maximum
-Transmission Unit (PMTU).  This also helps reduce the amplitude of amplification
-attacks caused by server responses toward an unverified client address; see
-{{address-validation}}.
-
-Datagrams containing Initial packets MAY exceed 1200 bytes if the client
+{{packet-coalesce}}.  Similarly, a server MUST expand the payload of all UDP
+datagrams carrying ack-eliciting Initial packets to at least the smallest
+allowed maximum packet size (1200 bytes).  Sending UDP datagrams of this size
+ensures that the network path supports a reasonable Path Maximum Transmission
+Unit (PMTU), in both directions.  Additionally, a client that expands Initial
+packets helps reduce the amplitude of amplification attacks caused by server
+responses toward an unverified client address; see {{address-validation}}.
+
+Datagrams containing Initial packets MAY exceed 1200 bytes if the sender
 believes that the network path and peer both support the size that it chooses.
 
 A server MUST discard an Initial packet that is carried in a UDP datagram with a
 payload that is less than the smallest allowed maximum packet size of 1200
 bytes.  A server MAY also immediately close the connection by sending a
 CONNECTION_CLOSE frame with an error code of PROTOCOL_VIOLATION; see
-{{immediate-close-hs}}.
+{{immediate-close-hs}}.  When a client receives an ack-eliciting Initial packet
+that is carried in a UDP datagram with a payload that is less than 1200 bytes,
+that client MAY close the connection by sending a CONNECTION_CLOSE frame.
 
 The server MUST also limit the number of bytes it sends before validating the
 address of the client; see {{address-validation}}.