Original text:
send a PING or other small ack-eliciting frame occasionally, such as once per round trip, to elicit an ACK from the peer. <del> A receiver MUST NOT send an ack-eliciting frame in all packets that would otherwise be non-ack-eliciting, to avoid an infinite feedback loop of acknowledgements. </del>  <del> 13.2.6. </del>  An endpoint measures the delays intentionally introduced between the time the packet with the largest packet number is received and the

Reviewer comments:
It's no longer normative and it's in a single section. I only moved text so far, and not as far as NAME suggested. I can go farther here or in a follow-up PR.
NAME I would like to merge this. WDYT?
Can we merge this soon. I'm worried about it developing conflicts.
Yep, NAME lost the chance to fix the PR. We are - of course - still open for editorial improvements in the form of new pull requests though.
calls them "exemplary" but 13.2.4 has MUST in it.
For reference, this refers to and in the editor's copy. I'm in favour of striking the exemplary note and saying that while the recovery draft is advisory, this document depends on implementations following something like what is recommended.
The specific MUSTs aren't really about the ACK algorithm per se, but about state endpoints will have to maintain for other reasons that are typically folded into your loss recovery code. If an implementation is unable to do duplicate detection for a packet number range, it MUST fail toward rejecting all packets, not toward accepting potential duplicates. An implementation must track the greatest packet number ever received, for use in recovering future packet numbers. In fact, the first requirement is discussed in 12.3 and could probably be dropped here. The second isn't actually called out (MUST) in 17.1, but could easily be moved there.
I think I'm inclined towards reorganizing the text and putting all the 'exemplary' parts into one section(ie: "Limiting ACK Ranges") and moving the normative text either into "Managing ACK Ranges" or elsewhere in the draft.
I thought I could clean this up fairly quickly, but I think a fair number of paragraphs need to move, including some of NAME suggestions. I'm happy to try to improve this in a few days if no one else has beaten me to it.
Anyone want to help NAME out and take this on?
Sorry about dropping this one. I'm fine with it, and happy to make editorials one later.Thanks Ian. When you lay it out like this, it seems so obvious. I checked that we don't have citations for {{ack-tracking}}, so this works nicely. If you care about the "MAY", then we can fix that in another PR.

Revised text:
send a PING or other small ack-eliciting frame occasionally, such as once per round trip, to elicit an ACK from the peer.  <ins> In cases without ACK frame loss, this algorithm allows for a minimum of 1 RTT of reordering.  In cases with ACK frame loss and reordering, this approach does not guarantee that every acknowledgement is seen by the sender before it is no longer included in the ACK frame. Packets could be received out of order and all subsequent ACK frames containing them could be lost.  In this case, the loss recovery algorithm could cause spurious retransmissions, but the sender will continue making forward progress. </ins>  <ins> 13.2.5. </ins> An endpoint measures the delays intentionally introduced between the time the packet with the largest packet number is received and the