Change:
retiring-cids. Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number <del> greater than any previously sent to the peer MAY be treated as a </del> <ins> greater than any previously sent to the peer MUST be treated as a </ins> connection error of type PROTOCOL_VIOLATION. The sequence number specified in a RETIRE_CONNECTION_ID frame MUST

Discussion:
When it comes to error checks for protocol violations, our principle is that easy to implement error checks are REQUIRED. Only error checks that might require a lot of state to perform are optional. The check that the sequence number retired in a RETIRECONNECTIONID frame is smaller than the highest issued connection ID is a single trivial uint64 comparison. Furthermore, every implementation needs to track the highest issued sequence number anyway, since connection IDs are issued in order.
This is small and I support it, but I think it needs to be marked design and run through the process because it changes normative language.
An issue to match with PR The text is: "Receipt of a RETIRECONNECTIONID frame containing a sequence number greater than any previously sent to the peer MAY(->MUST) be treated as a connection error of type PROTOCOL_VIOLATION."
Just pasting in the PR text:
I agree with the reasoning here and agree that it’s easy enough to check, but didn’t we consider this previously and decide against it for some reason (reordering or some other issue making this possible to have happen?)?
Reordering won't change what the maximum sequence number is. That should be tracked.
I agree with Martin(and Marten). This is similar to the rule that a peer can't ACK a packet number you've never sent.
NAME : I have a vague recollection, but I think that might have been about tracking this at the receiver of NEWCONNECTIONID frames. This issue is about what the corresponding sender does when the receiver indicates a CID that the sender never sent.
I think there might be issues with checking for any invalid sequence number, but the maximum should be easy. But if that is the case, what is the point of specifically checking for max and not a host of other bad cases? Sanity check...
I think the question is if we consider processing of NEWCONNECTIONID and RETIRECONNECTIONID frames as a mandatory feature. Migration is an optional feature of QUIC. For endpoints that do not migrate, there is no reason to update the Connection IDs (note that even though we recently introduced Retire Prior To field, we do not mandate endpoints to respect it - the keyword is "SHOULD").

If we consider that way, I think it is reasonable to never use a MUST for anything related to NEWCONNECTIONID or RETIRECONNECTIONID frames (except for parsing and skipping them).
NAME I wouldn't encourage people to think of NEWCONNECTIONID and RETIRECONNECTIONID as optional, but I agree that effectively they are in many cases. However, if you sent NEWCONNECTIONID, I don't think it's optional to not correctly process RETIRECONNECTIONID, and that's the question here(I copy-pasted the paragraph above). If the peer never sends RETIRECONNECTIONID because it doesn't fully implement connection ID functionality, then this is not a problem.
I agree with Ian. Processing these frames, and acting accordingly is not optional. Even in the absence of migration RETIRECONNECTIONID can be used to force a peer to start using new connection IDs. WinQuic will make use of this to dynamically balance load of connections across processors; independent of migration.
NAME Thank you for clarifying your position. I'd be perfectly fine if the intent of the proposed change is to require validation if the endpoint has sent a NEWCONNECTIONID frame. My problem has been that I have been uncertain if the proposed change meant that; I'd be happy to proposed editorial tweaks to better clarify that. NAME By saying "force a peer to start using new connection IDs", I think you are referring to the Retire Prior To field of the NEWCONNECTIONID frame. That's a SHOULD (as the text currently says), IIRC we have agreed on that.
If you've never sent a NEWCONNECTIONID, how could receiving a RETIRECONNECTIONID frame ever be valid?
NAME sorry. You're right, I meant the NEWCONNECTIONID frame's Retire Prior To field. But I disagree on your interpretation of the : The is for . If you don't do it, the connection will eventually break, likely via a stateless reset.
NAME The preferredaddress TP. An endpoint is allowed, even though not required, to send a RETIRECONNECTIONID frame to retire a CID used during handshake. Quoting from : An endpoint sends a RETIRECONNECTIONID frame (type=0x19) to indicate that it will no longer use a connection ID that was issued by its peer.

This may include the connection ID provided during the handshake._
NAME The question is the intent of using "SHOULD in a timely manner" rather than "MUST in a timely manner". Yes, the connection would break, if the receiver does not migrate to a new connection ID. However, because we use a SHOULD, that is one of the expected outcomes when an endpoint sends a NEWCONNECTIONID frame carrying non-zero Retire Prior To field.
NAME it sounds like you're arguing that it's an acceptable trade off for clients that don't want to implement support for the Retire Prior To field. I hope that isn't what you're saying. As it is, I'm thinking I'm going to have to add some greasing for this feature to WinQuic.
NAME I am saying that that is the natural way of reading the text. It seems to me that there is a disagreement on what the text implies, and I think it'd be more productive to try to polish up the intent of the text before resorting to encouraging particular behavior through greasing; hence .
Thanks NAME that sounds about right, this is the other direction, makes sense.