Change:
The token body has the following fields: <ins> Timestamp: The Timestamp is a 64-bit integer, in network order, that expresses the expiration time of the token as a number of seconds in POSIX time (see Sec.  4.16 of TIME_T). </ins> ODCIL: The original destination connection ID length.  Tokens in <del> NEW_TOKEN frames MUST set this field to zero. </del> <ins> NEW_TOKEN frames do not have this field. </ins> <del> RSCIL: The retry source connection ID length.  Tokens in NEW_TOKEN frames MUST set this field to zero. </del> <ins> Original Destination Connection ID: The server or Retry Service copies this from the field in the client Initial packet.  Tokens in NEW_TOKEN frames do not have this field. </ins> Port: The Source Port of the UDP datagram that triggered the Retry packet.  This field MUST be present if and only if the ODCIL is greater than zero.  This field is therefore always absent in tokens in NEW_TOKEN frames. <del> Original Destination Connection ID: The server or Retry Service copies this from the field in the client Initial packet. Retry Source Connection ID: The server or Retry service copies this from the Source Connection ID of the Retry packet. Timestamp: The Timestamp is a 64-bit integer, in network order, that expresses the expiration time of the token as a number of seconds in POSIX time (see Sec.  4.16 of TIME_T). </del> Opaque Data: The server may use this field to encode additional information, such as congestion window, RTT, or MTU.  The Retry Service MUST have zero-length opaque data.

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.