Original text:
An endpoint can cause its peer to retire connection IDs by sending a NEW_CONNECTION_ID frame with an increased Retire Prior To field. Upon receipt, the peer MUST retire the corresponding connection IDs <del> and send corresponding RETIRE_CONNECTION_ID frames.  Failing to retire the connection IDs within approximately one PTO can cause packets to be delayed, lost, or cause the original endpoint to send a stateless reset in response to a connection ID it can no longer route correctly. </del>  An endpoint MAY discard a connection ID for which retirement has been requested once an interval of no less than 3 PTO has elapsed since an for different connection IDs, the endpoint MAY treat that receipt as a connection error of type PROTOCOL_VIOLATION. <del> The Retire Prior To field is a request for the peer to retire all connection IDs with a sequence number less than the specified value. This includes the initial and preferred_address transport parameter connection IDs.  The peer SHOULD retire the corresponding connection IDs and send the corresponding RETIRE_CONNECTION_ID frames in a timely manner. The Retire Prior To field MUST be less than or equal to the Sequence Number field.  Receiving a value greater than the Sequence Number MUST be treated as a connection error of type FRAME_ENCODING_ERROR. </del>  Once a sender indicates a Retire Prior To value, smaller values sent in subsequent NEW_CONNECTION_ID frames have no effect.  A receiver

Reviewer comments:
Consolidate Retire Prior To instructions in the section that discusses retiring CIDs and clean up the frame description. Left the operational requirements about the frame and its values with the frame, but all of the mechanism for requesting retirement of CIDs is now in one section.
In the section talking about Connection IDs (section 5.1.2) it says: In the description of the NEWCONNECTIONID frame (section 19.15) it says: So it's not clear if you just SHOULD or if you MUST send the RETIRECONNECTIONID frame. As an editorial remark, I find the existing text a bit hard to understand, since it's spread over these two sections. Maybe it would be easier to keep the frame description relatively short, and move more of the logic into the section that describes how CIDs are used and retired.
I think what we concluded in previous discussion was that you MUST retire them, and SHOULD do so in a timely manner. The suggested reorganization isn't a bad suggestion either.
Based on this feedback, this can probably be handled as an editorial matter. I would be happy to receive a PR that reconciled this with .
Definitely agree that this is editorial, we just missed this duplicate requirement in the original change. Removed that duplication and cleaned up the frame description a bit.

Revised text:
An endpoint can cause its peer to retire connection IDs by sending a NEW_CONNECTION_ID frame with an increased Retire Prior To field. Upon receipt, the peer MUST retire the corresponding connection IDs  <ins> using RETIRE_CONNECTION_ID frames.  Failure to retire the connection IDs within approximately one PTO can cause packets to be delayed, lost, or cause the original endpoint to send a stateless reset in response to a connection ID it can no longer route correctly. </ins> An endpoint MAY discard a connection ID for which retirement has been requested once an interval of no less than 3 PTO has elapsed since an for different connection IDs, the endpoint MAY treat that receipt as a connection error of type PROTOCOL_VIOLATION.  <ins> The Retire Prior To field counts connection IDs established during connection setup and the preferred_address transport parameter (see retiring-cids).  The Retire Prior To field MUST be less than or equal to the Sequence Number field.  Receiving a value greater than the Sequence Number MUST be treated as a connection error of type FRAME_ENCODING_ERROR. </ins> Once a sender indicates a Retire Prior To value, smaller values sent in subsequent NEW_CONNECTION_ID frames have no effect.  A receiver