Original text:
value to seed the RTT estimator for a subsequent connection attempt to the server. <del> 6.2.2. When packet protection keys are discarded (see Section 4.9 of QUIC- TLS), all packets that were sent with those keys can no longer be acknowledged because their acknowledgements cannot be processed anymore.  The sender MUST discard all recovery state associated with those packets and MUST remove them from the count of bytes in flight. Endpoints stop sending and receiving Initial packets once they start exchanging Handshake packets (see Section 17.2.2.1 of QUIC- TRANSPORT).  At this point, recovery state for all in-flight Initial packets is discarded. When 0-RTT is rejected, recovery state for all in-flight 0-RTT packets is discarded. If a server accepts 0-RTT, but does not buffer 0-RTT packets that arrive before Initial packets, early 0-RTT packets will be declared lost, but that is expected to be infrequent. It is expected that keys are discarded after packets encrypted with them would be acknowledged or declared lost.  Initial secrets however might be destroyed sooner, as soon as handshake keys are available (see Section 4.10 of QUIC-TLS). </del> 6.3. A Probe Timeout (PTO) triggers a probe packet when ack-eliciting data 6.4.  The majority of constants were derived from best common practices among widely deployed TCP implementations on the internet. Exceptions follow.

Reviewer comments:
Move the "Discarding Keys and Packet State" section up a level and out from underneath the Crypto Handshake Timer. This section in no way references the crypto handshake timer, so there's no reason to put it there. It's possible this should be up-leveled out of loss recovery as well? The preceding "Retry and Version Negotiation" has a similar problem, so I'd like suggestions on where to move that too.

Revised text:
value to seed the RTT estimator for a subsequent connection attempt to the server.  6.3. A Probe Timeout (PTO) triggers a probe packet when ack-eliciting data 6.4. <ins> When packet protection keys are discarded (see Section 4.9 of QUIC- TLS), all packets that were sent with those keys can no longer be acknowledged because their acknowledgements cannot be processed anymore.  The sender MUST discard all recovery state associated with those packets and MUST remove them from the count of bytes in flight. Endpoints stop sending and receiving Initial packets once they start exchanging Handshake packets (see Section 17.2.2.1 of QUIC- TRANSPORT).  At this point, recovery state for all in-flight Initial packets is discarded. When 0-RTT is rejected, recovery state for all in-flight 0-RTT packets is discarded. If a server accepts 0-RTT, but does not buffer 0-RTT packets that arrive before Initial packets, early 0-RTT packets will be declared lost, but that is expected to be infrequent. It is expected that keys are discarded after packets encrypted with them would be acknowledged or declared lost.  Initial secrets however might be destroyed sooner, as soon as handshake keys are available (see Section 4.10 of QUIC-TLS). 6.5. </ins> The majority of constants were derived from best common practices among widely deployed TCP implementations on the internet. Exceptions follow.