Change:
7.3.3. In inactive mode, the Retry service forwards all packets without <del> further inspection or processing. </del> <ins> further inspection or processing.  The rest of this section only applies to a service in active mode. </ins> Retry services MUST NOT issue Retry packets except where explicitly allowed below, to avoid sending a Retry packet in response to a Retry token. <del> 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> <ins> The service MUST generate Retry tokens with the format described above when it receives a client Initial packet with no token. If there is a token of either type, the service MUST attempt to decrypt it. To decrypt a packet, the service checks the Token Type and constructs a pseudoheader with the appropriate format for that type, using the bearing packet's Destination Connection ID to populate the Retry Source Connection ID field, if any. </ins> <del> The service SHOULD decrypt incoming tokens.  The service SHOULD drop packets with unknown key sequence, or an AEAD ICV that does not match the expected value.  (By construction, the AEAD ICV will only match if the client IP Address also matches.) </del> <ins> A token is invalid if: </ins> <del> If the token verification passes, and the ODCIL and RSCIL fields are both 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. </del> <ins> it uses unknown key sequence, </ins> <del> 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. </del> <ins> the AEAD ICV does not match the expected value (By construction, it will only match if the client IP Address, and any Retry Source Connection ID, also matches), </ins> <del> 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. </del> <ins> the ODCIL, if present, is invalid for a client-generated CID (less than 8 or more than 20 in QUIC version 1), </ins> <del> 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. </del> <ins> the Timestamp of a token points to time in the past (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), or </ins> <del> All other packets SHOULD be forwarded to the server. </del> <ins> the port number, if present, does not match the source port in the encapsulating UDP header. Packets with valid tokens MUST be forwarded to the server. The service MUST drop packets with invalid tokens.  If the token is of type '1' (NEW_TOKEN), it MUST respond with a Retry packet.  If of type '0', it MUST NOT respond with a Retry packet. </ins> 7.3.4. <del> When issuing Retry or NEW_TOKEN tokens, the server MUST include the client IP address in the authenticated data as specified in token- protection-with-aead.  The ODCIL and RSCIL fields are zero for NEW_TOKEN tokens, making them easily distinguishable from Retry tokens. </del> <ins> The server MAY issue Retry or NEW_TOKEN tokens in accordance with RFC9000.  When doing so, it MUST follow the format above. </ins> The server MUST validate all tokens that arrive in Initial packets, <del> as they may have bypassed the Retry service. </del> <ins> as they may have bypassed the Retry service.  It determines validity using the procedure in ss-service. </ins> <del> For Retry tokens that follow the format above, servers SHOULD use the timestamp field to apply its expiration limits for tokens.  This need not be precisely synchronized with the retry service.  However, servers MAY allow retry tokens marked as being a few seconds in the past, due to possible clock synchronization issues. </del> <ins> If a valid Retry token, the server populates the original_destination_connection_id transport parameter using the corresponding token field.  It populates the retry_source_connection_id transport parameter with the Destination Connection ID of the packet bearing the token. </ins> <del> After decrypting the token, the server uses the corresponding fields to populate the original_destination_connection_id transport parameter, with a length equal to ODCIL, and the retry_source_connection_id transport parameter, with length equal to RSCIL. </del> <ins> In all other respects, the server processes both valid and invalid tokens in accordance with RFC9000. </ins> For QUIC versions the service does not support, the server MAY use any token format. <del> As discussed in RFC9000, a server MUST NOT send a Retry packet in response to an Initial packet that contains a retry token. </del> 8. QUIC-LB requires common configuration to synchronize understanding of

Discussion:
Takes the RSCID out of the token body because the server can catch mismatches with the DCID if it's used as associated data.
I have read URL but still don't understand why we need to include it again in token. I'd thought that that server or retry service can read it from the Initial packet (invariant long header packet). What happen if they are different? Which one server should take to initiate the connection?
I recommend Section 7.3 of RFC 9000 to understand this: "The values provided by a peer for these transport parameters MUST match the values that an endpoint used in the Destination and Source Connection ID fields of Initial packets that it sent (and received, for servers). Endpoints MUST validate that received transport parameters match received connection ID values." The connection IDs in Retry and Initial packets are not effectively authenticated unless they are included in transport parameters, which are included in key computation. If the server doesn't have a trustworthy record of the CID it picked (this token), it has no way of confirming that the Retry's SCID wasn't modified in flight.
yeah, I get that server needs to verify SCID in Retry packet. I still do not get why we need to include Retry SCID again in the token.
How would it verify the SCID was unchanged if it wasn't in the token?
I think it'd be authenticated by including in the associated data, i.e
Hmm, this is a clever proposal. I'll reopen to reconsider properly.
Trying to wrap my head around this. The server wants to verify that the RSCID is correct, so the current solution is to copy that in the token. If the client messes up, the server compares the value in the token to the value sent by the client. Yes, putting that in the pseudo header will mostly work. If the client does not use the specified RSCID, the token will just not decode. But there are two potential issues: 1) Debugging is harder. For example, there will not be any way to differentiate between wrong RSCID and wrong IP 2) If the token came as "NEW TOKEN", there is no RSCID specified. There will need to be a special case for constructing the pseudo header, but that means exposing the difference between Retry Token and New Token in clear text.

In any case, we would need additional text for the New Token case.
Christian, good point on (2). The NSS Token already distinguishes the types in cleartext, so perhaps that's not such a big deal. But yes, we'd need to take a bit from the key sequence to indicate the token type.
I filed , please take a look.