Original text:
connections.  An endpoint that wishes to communicate a fatal connection error MUST use a CONNECTION_CLOSE frame if it is able. <del> To support this process, a token is sent by endpoints.  The token is carried in the Stateless Reset Token field of a NEW_CONNECTION_ID frame.  Servers can also specify a stateless_reset_token transport parameter during the handshake that applies to the connection ID that it selected during the handshake; clients cannot use this transport parameter because their transport parameters do not have confidentiality protection.  These tokens are protected by encryption, so only client and server know their value.  Tokens are invalidated when their associated connection ID is retired via a RETIRE_CONNECTION_ID frame (frame-retire-connection-id). </del>  An endpoint that receives packets that it cannot process sends a packet in the following layout (see notation):

Reviewer comments:
This was a little obtuse; it would benefit from a clearer description of what the token is and how it is used.
Thanks Mike. I don't think that I need to worry about "easy to regenerate" (there is a lot of text on that later). The "exchanges" comment is unmodified text, but it is worth fixing.
Having read to the end of section 10 I made a note that I was still trying to figure out what a reset token actually looked like.
Addressed in .

10.3.1. Detecting a Stateless Reset bytes of the UDP datagram. I find this rather opaque given that so far we do not know what a packet looks like, and I cannot see what the encoding of this is. To add to the confusion over packets and frames we now have datagrams.
The encoding of a packet is specifically not relevant at this point. I think that the question is whether it is reasonable to expect that readers have internalized : There is a reasonable criticism here in that the level of detail in the stateless reset description is too much too early. It would be nicer if some of the more detailed stuff here were deferred until later. Unfortunately, it is hard to extricate this from the other more generic stuff in Section 10. So I'm not seeing any real way to improve this without making things worse in other ways.
A few suggestions, but I think this is adequate to resolve the issue.

Revised text:
connections.  An endpoint that wishes to communicate a fatal connection error MUST use a CONNECTION_CLOSE frame if it is able.  <ins> To support this process, an endpoint issues a stateless reset token, which is a 16-byte value that is hard to guess.  If the peer subsequently receives a stateless reset, which is a UDP datagram that ends in that stateless reset token, the peer will immediately end the connection. A stateless reset token is specific to a connection ID.  An endpoint issues a stateless reset token by including the value in the Stateless Reset Token field of a NEW_CONNECTION_ID frame.  Servers can also issue a stateless_reset_token transport parameter during the handshake that applies to the connection ID that it selected during the handshake.  These exchanges are protected by encryption, so only client and server know their value.  Note that clients cannot use the stateless_reset_token transport parameter because their transport parameters do not have confidentiality protection. Tokens are invalidated when their associated connection ID is retired via a RETIRE_CONNECTION_ID frame (frame-retire-connection-id). </ins> An endpoint that receives packets that it cannot process sends a packet in the following layout (see notation):