Change:
Packets are acknowledged, though packet numbers are communicated to acknowledge them.
One high-level comment. I believe the intent was to move most of the text about sending ACKs from recovery to transport. Also, if we defined ack-eliciting in transport, I think this PR and some other text would read more clearly. I can do that in a follow up PR.
Thanks for cleaning this up. One more TODO down.

Discussion:
13.1.1. <del> To avoid creating an indefinite feedback loop, an endpoint MUST NOT send an ACK frame in response to a packet containing only ACK or PADDING frames, even if there are packet gaps which precede the received packet.  The endpoint MUST however acknowledge packets containing only ACK or PADDING frames when sending ACK frames in response to other packets. </del> <ins> An endpoint MUST NOT send more than one packet containing only an ACK frame per received packet that contains frames other than ACK and PADDING frames.  An endpoint MUST NOT send a packet containing only an ACK frame in response to a packet containing only ACK or PADDING frames, even if there are packet gaps which precede the received packet.  This prevents an indefinite feedback loop of ACKs.  The endpoint MUST however acknowledge packets containing only ACK or PADDING frames when sending ACK frames in response to other packets. </ins> Packets containing PADDING frames are considered to be in flight for congestion control purposes QUIC-RECOVERY.  Sending only PADDING

that other frames are sent in addition to PADDING frames to elicit acknowledgments from the receiver. <del> An endpoint MUST NOT send more than one packet containing only an ACK frame per received packet that contains frames other than ACK and PADDING frames. </del> The 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

Strategies and implications of the frequency of generating acknowledgments are discussed in more detail in QUIC-RECOVERY. <del> To limit the ranges of acknowledged packet numbers to those that have not yet been received by the sender, the receiver SHOULD track which ACK frames have been acknowledged by its peer.  The receiver SHOULD exclude already acknowledged packets from future ACK frames whenever these packets would unnecessarily contribute to the ACK frame size. </del> <ins> To limit ACK Ranges (see ack-ranges) to those that have not yet been received by the sender, the receiver SHOULD track which ACK frames have been acknowledged by its peer.  The receiver SHOULD exclude already acknowledged packets from future ACK frames whenever these packets would unnecessarily contribute to the ACK frame size. </ins> Because ACK frames are not sent in response to ACK-only packets, a receiver that is only sending ACK frames will only receive

packets preceding the Largest Acknowledged that are being acknowledged.  The First ACK Range is encoded as an ACK Range (see ack-ranges) starting from the Largest Acknowledged.  That is, the <del> smallest packet number included in the range is determined by </del> <ins> smallest packet acknowledged in the range is determined by </ins> subtracting the First ACK Range value from the Largest Acknowledged. <del> Contains additional ranges of packet numbers which are alternately not acknowledged (Gap) and acknowledged (ACK Range), see ack- ranges. </del> <ins> Contains additional ranges of packets which are alternately not acknowledged (Gap) and acknowledged (ACK Range), see ack-ranges. </ins> The three ECN Counts, see ack-ecn-counts.

packet number for the range, the smallest value is determined by the formula: <del> An ACK Range acknowledges all packet numbers between the smallest packet number and the largest, inclusive. </del> <ins> An ACK Range acknowledges all packets between the smallest packet number and the largest, inclusive. </ins> The largest value for an ACK Range is determined by cumulatively subtracting the size of all preceding ACK Ranges and Gaps.