Draft: draft-ietf-quic-ack-frequency

Commentary: We have inconsistent definitions for Ack - Eliciting Threshold , which probably has people implementing this differently . In Section 4 : In Section 7 : The intended definition is the one in Section 4 , so fixes and makes this consistent . 
 The document uses MUST in multiple places , however , as discussed in the new proposed text for the security considerations ( see PR ) the requester can not enforce any ACK strategy and there might be reason like practical limitation or an overload situation where the ACK sender simply decides to send less ACKs . So the question is really can to requirements be MUSTs or is SHOULD more realistic and correct ?
A variable-length integer representing the maximum number of ack-
eliciting packets the recipient of this frame can receive without
sending an acknowledgment.  In other words, an acknowledgement is
sent when more than this number of ack-eliciting packets have been
received.  Since this is a maximum value, a receiver can send an
acknowledgement earlier.  A value of 0 results in a receiver
immediately acknowledging every ack-eliciting packet.
A variable-length integer representing the maximum number of ack-
eliciting packets the recipient of this frame receives before
sending an acknowledgment.  A receiving endpoint SHOULD send at
least one ACK frame when more than this number of ack-eliciting
packets have been received.  A value of 0 results in a receiver
immediately acknowledging every ack-eliciting packet.  By default,
an endpoint sends an ACK frame for every other ack-eliciting
packet, as specified in Section 13.2.2 of QUIC-TRANSPORT, which
corresponds to a value of 1.
A variable-length integer representing the value to which the
endpoint requests the peer update its "max_ack_delay"
(Section 18.2 of QUIC-TRANSPORT).  The value of this field is in
microseconds, unlike the 'max_ack_delay' transport parameter,
which is in milliseconds.  Sending a value smaller than the
"min_ack_delay" advertised by the peer is invalid.  Receipt of an
invalid value MUST be treated as a connection error of type
PROTOCOL_VIOLATION.
A variable-length integer representing the value to which the
endpoint requests the peer update its "max_ack_delay"
(Section 18.2 of QUIC-TRANSPORT).  The value of this field is in
microseconds, unlike the 'max_ack_delay' transport parameter,
which is in milliseconds.  Sending a value smaller than the
"min_ack_delay" advertised by the peer is invalid.  Receipt of an
invalid value MUST be treated as a connection error of type
PROTOCOL_VIOLATION.  On receiving a valid value in this field, the
endpoint MUST update its "max_ack_delay" to the value provided by
the peer.
An endpoint will have committed a "max_ack_delay" value to the peer,
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
proposed by the peer in the Request Max Ack Delay field.
Since the last acknowledgement was sent, the number of received
ack-eliciting packets is greater than or equal to the recorded
"Ack-Eliciting Threshold".
Since the last acknowledgement was sent, the number of received
ack-eliciting packets is greater than the "Ack-Eliciting
Threshold".