Change:
13.2.1. <ins> Every packet SHOULD be acknowledged at least once, and ack-eliciting packets MUST be acknowledged at least once within the maximum ack delay.  An endpoint communicates its maximum delay using the max_ack_delay transport parameter; see transport-parameter- definitions.  max_ack_delay declares an explicit contract: an endpoint promises to never intentionally delay acknowledgments of an ack-eliciting packet by more than the indicated value.  If it does, any excess accrues to the RTT estimate and could result in spurious or delayed retransmissions from the peer.  For Initial and Handshake packets, a max_ack_delay of 0 is used.  The sender uses the receiver's "max_ack_delay" value in determining timeouts for timer- based retransmission, as detailed in Section 5.2.1 of QUIC-RECOVERY. </ins> An ACK frame SHOULD be generated for at least every second ack- eliciting packet.  This recommendation is in keeping with standard practice for TCP RFC5681. <del> A receiver's delayed acknowledgment timer SHOULD NOT exceed the current RTT estimate or the value it indicates in the "max_ack_delay" transport parameter.  This ensures an acknowledgment is sent at least once per RTT when packets needing acknowledgement are received.  The sender can use the receiver's "max_ack_delay" value in determining timeouts for timer-based retransmission. </del> In order to assist loss detection at the sender, an endpoint SHOULD send an ACK frame immediately on receiving an ack-eliciting packet that is out of order.  The endpoint MAY continue sending ACK frames immediately on each subsequently received packet, but the endpoint <del> SHOULD return to acknowledging every other packet after a period of </del> <ins> SHOULD return to acknowledging every other packet within a period of </ins> 1/8 x RTT, unless more ack-eliciting packets are received out of order.  If every subsequent ack-eliciting packet arrives out of order, then an ACK frame SHOULD be sent immediately for every

Discussion:
The editors assumed this was true, but I think it's worth stating this as a MUST to ensure clarity.
I'm a bit worried this misses the point. Ack-eliciting packets should be acknowledged yes, but so should non-ack-eliciting packets. By stating that ack-eliciting packets should be ACK'ed at least once, it is implied that this is not the case for other packets. This may be correct but not necessarily clear. For example for long transmissions where the peer does nothing but sending ACKs, not all of those ACKs will necessarily have to be ACK'ed. But what is the guiding principle for that? And, since you in this case are sending lots of ACK eliciting packets, you can easily ACK all the peers ACK's. So when would you not want to do that? A special case that could deadlock - e.g. too many ACKs to fit in a packet?
Also, when ACKs packets don't fit in packets, this would also hold for ACK'ing ack-eliciting packets. So you could end up having to not ACK'ing some packets and induce loss. Requiring an ACK for all packets would be problematic. I'm not sure we want that. The result could be very hard to implement while the practical benefit would be small: sending multiple ACK packets with different content due to overflow.
I just synced to master and now this seems to be an editorial change, at least to me. That being said, PTAL at the text and tell me if there are any other changes I should make.
It appears that the spec doesn't actually require sending ACKs for every ACK-eliciting packet. This could lead to a perverse implementation just not ACKing things with obvious problems.
Discussed in Cupertino. Add normative language to prescribe what should be ACKed. Reclassifying as Editorial (adds normative language, but we have consensus on that).
Generally looks good, but I don't think we can have an absolute requirement that every ack-eliciting packet is acknowledged.