Original text:
An endpoint MUST NOT excessively delay acknowledgements of ack- eliciting packets.  The maximum ack delay is communicated in the <del> max_ack_delay transport parameter; see Section 18.1 of QUIC- </del>  TRANSPORT.  max_ack_delay implies an explicit contract: an endpoint promises to never delay acknowledgments of an ack-eliciting packet by more than the indicated value.  If it does, any excess accrues to the New transport parameters can be used to negotiate new protocol behavior.  An endpoint MUST ignore transport parameters that it does not support.  Absence of a transport parameter therefore disables any <del> optional protocol feature that is negotiated using the parameter. </del>  New transport parameters can be registered according to the rules in iana-transport-parameters. 18.1.  This section details the transport parameters defined in this document. The initial contents of this registry are shown in iana-tp-table.  22.2. IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a

Reviewer comments:
NAME I added IANA considerations, analogous to those in the HTTP doc for the stream type.
We have space for private transport parameters and a process for assigning new standard transport parameters. However, since we do not apply GREASE to transport parameters, we leave ourselves open to that flexibility ossifying. I'm happy to produce a PR to address this in the spec.
During interop in London we found an implementation that failed the handshake upon seeing an unknown transport parameter. I think applying GREASE to transport parameters is a great idea.
Discussed in London, NAME to prepare a PR
NAME any progress here?
I have prepared something. I can open a pr
NAME sorry I totally dropped the ball here! I had text ages ago and was circling back today finally. Thanks NAME for seeing to it.
Thanks Marten!Thanks for writing this up!Need to fix the examples, but otherwise looks good.

Revised text:
An endpoint MUST NOT excessively delay acknowledgements of ack- eliciting packets.  The maximum ack delay is communicated in the  <ins> max_ack_delay transport parameter; see Section 18.2 of QUIC- </ins> TRANSPORT.  max_ack_delay implies an explicit contract: an endpoint promises to never delay acknowledgments of an ack-eliciting packet by more than the indicated value.  If it does, any excess accrues to the New transport parameters can be used to negotiate new protocol behavior.  An endpoint MUST ignore transport parameters that it does not support.  Absence of a transport parameter therefore disables any  <ins> optional protocol feature that is negotiated using the parameter.  As described in transport-parameter-grease, some identifiers are reserved in order to exercise this requirement. </ins> New transport parameters can be registered according to the rules in iana-transport-parameters. 18.1. <ins> Transport parameters with an identifier of the form "31 * N + 27" for integer values of N are reserved to exercise the requirement that unknown transport parameters be ignored.  These transport parameters have no semantics, and may carry arbitrary values. 18.2. </ins> This section details the transport parameters defined in this document. The initial contents of this registry are shown in iana-tp-table. <ins> Additionally, each value of the format "31 * N + 27" for integer values of N (that is, "27", "58", "89", ...) MUST NOT be assigned by IANA. </ins> 22.2. IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a