Original text:
value: 0 (default) for disabled. Endpoints use 2-bits in the value field for negotiating one or more <del> PN spaces, available option value for client and server are listed in </del>  param_value_definition : <del> If the parameter is absent or set to 0, the endpoints MUST fallback to QUIC-TRANSPORT with single path and MUST NOT use any frame or mechanism defined in this document. </del>  If endpoint receives unexpected value for the transport parameter "enable_multipath", it MUST treat this as a connection error of type

Reviewer comments:
The current text assumes that the server transport parameters are composed after seeing the client's proposal. As pointed out in issue , this is a deviation from standard QUIC practice. The proposed text fixes that and specifies what happens if both endpoints select option 3, "support both". In that case, option 2 "multiple number spaces" is selected.
In Section 2 you define a transport parameter and set of values. These are presented in a table with a column header "Allowed server responses", what does that mean? One way to read this is that it implies servers would tailor their Transport Parameters to the value sent by the client but that's conflicting with our philosophy that TPs are unilateral declarations, not active negotiation. So the question for me is, is this just a wording issue or a design one?
I think this mainly means that server are not allow to send 0x3. However, if the client sends 0x3, the server's reply will impact the client behaviour for 1-RTT packets. Is that a negotiation? However, keep in mind that the intention is not to publish this as it.
unilateral negotiation is ok by me. If that's the intent then maybe just rewording of the table to be clariy it is a matrix of combinations is ok, and state somewhere that server 0x3 is illegal. do you mean not to adopt the draft with this type of TP, or the final RFC? I think better clarity is needed for implementation and experiementation as we try and answer the PN question
NAME that's my fault. I wrote that table based on my implementation, in which the server response does depend on the client proposal. We should replace it by a matrix showing what is expected if the client proposes 0-1-2-3 and the server 0-1-2-3. The only problematic case is "3 and 3", and we should simply state what happens there.
NAME please review PR
NAME thanks for the clarification, the new text makes the intent much more clear IMO.
Just to clarify, we are not intending to have this in the final RFC. We would like to have it adopted as it to enable more experimentation.
thanks NAME that also works for me!
LTGTM just 2 nits

Revised text:
value: 0 (default) for disabled. Endpoints use 2-bits in the value field for negotiating one or more  <ins> PN spaces, available option values are listed in </ins> param_value_definition :  <ins> If for any one of the endpoints the parameter is absent or set to 0, or if the two endpoints select incompatible values, one proposing 0x1 and the other proposing 0x2, the endpoints MUST fallback to QUIC- TRANSPORT with single path and MUST NOT use any frame or mechanism defined in this document. If an endpoint proposes the value 0x3, the value proposed by the other is accepted.  If both endpoints propose the value 0x3, the value 0x2 is negotiated. </ins> If endpoint receives unexpected value for the transport parameter "enable_multipath", it MUST treat this as a connection error of type