Original text:
7.6. <del> When a sender establishes loss of all ack-eliciting packets sent over a long enough duration, the network is considered to be experiencing persistent congestion. </del>  7.6.1. 7.6.2. <del> A sender establishes persistent congestion on receiving an </del>  acknowledgement if at least two ack-eliciting packets are declared lost, and: <del> all packets, across all packet number spaces, sent between these two send times are declared lost; </del>  the duration between the send times of these two packets exceeds the persistent congestion duration (pc-duration); and a prior RTT sample existed when both packets were sent.  The persistent congestion period SHOULD NOT start until there is at least one RTT sample.  Before the first RTT sample, a sender arms its PTO timer based on the initial RTT (pto-handshake), which could be

Reviewer comments:
Removes the word ack-eliciting in the descriptive text to persistent congestion. It also contains minor text changes in the following of that section.
I'm taking the suggested changes and this PR. Thanks, NAME !
On the mailing list Timo Völker asked some questions about persistent congestion and why it was only applicable to in-flight packets. During the explanation, I realized that it should probably be ack-eliciting packets, not in-flight. UPDATE: It already is ack-eliciting in all but one spot. I wrote PR to fix that one spot.
To have the context, I quote your explanation. I think ack-eliciting makes more sense here than in-flight. At least, I understand that for the persistent congestion detection the first and the last packet need to be ack-eliciting. But why does this have to be true for packets sent between these two ack-eliciting packets? Here is an example for the edge case. The loss of three out of 50 packets let the sender consider this a persistent congestion. In general, I don't see a real issue here. But, I would like to understand why it is helpful to ignore the fact that non-ack-eliciting packets, sent between two lost ack-eliciting packets, have been acknowledged.
This absolutely should not be in flight packets. This may not cause a major issue as it stands but it is not technically correct.
The text is largely correct(ack-eliciting, not in-flight) already, based on my reading. Unfortunately, the very first description is incorrect, which is potentially confusing, so see
Looking good, one further suggestion.

Revised text:
7.6.  <ins> When a sender establishes loss of all packets sent over a long enough duration, the network is considered to be experiencing persistent congestion. </ins> 7.6.1. 7.6.2.  <ins> A sender establishes persistent congestion after the receipt of an </ins> acknowledgement if at least two ack-eliciting packets are declared lost, and:  <ins> all packets, across all packet number spaces, sent between the send times of two ack-eliciting packets are declared lost; </ins> the duration between the send times of these two packets exceeds the persistent congestion duration (pc-duration); and a prior RTT sample existed when both packets were sent. <ins> These two packets MUST be ack-eliciting, since a receiver is required to acknowledge only ack-eliciting packets within its maximum ack delay; see Section 13.2 of QUIC-TRANSPORT. </ins> The persistent congestion period SHOULD NOT start until there is at least one RTT sample.  Before the first RTT sample, a sender arms its PTO timer based on the initial RTT (pto-handshake), which could be