The specification of MP_NEW_CONNECTION_ID and MP_RETIRE_CONNECTION_ID frames was clarified in PR #361, but some minor details are still missing:
In RFC 9000, there is a discussion about enforcing the connection ID limit after the combination of "retire prior" and the newly added CID. Maybe we should add a bit of text explaining that this limit is per path.
In RFC9000, there is a prohibition from applying "retire to" to the CID used to send the packet. I think that still stands, but we that we should clarify that the test applies to the path-ID + sequence number tuple.
In RFC 9000 says that "_Endpoints SHOULD NOT issue updates of the Retire Prior To field before receiving RETIRE_CONNECTIONID frames that retire all connection IDs indicated by the previous Retire Prior To value." We may want to clarify that this requirement still stands, but only apply to the CID with the same path-ID.
The specification of MP_NEW_CONNECTION_ID and MP_RETIRE_CONNECTION_ID frames was clarified in PR #361, but some minor details are still missing:
In RFC 9000, there is a discussion about enforcing the connection ID limit after the combination of "retire prior" and the newly added CID. Maybe we should add a bit of text explaining that this limit is per path.
In RFC9000, there is a prohibition from applying "retire to" to the CID used to send the packet. I think that still stands, but we that we should clarify that the test applies to the path-ID + sequence number tuple.
In RFC 9000 says that "_Endpoints SHOULD NOT issue updates of the Retire Prior To field before receiving RETIRE_CONNECTIONID frames that retire all connection IDs indicated by the previous Retire Prior To value." We may want to clarify that this requirement still stands, but only apply to the CID with the same path-ID.