Original text:
A variable-length integer representing the minimum amount of time in microseconds by which the endpoint can delay an <del> acknowledgement.  Values of 2^24 or greater are invalid, and receipt of these values MUST be treated as a connection error of type TRANSPORT_PARAMETER_ERROR. </del>  An endpoint's min_ack_delay MUST NOT be greater than its max_ack_delay.  Endpoints that support this extension MUST treat A variable-length integer representing an update to the peer's "max_ack_delay" transport parameter (Section 18.2 of QUIC- TRANSPORT).  The value of this field is in microseconds.  Any <del> value smaller than the "min_ack_delay" advertised by this endpoint is invalid.  Receipt of an invalid value MUST be treated as a connection error of type PROTOCOL_VIOLATION. </del>  An 8-bit field representing a boolean truth value.  This field MUST have the value 0x00 (representing "false") or 0x01

Reviewer comments:
Does it make sense to specify any maximum values for any of the ACK frequency frame fields, such as for Packet Tolerance? Does a value of 4 billion make sense? Can I use a in my implementation to store this locally? Is there any expectation around the sizes of these fields? If there is no explicit max, what if I implicitly apply one? I'm working on implementing this and I'm trying to figure out how small (byte size) I can make the variables I use to store the values on the connection.
Update Max Ack Delay will be limited by the Max Ack Delay limit once lands. That leaves Packet Tolerance, which I agree is reasonable to limit to a value smaller than 2^62-1 locally. We could add a comment like "Implementations that have a lower limit than 2^62-1 on the Packet Tolerance MUST set treat it as though the maximum supported Packet Tolerance value has been received."
Slight tweak: "If an endpoint receives a Packet Tolerance value that is larger than the maximum value it can represent, the endpoint MUST use the largest representable maximum value instead."
If I understand correctly, the maximum value of the transport parameter is supposed to ensure that the value is smaller or equal than the transport parameter. According to the maximum value of is . However, the maximum value of is .
We're going to remove the 2^24 - 1 limit and just rely on the MUST that minackdelay can't be greater than maxackdelay, which implies the 2^14-1 limit.
QUIC Transport specifies a maximum value of 2^14 ms (roughly 16s) for the transport parameter. Does this limit apply to values sent in the field of the ACK_FREQUENCY frame, or is any value up to 2^62 microseconds allowed here? Either way, the draft might benefit from clarifying the rules here.
The editors do not have a strong opinion, and we currently say nothing about the limit being changed by this extension, so we're inclined to keep the limit as is and add some text clarifying that the extension doesn't change the limit. We're open to arguments otherwise if people have them.

Revised text:
A variable-length integer representing the minimum amount of time in microseconds by which the endpoint can delay an  <ins> acknowledgement. </ins> An endpoint's min_ack_delay MUST NOT be greater than its max_ack_delay.  Endpoints that support this extension MUST treat A variable-length integer representing an update to the peer's "max_ack_delay" transport parameter (Section 18.2 of QUIC- TRANSPORT).  The value of this field is in microseconds.  Any  <ins> value larger than 16,383,000 microseconds is invalid, as specified for the "max_ack_delay" transport parameter.  Any value smaller than the "min_ack_delay" advertised by this endpoint is invalid. Receipt of an invalid value MUST be treated as a connection error of type PROTOCOL_VIOLATION. </ins> An 8-bit field representing a boolean truth value.  This field MUST have the value 0x00 (representing "false") or 0x01