Original text:
A stateless reset is provided as an option of last resort for an endpoint that does not have access to the state of a connection.  A crash or outage might result in peers continuing to send data to an <del> endpoint that is unable to properly continue the connection.  A stateless reset is not appropriate for signaling error conditions. </del>  An endpoint that wishes to communicate a fatal connection error MUST use a CONNECTION_CLOSE frame if it has sufficient state to do so. packet either cannot be associated with a connection, cannot be decrypted, or is marked as a duplicate packet.  The endpoint MUST then compare the last 16 bytes of the packet with all Stateless Reset <del> Tokens that are associated with connection IDs that are currently in use.  This includes Stateless Reset Tokens from NEW_CONNECTION_ID frames and the server's transport parameters.  An endpoint MUST NOT check for any Stateless Reset Tokens associated with connection IDs it has not used or for connection IDs that have been retired. </del>  If the last 16 bytes of the packet values are identical to a Stateless Reset Token, the endpoint MUST enter the draining period A stateless reset token is used in verifying a stateless reset, see stateless-reset.  This parameter is a sequence of 16 bytes. <del> This transport parameter is only sent by a server. </del>  The maximum packet size parameter is an integer value that limits the size of packets that the endpoint is willing to receive.  This

Reviewer comments:
I know that we made this a design issue, and these do change 2119 language, but those normative requirements were implied anyway. That is, the text used cannot vs. MUST NOT.
I was also wondering about the rate limit in SR - I too thought it was there. But now, after thinking a bit, the rate limit was probably removed because it is a DoS vector. It can force state to maintained where it is not wanted.
This is a weird statement to make. It is absolutely the place of the spec to do that! If what you mean is that this is entirely optional, then I'm happy to make it a MAY. My concern is not so much what level of force the spec uses, just that the level of force is clear.
Before I merge this, NAME NAME might want to check that I'm not making technical changes. (There is new 2119 language, but my view is that this is converting from implied to express, but I want to give a chance to run a consensus call if you think that's appropriate.)
Those sorts of conversions have surprised people before, and is design anyway, so let's do run that consensus call. If it's ready to go, add and we'll run it up the virtual flagpole.
NAME take a look at what I just proposed.
While there are some prohibitions, and an explicit MAY for responding to Long Headers, there is no normative statement for the usual use case for Stateless Reset. I believe it's a SHOULD, but maybe someone thinks it's a MUST. Relatedly, in 10.4.1, MUST we attempt to detect Stateless Reset, or MAY endpoints just drop after decrypt failure? At the end of 10.4.2, MUST we not reuse connection IDs if there's a static key? (I think the answer is yes)
Thanks, NAME this LGTM.Thank you, this addresses the original issue. One nit below.

Revised text:
A stateless reset is provided as an option of last resort for an endpoint that does not have access to the state of a connection.  A crash or outage might result in peers continuing to send data to an  <ins> endpoint that is unable to properly continue the connection.  An endpoint MAY send a stateless reset in response to receiving a packet that it cannot associate with an active connection. A stateless reset is not appropriate for signaling error conditions. </ins> An endpoint that wishes to communicate a fatal connection error MUST use a CONNECTION_CLOSE frame if it has sufficient state to do so. packet either cannot be associated with a connection, cannot be decrypted, or is marked as a duplicate packet.  The endpoint MUST then compare the last 16 bytes of the packet with all Stateless Reset  <ins> Tokens that are associated with connection IDs that the endpoint recently used to send packets from the IP address and port on which the datagram is received.  This includes Stateless Reset Tokens from NEW_CONNECTION_ID frames and the server's transport parameters.  An endpoint MUST NOT check for any Stateless Reset Tokens associated with connection IDs it has not used or for connection IDs that have been retired. </ins> If the last 16 bytes of the packet values are identical to a Stateless Reset Token, the endpoint MUST enter the draining period A stateless reset token is used in verifying a stateless reset, see stateless-reset.  This parameter is a sequence of 16 bytes.  <ins> This transport parameter MUST NOT be sent by a client, but MAY be sent by a server.  A server that does not send this transport parameter cannot use stateless reset (stateless-reset) for the connection ID negotiated during the handshake. </ins> The maximum packet size parameter is an integer value that limits the size of packets that the endpoint is willing to receive.  This