Original text:
name: enable_multipath (TBD - experiments use 0xbaba) <del> value: 0 (default) for disabled, 1 for multipath support with multiple packet number spaces, 2 for multipath support with one packet number space (this is compatible with I-D.liu-multipath- quic) </del>  If the peer does not carry the enable_multipath transport parameter, which means the peer does not support multipath, endpoint MUST fallback to QUIC-TRANSPORT with single path and MUST NOT use any <del> frame or mechanism defined in this document. </del>  Note that the transport parameter "active_connection_id_limit" QUIC- TRANSPORT limits the number of usable Connection IDs, and also limits

Reviewer comments:
I just want to note that I used value 1 for multiple packet number spaces to bee compatible with what is already used by Alibaba. However, if that change it not a problem for Alibaba, this order is slightly nicer.
I took the following text from draft-liu: This basically makes the one packet number handling mandatory to implement as you also need it if multiple packet number spaces were negotiated but zero length CID is used. The alternative would be to say that you can't used zero length CID if multiple packet number spaces are negotiated. Also I'm currently proposing enablemultipath=1 for multiple number space and enablemultipath=2 for one number space to be compatible with the draft-liu and the alibaba implementation. However if we think one packet number space is mandatory to implement, it would make more sense to have it the other way around and allow fallback to one packet number space, namely if the client ask for two packet number spaces but the server supports only one but would also lead to a successful negotiation. What do people think about this?
As long as inter-op is allowed, I think it might be better to keep both PN space choices optional (Mirja's proposal of using enable_multipath=1 or 2 works for me). The first thing is to allow people more freedom. If some implementors only want to use one option, they just need to implement one code branch. Second, single packet number space requires the modification of loss detection algorithm, the way how rtt is sampled (the overall largest ack may not be the largest acked packet on a given path), and some delayed ACK strategies, which might take additional effort. People may also want to avoid round-robin scheduling in single PN as it creates a lot of holes in the ack range, so certain things regarding performance get coupled. Christian introduced many good practices and we are currently learning from it, so we probably need more experience on that.
Adding the option to negotiate is a very good solution at this point. It would be helpful to hear more people's implementation experience. To avoid failure for interop tests, I suggest that we could negotiate the transport parameter like this: use 2-bits in the value field for negotiating one or more PN spaces. 0x0: don't support multi-path 0x1: only support multiple PN spaces for multi-path 0x2: only support one PN space for multi-path 0x3: support both one PN space and multiple PN space The client could send all these 4 values in the enable_multipath transport parameter which depends on what kind of modes it supports. If the server just support one mode(such as one PN space), it could return 0x2 so that the client knows how to do next. If the server support both, it could choose 0x1 or 0x2 as it prefers, and make sure that the server don't return 0x3 as it need to decide which mode to choose. In 0x2 mode, the endpoints must not use 0-length CID. Then for people who just want one PN space, it would be ok to just support 0x2 mode. For the other guys who don't use 0-length Connection ID and want to get less overhead for ack ranges, they could choose to use 0x1 mode. And for people who want to support both 0-length CID and multiple PN spaces, they could choose 0x3 and of course it will add more modification in the implementation. Maybe this could meet everyone's need for experiments.
NAME any views?
I agree with Yanmei's proposal of 4 options 0, 1, 2 or 3, although I have a slight preference for "the other way around": Client Option Allowed server responses -------------------------------------------- 0x0 0x0 0x1 0x0 or 0x1 0x2 0x0 or 0x2 0x3 0x0, 0x1 or 0x2 Receiving an unexpected value from the server should be a protocol violation. If the transport parameter is not present, the value defaults to zero.
Agree with Christian's design for value definitions. Submitted PR for this issue.
As got merged, I think this is now resolved.
Actually I think this is not fully resolved. The initial question was about use of multiple packet number spaces and zero length connection ID. Do we now say that if multiple packet number spaces are used, zero connection ID cannot be used? If yes, that means we need to remove the text I've cited in the initial issue description from the draft. And also add some text that "zero-length CID MUST not be used with enable_multipath=2". Or if we want to keep that option that basically means that you need to always implement also singe packet number handling even if use of multiple packet number spaces is negotiated, and then we should say that more explicitly in the negotiation section. To me it's not fully clear which option you have agreed to now...?
I opened to track the remaining point.

Revised text:
name: enable_multipath (TBD - experiments use 0xbaba)  <ins> value: 0 (default) for disabled.  Endpoints use 2-bits in the value field for negotiating one or more PN spaces, available option value for client and server are listed in param_value_definition : </ins> If the peer does not carry the enable_multipath transport parameter, which means the peer does not support multipath, endpoint MUST fallback to QUIC-TRANSPORT with single path and MUST NOT use any  <ins> frame or mechanism defined in this document.  If endpoint receives unexpected value for the transport parameter "enable_multipath", it MUST treat this as a connection error of type MP_CONNECTION_ERROR and close the connection. </ins> Note that the transport parameter "active_connection_id_limit" QUIC- TRANSPORT limits the number of usable Connection IDs, and also limits