Jana's suggestion

draft-ietf-quic-transport.md

@@ -1643,12 +1643,18 @@ more resources available for new connections.
 
 If a server receives a client Initial that can be unprotected but contains an
 invalid Retry token, it knows the client will not accept another Retry token.
-It can proceed with the handshake without verifying the token, drop the Initial
-packet, or immediately close ({{immediate-close}}) the connection with an
-INVALID_TOKEN error to cause the handshake to fail quickly instead of waiting
-for the client to timeout. The server MAY close the connection without creating
-connection state, including not adding the connection to those in the closing
-state.
+
+
+
+If a server receives a client Initial that can be unprotected but contains an
+invalid Retry token, it knows the client will not accept another Retry token.
+
+The server can drop such a packet and allow the client to time out to detect
+handshake failure, but that is a significant latency penalty to the client.
+If possible, the server SHOULD either immediately close ({{immediate-close}}) 
+the connection with an INVALID_TOKEN error or proceed with the handshake
+without verifying the token. The server MAY close the connection without
+creating connection state, including skipping the closing state.
 
 A flow showing the use of a Retry packet is shown in {{fig-retry}}.