Original text:
receipt of a min_ack_delay that is greater than the received max_ack_delay as a connection error of type PROTOCOL_VIOLATION.  Note that while the endpoint's max_ack_delay transport parameter is in <del> milliseconds (Section 18.2 in QUIC-TRANSPORT), min_ack_delay is </del>  specified in microseconds. 4. is invalid. A variable-length integer representing an update to the peer's <del> "max_ack_delay" transport parameter (Section 18.2 in QUIC- </del>  TRANSPORT).  The value of this field is in microseconds.  Any <del> value smaller than the min_ack_delay advertised by this endpoint </del>  is invalid. <del> Receipt of invalid values in an ACK-FREQUENCY frame MUST be treated as a connection error of type PROTOCOL_VIOLATION. </del>  ACK-FREQUENCY frames are ack-eliciting.  However, their loss does not require retransmission. <del> An endpoint MUST NOT send an empty ACK-FREQUENCY frame.  Endpoints MUST treat receipt of an empty ACK-FREQUENCY frame as a connection error of type PROTOCOL_VIOLATION. </del> An endpoint MAY send ACK-FREQUENCY frames multiple times during a connection and with different values. <del> An endpoint will have committed a max_ack_delay value to the peer, </del>  which specifies the maximum amount of time by which the endpoint will delay sending acknowledgments.  When the endpoint receives an ACK- FREQUENCY frame, it MUST update this maximum time to the value 7. <del> TBD. </del>  8. TBD. 

Reviewer comments:
merging.
If it doesn't change it, we should say so. If it allows it to be reduced, then we need to understand what the limits are(ie: it can't be lowered to 1us presumably?). Admittedly, the way we're using maxackdelay should be safe to assuming a 0 value, since the SRTT will accrue the excess.

Revised text:
receipt of a min_ack_delay that is greater than the received max_ack_delay as a connection error of type PROTOCOL_VIOLATION.  Note that while the endpoint's max_ack_delay transport parameter is in  <ins> milliseconds (Section 18.2 of QUIC-TRANSPORT), min_ack_delay is </ins> specified in microseconds. 4. is invalid. A variable-length integer representing an update to the peer's  <ins> "max_ack_delay" transport parameter (Section 18.2 of QUIC- </ins> TRANSPORT).  The value of this field is in microseconds.  Any  <ins> value smaller than the "min_ack_delay" advertised by this endpoint </ins> is invalid.  <ins> Receipt of an empty ACK-FREQUENCY frame or invalid values in an ACK- FREQUENCY frame MUST be treated as a connection error of type PROTOCOL_VIOLATION. </ins> ACK-FREQUENCY frames are ack-eliciting.  However, their loss does not require retransmission.  An endpoint MAY send ACK-FREQUENCY frames multiple times during a connection and with different values.  <ins> An endpoint will have committed a "max_ack_delay" value to the peer, </ins> which specifies the maximum amount of time by which the endpoint will delay sending acknowledgments.  When the endpoint receives an ACK- FREQUENCY frame, it MUST update this maximum time to the value 7.  <ins> On sending an update to the peer's "max_ack_delay", an endpoint can use this new value in later computations of its Probe Timeout (PTO) period; see Section 5.2.1 of QUIC-RECOVERY.  The endpoint MUST however wait until the ACK-FREQUENCY frame that carries this new value is acknowledged by the peer. Until the frame is acknowledged, the endpoint MUST use the greater of the current "max_ack_delay" and the value that is in flight when computing the PTO period.  Doing so avoids spurious PTOs that can be caused by an update that increases the peer's "max_ack_delay". While it is expected that endpoints will have only one ACK-FREQUENCY frame in flight at any given time, this extension does not prohibit having more than one in flight.  Generally, when using "max_ack_delay" for PTO computations, endpoints MUST use the maximum of the current value and all those in flight. </ins> 8. TBD. <ins> 9. TBD. </ins>