Change:
contains an invalid Retry token, it knows the client will not accept another Retry token.  The server can discard such a packet and allow the client to time out to detect handshake failure, but that could <del> impose a significant latency penalty on the client.  A server MAY proceed with the connection without verifying the token, though the server MUST NOT consider the client address validated.  If a server chooses not to proceed with the handshake, it SHOULD immediately close (immediate-close) the connection with an INVALID_TOKEN error. Note that a server has not established any state for the connection at this point and so does not enter the closing period. </del> <ins> impose a significant latency penalty on the client.  Instead, the server SHOULD immediately close (immediate-close) the connection with an INVALID_TOKEN error.  Note that a server has not established any state for the connection at this point and so does not enter the closing period. </ins> A flow showing the use of a Retry packet is shown in fig-retry.

Discussion:
Fixes issue
This is right. I think that we got a bit of skew over time and the text you cut no longer makes sense.
( was on the mailing list.) PR introduces the following text: The problem with the "server MAY proceed" part is that there is no reasonable way for the server to do so. If ODCID cannot be extracted from the invalid Retry token, then the server cannot set the , which it MUST do. The recommendation that the "server MAY proceed" should come out.
I am not sure if I agree. IIUC, the sentence suggests that a server can process the Initial packet and proceed the handshake as if that Initial packet did not have a token attached. That's at least possible technically (we do that occasionally for NEW_TOKEN tokens, right?). Whether if people would want to do that is a different question, but I think this behavior makes sense for deployments in which you'd have a retry middlebox occasionally installed (and uninstalled).
The problem here is that something that is identifiable as a Retry token as distinct from a NEWTOKEN token will ultimately not be usable. There's a bit of hedging necessary though as junk that appears to be a Retry token is still ultimately just junk. To be concrete, let's say that you generate Retry tokens that start with "RETRY!!!" and NEWTOKEN tokens start with "~~~NEW_TOKEN" The difference between those two is such that it would be unlikely for corruption to cause one to be mistaken for the other, and you have a way to distinguish the two even when all the subsequent bits can't be interpreted after you lose keys or something like that.
The only case in which the server can proceed is when the server sees a junk token, but knows that the client does not consider it a Retry token. There's no mechanism for the client to tell the server what it thinks the token it has presented is, so the server doesn't know when it's in this state. I agree -- axe it.
As pointed out by NAME and NAME the client would reject the handshake even if the server ignores the token and proceeds with the handshake. This is because TP.originalconnectionid would not contain the expected value. I now agree that this MAY is awkward and that we can strike the sentence.
The resolution to send INVALID_TOKEN error could be used to attack tokens through timing attacks.

It may be better to drop the packet or to require some attack mitigation measure. Hello, PR 3107 introduced the following text: 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 discard such a packet and allow the client to time out to detect handshake failure, but that could impose a significant latency penalty on the client. A server MAY proceed with the connection without verifying the token, though the server MUST NOT consider the client address validated. If a server chooses not to proceed with the handshake, it SHOULD immediately close (Section 10.3) the connection with an INVALIDTOKEN error. Note that a server has not established any state for the connection at this point and so does not enter the closing period. The problem with the "server MAY proceed" part is that the server's transport parameters MUST include originalconnection_id. If ODCID cannot be extracted from the invalid Retry token, then the server cannot let this connection proceed. Questions: The Retry token seems like the obvious place for the server to store ODCID. Is there an implementation that does something else (state on server)? Should we spell out this caveat in the draft? I.e. "server MAY proceed if it possesses ODCID." Thanks, Dmitri.