Original text:
8.1.1.  Upon receiving the client's Initial packet, the server can request address validation by sending a Retry packet (packet-retry) containing a token.  This token MUST be repeated by the client in all A flow showing the use of a Retry packet is shown in fig-retry. <del> 8.1.2. </del>  A server MAY provide clients with an address validation token during one connection that can be used on a subsequent connection.  Address the token provided in a Retry for future connections.  Servers MAY discard any Initial packet that does not carry the expected token. <del> A token SHOULD be constructed in a way that allows the server to distinguish it from tokens that are sent in Retry packets as they are carried in the same field. The token MUST NOT include information that would allow it to be linked by an on-path observer to the connection on which it was issued.  For example, it cannot include the connection ID or addressing information unless the values are encrypted. </del> Unlike the token that is created for a Retry packet, there might be some time between when the token is created and when the token is subsequently used.  Thus, a token SHOULD have an expiration time, time.  A server can store the expiration time or include it in an encrypted form in the token.  It is unlikely that the client port number is the same on two different connections; validating the port is therefore unlikely to be successful. A token allows a server to correlate activity between the connection where the token was issued and any connection where it is used. Clients that want to break continuity of identity with a server MAY <del> discard tokens provided using the NEW_TOKEN frame.  A token obtained in a Retry packet MUST be used immediately during the connection attempt and cannot be used in subsequent connection attempts. A client SHOULD NOT reuse a token in different connections.  Reusing a token allows connections to be linked by entities on the network path; see migration-linkability.  A client MUST NOT reuse a token if it believes that its point of network attachment has changed since the token was last used; that is, if there is a change in its local IP address or network interface.  A client needs to start the connection process over if there is any change in its local address prior to completing the handshake. </del>  Clients might receive multiple tokens on a single connection.  Aside from preventing linkability, any token can be used in any connection times in a short period.  Servers are encouraged to allow tokens to be used only once, if possible. <del> 8.1.3. </del>  An address validation token MUST be difficult to guess.  Including a large enough random value in the token would be sufficient, but this

Reviewer comments:
Question for reviewers: do you think it necessary to point out that this distinction doesn't need to be hidden from other entities? That's almost obvious based on the way that this results in different behaviour from servers, but should it be written down?
We currently say that these tokens SHOULD be distinguishable by a server on the basis that an error in a NEW_TOKEN token is recoverable, but an error in a Retry token is fatal. I don't see why this can't be MUST. If we make it "MUST", then we can rely on this property in the design.
Agreed, that'd be a useful property to rely on.
Does that property need to hold if there are bit flips in the token? If you’re encrypting the token, this would be easy to ensure: put the distinguishing bit under crypto cover. If you’re using a map lookup, you’ll probably have to work a little bit harder.
Please ignore my last post, I mixed up Retry packets and Initials. Tokens in the client’s Initial are part of the AAD, so we don’t have to worry about bit flips.
One suggestion to change a normative to a MUST, on existing text.Some small suggestions, but LG

Revised text:
8.1.1. <ins> A token sent in a NEW_TOKEN frames or a Retry packet MUST be constructed in a way that allows the server to identity how it was provided to a client.  These tokens are carried in the same field, but require different handling from servers. 8.1.2. </ins> Upon receiving the client's Initial packet, the server can request address validation by sending a Retry packet (packet-retry) containing a token.  This token MUST be repeated by the client in all A flow showing the use of a Retry packet is shown in fig-retry.  <ins> 8.1.3. </ins> A server MAY provide clients with an address validation token during one connection that can be used on a subsequent connection.  Address the token provided in a Retry for future connections.  Servers MAY discard any Initial packet that does not carry the expected token.  Unlike the token that is created for a Retry packet, there might be some time between when the token is created and when the token is subsequently used.  Thus, a token SHOULD have an expiration time, time.  A server can store the expiration time or include it in an encrypted form in the token. <ins> A token issued with NEW_TOKEN MUST NOT include information that would allow values to be linked by an on-path observer to the connection on which it was issued, unless the values are encrypted.  For example, it cannot include the previous connection ID or addressing information.  Information that allows the server to distinguish between tokens from Retry and NEW_TOKEN MAY be accessible to entities other than the server. </ins> It is unlikely that the client port number is the same on two different connections; validating the port is therefore unlikely to be successful. A token allows a server to correlate activity between the connection where the token was issued and any connection where it is used. Clients that want to break continuity of identity with a server MAY  <ins> discard tokens provided using the NEW_TOKEN frame.  In comparison, a token obtained in a Retry packet MUST be used immediately during the connection attempt and cannot be used in subsequent connection attempts. A client SHOULD NOT reuse a NEW_TOKEN token for different connection attempts.  Reusing a token allows connections to be linked by entities on the network path; see migration-linkability.  A client MUST NOT reuse a token if it believes that its point of network attachment has changed since the token was last used; that is, if there is a change in its local IP address or network interface.  A client needs to start the connection process over if there is any change in its local address prior to completing the handshake. </ins> Clients might receive multiple tokens on a single connection.  Aside from preventing linkability, any token can be used in any connection times in a short period.  Servers are encouraged to allow tokens to be used only once, if possible.  <ins> 8.1.4. </ins> An address validation token MUST be difficult to guess.  Including a large enough random value in the token would be sufficient, but this