multipath icon indicating copy to clipboard operation
multipath copied to clipboard

Editorial: SHOULD for the wrong aspect on when to use MP_*_CONNECTION_ID frames

Open gloinul opened this issue 1 year ago • 4 comments

Section 3: "Endpoints SHOULD use the MP_NEW_CONNECTION_ID frame to provide new connection IDs and, respectively, the MP_RETIRE_CONNECTION_ID frame to retire connection IDs after a successful handshake indicating multipath support by both endpoints."

The SHOULD appear to point to the wrong aspect. One is required to use MP_NEW_CONNECTION_ID frame to provide new CIDs, what is SHOULD is to do it after a successful handshake. So sentence need reformulation.

gloinul avatar Jul 10 '24 14:07 gloinul

Fixed in PR #417

Yanmei-Liu avatar Jul 11 '24 12:07 Yanmei-Liu

Actually this sentence is in the wrong place and should only talk about using the MP frames for path ID 0 (because there is no other option for the other paths). I think that is a left over from the pre-path-ID version. I created a new PR #419

mirjak avatar Jul 18 '24 10:07 mirjak

Actually I don't agree that we SHOULD use MP frames for Path ID 0 as the initial path. The implementation could decide on their own that they could use the original NEW_CID/RETIRE_CID for the initial path. It would be better compatible with RFC9000.

Actually this sentence is in the wrong place and should only talk about using the MP frames for path ID 0 (because there is no other option for the other paths). I think that is a left over from the pre-path-ID version. I created a new PR #419

Yanmei-Liu avatar Jul 24 '24 12:07 Yanmei-Liu

@Yanmei-Liu this is an editorial issue. If you want to change the SHOULD, please open a new issue. Please note that this is also related to the discussion in issue #220 for MP_ACK frames. However, SHOULD allows the use of non MP frames for path 0, so I think there is no problem.

mirjak avatar Jul 24 '24 15:07 mirjak