search

quicwg / multipath

In-progress version of draft-ietf-quic-multipath
Other
49 stars 17 forks source link

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

Open gloinul opened 1 month ago

gloinul commented 1 month ago

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.

Yanmei-Liu commented 1 month ago

Fixed in PR #417

mirjak commented 1 month ago

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 commented 1 month ago

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

mirjak commented 1 month ago

@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.