Change:
We've added new transport parameters since we wrote section 7.3.1. The following TPs are neither MUST NOT remember nor MUST remember: maxidletimeout maxpacketsize maxackdelay disableactivemigration
In my opinion, the only one that the client SHOULD remember is maxpacketsize. This is an interesting special case since the server doesn’t need to remember this one (nor store it in the session ticket). I don’t see any motivation for remembering the other three TPs.
Remember ing maxackdelay is useless I believe, because Initial and Handshake packets use an maxackdelay of kAlarmGranularity. I would not want to remember disableactivemigration or maxidletimeout if at all possible.
As maxidletimeout and disableactivemigration can only ever apply after the handshake is complete, remembrance is unnecessary. maxackdelay is annoying because it implies a particular acknowledgment schedule for 0-RTT that might not be compatible with the path, but setting it to the absolute minimum is problematic also.
See also .
I don't read the text this way. In the fourth paragraph it says that "A client that attempts to send 0-RTT data MUST remember all other transport parameters used by the server." [i.e. all but a short list of obviously insane TPs listed in the previous paragraph. I suggest we close with no action.
NAME that's a good point that the list doesn't have to be exhaustive. The text says clients MUST NOT remember certain parameters and MUST remember all others. So perhaps the more apt question is whether any of these unmentioned TPs belong in the MUST-NOT list.
So I'm reviewing this and the only case I'm concerned about is maxackdelay for 0-RTT. The server's values might be remembered by the client and applied to its logic. But I can't see any reason why this might cause actual problems as long as the client adjusts its value when it can. If the server increases this value, then any increase might accrue to the RTT estimates that are received before the client installs the new value. But the client won't be generating RTT estimates based on application data, so this is a wash. And the effect on the PTO duration has no effect because you don't arm PTO because the recovery draft . So, I see three valid choices: Say nothing. Let people work out that maxackdelay has no effect prior to the handshake completing on their own. Explain this. Probably just by saying "Note that maxackdelay has no effect during the handshake therefore cannot be violated by a client sending 0-RTT data." OR something along those lines. Explicitly forbid remembering this parameter, by adding it to the list but don't explain it. I'm inclined toward number 3 here, if only to save people the effort of working through this one.
I agree with your analysis and your recommendation(3) that clients MUST NOT remember it. We're pretty clear that the maxackdelay is 0 until you receive the value in TPs, and this fits with that model.
The proposed resolution in PR 3545, although short and sweet, categorises a TP as a MUST NOT. In the interest of process, I'm marking this issue as design. Since there is a proposal things should make the next round of consensus call, unless some objections are raised in the meantime.
Accidental close, sorry.

Discussion:
A client need not store a transport parameter it cannot process. A client MUST NOT use remembered values for the following parameters: <del> original_connection_id, preferred_address, stateless_reset_token, and ack_delay_exponent.  The client MUST use the server's new values in the handshake instead, and absent new values from the server, the default value. </del> <ins> ack_delay_exponent, max_ack_delay, original_connection_id, preferred_address, and stateless_reset_token.  The client MUST use the server's new values in the handshake instead, and absent new values from the server, the default value. </ins> A client that attempts to send 0-RTT data MUST remember all other transport parameters used by the server.  The server can remember