Original text:
6.3.3.  When in active mode, the service MUST generate Retry tokens with the format described above when it receives a client Initial packet with no token. <del> In active mode, the service SHOULD decrypt the incoming tokens.  The service SHOULD drop packets with unknown key sequence, or an AEAD checksum that does not match the expected value.  (By construction, the AEAD checksum will only match if the client IP Address also matches.) </del>  If the token checksum passes, and the ODCIL and RSCIL fields are both <del> zero, then this is an expired NEW_TOKEN token generated by the server.  An active Retry Service MUST drop the packet and issue a Retry packet with the appropriate token. The service SHOULD drop packets if the Timestamp of the retry token points to a past date; however, in order to allow for clock skew, it SHOULD NOT drop packets if the Timestamp merely points to a a few seconds in the past. It SHOULD forward packets if the AEAD checksum and the Timestamp can be verified, regardless of the other fields. However, the service MUST NOT decrypt or validate tokens if there is a NAT between it and the servers. In inactive mode, the service SHOULD forward all packets to the server so that the server can issue an up-to-date token to the client. </del>  6.3.4.

Reviewer comments:
Ended up rewriting the Retry Requirements for shared-state while adding the bit about port verification. Inspired by the review here: URL

Revised text:
6.3.3. <ins> In inactive mode, the Retry service forwards all packets without further inspection or processing. Retry services MUST NOT issue Retry packets except where explicitly allowed below, to avoid sending a Retry packet in response to a Retry token. </ins> When in active mode, the service MUST generate Retry tokens with the format described above when it receives a client Initial packet with no token.  <ins> The service SHOULD decrypt incoming tokens.  The service SHOULD drop packets with unknown key sequence, or an AEAD checksum that does not match the expected value.  (By construction, the AEAD checksum will only match if the client IP Address also matches.) </ins> If the token checksum passes, and the ODCIL and RSCIL fields are both  <ins> zero, then this is a NEW_TOKEN token generated by the server. Processing of NEW_TOKEN tokens is subtly different from Retry tokens, as described below. The service SHOULD drop a packet containing a token where the ODCIL is greater than zero and less than the minimum number of octets for a client-generated CID (8 in QUIC version 1).  The service also SHOULD drop a packet containing a token where the ODCIL is zero and RSCIL is nonzero. If the Timestamp of a token points to time in the past, the token has expired; however, in order to allow for clock skew, it SHOULD NOT consider tokens to be expired if the Timestamp encodes a few seconds in the past.  An active Retry service SHOULD drop packets with expired tokens.  If a NEW_TOKEN token, the service MUST generate a Retry packet in response.  It MUST NOT generate a Retry packet in response to an expired Retry token. If a Retry token, the service SHOULD drop packets where the port number encoded in the token does not match the source port in the encapsulating UDP header. All other packets SHOULD be forwarded to the server. </ins> 6.3.4.