diff --git a/rfc9002.md b/rfc9002.md
index c1805ece82..6534da7725 100644
--- a/rfc9002.md
+++ b/rfc9002.md
@@ -232,9 +232,10 @@ more accurate round-trip time estimate; see {{Section 13.2 of QUIC-TRANSPORT}}.
 
 ## Probe Timeout Replaces RTO and TLP
 
-QUIC uses a probe timeout (PTO; see {{pto}}), with a timer based on TCP's RTO
-computation; see {{?RFC6297}}.  QUIC's PTO includes the peer's maximum expected
-acknowledgment delay instead of using a fixed minimum timeout.
+QUIC uses a probe timeout (PTO; see {{pto}}), with a timer based on TCP's
+retransmission timeout (RTO) computation; see {{?RFC6298}}.  QUIC's PTO includes
+the peer's maximum expected acknowledgment delay instead of using a fixed
+minimum timeout.
 
 Similar to the RACK-TLP loss detection algorithm for TCP
 ({{?RACK=I-D.ietf-tcpm-rack}}), QUIC does not collapse the congestion window
@@ -493,7 +494,7 @@ packet and time thresholds provide some tolerance for packet reordering.
 Spuriously declaring packets as lost leads to unnecessary retransmissions and
 may result in degraded performance due to the actions of the congestion
 controller upon detecting loss.  Implementations can detect spurious
-retransmissions and increase the reordering threshold in packets or time to
+retransmissions and increase the packet or time reordering threshold to
 reduce future spurious retransmissions and loss events. Implementations with
 adaptive time thresholds MAY choose to start with smaller initial reordering
 thresholds to minimize recovery latency.
@@ -654,9 +655,9 @@ PATH_RESPONSE to set the initial RTT (see kInitialRtt in
 {{constants-of-interest}}) for a new path, but the delay SHOULD NOT be
 considered an RTT sample.
 
-Initial packets and Handshake packets could be never acknowledged, but they are
-removed from bytes in flight when the Initial and Handshake keys are discarded,
-as described below in {{discarding-packets}}. When Initial or Handshake keys are
+When the Initial keys and Handshake keys are discarded ({{discarding-packets}}),
+any Initial packets and Handshake packets can no longer be acknowledged, so
+they are removed from bytes in flight. When Initial or Handshake keys are
 discarded, the PTO and loss detection timers MUST be reset, because discarding
 keys indicates forward progress and the loss detection timer might have been set
 for a now discarded packet number space.
@@ -680,7 +681,7 @@ validate the client's address.
 Since the server could be blocked until more datagrams are received from the
 client, it is the client's responsibility to send packets to unblock the server
 until it is certain that the server has finished its address validation (see
-{{Section 8 of QUIC-TRANSPORT}}). That is, the client MUST set the probe timer
+{{Section 8 of QUIC-TRANSPORT}}). That is, the client MUST set the PTO timer
 if the client has not received an acknowledgment for any of its Handshake
 packets and the handshake is not confirmed (see {{Section 4.1.2 of QUIC-TLS}}),
 even if there are no packets in flight. When the PTO fires, the client MUST
@@ -797,10 +798,11 @@ 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.  However, Initial and Handshake secrets are
-discarded as soon as handshake and 1-RTT keys are proven to be available to both
-client and server; see {{Section 4.9.1 of QUIC-TLS}}.
+It is expected that keys are discarded at some time after the packets
+encrypted with them are either acknowledged or declared lost. However, Initial
+and Handshake secrets are discarded as soon as handshake and 1-RTT keys are
+proven to be available to both client and server;
+see {{Section 4.9.1 of QUIC-TLS}}.
 
 # Congestion Control {#congestion-control}
 
@@ -1136,10 +1138,10 @@ rate the "bucket" fills is determined by the above function.
 ## Under-utilizing the Congestion Window
 
 When bytes in flight is smaller than the congestion window and sending is not
-pacing limited, the congestion window is under-utilized.  When this occurs,
+pacing limited, the congestion window is under-utilized. This can happen due to
+insufficient application data or flow control limits. When this occurs,
 the congestion window SHOULD NOT be increased in either slow start or
-congestion avoidance. This can happen due to insufficient application data
-or flow control limits.
+congestion avoidance.
 
 A sender that paces packets (see {{pacing}}) might delay sending packets
 and not fully utilize the congestion window due to this delay. A sender