RFC editor comments, Recovery Section 8

rfc9002.md

@@ -1158,7 +1158,7 @@ after periods of under-utilization, such as those proposed for TCP in
 Loss detection and congestion control fundamentally involve consumption of
 signals, such as delay, loss, and ECN markings, from unauthenticated
 entities. An attacker can cause endpoints to reduce their sending rate by
-manipulating these signals; by dropping packets, by altering path delay
+manipulating these signals: by dropping packets, by altering path delay
 strategically, or by changing ECN codepoints.
 
 ## Traffic Analysis
@@ -1178,17 +1178,17 @@ increase their send rate.  This increase could result in congestion and loss.
 A sender can detect suppression of reports by marking occasional packets that it
 sends with an ECN-CE marking. If a packet sent with an ECN-CE marking is not
 reported as having been CE marked when the packet is acknowledged, then the
-sender can disable ECN for that path by not setting ECT codepoints in subsequent
-packets sent on that path {{!RFC3168}}.
+sender can disable ECN for that path by not setting ECN-Capable Transport (ECT)
+codepoints in subsequent packets sent on that path {{!RFC3168}}.
 
 Reporting additional ECN-CE markings will cause a sender to reduce their sending
 rate, which is similar in effect to advertising reduced connection flow control
 limits and so no advantage is gained by doing so.
 
 Endpoints choose the congestion controller that they use. Congestion controllers
 respond to reports of ECN-CE by reducing their rate, but the response may vary.
-Markings can be treated as equivalent to loss ({{!RFC3168}}), but other
-responses can be specified, such as ({{?RFC8511}}) or ({{?RFC8311}}).
+Markings can be treated as equivalent to loss {{!RFC3168}}, but other
+responses can be specified, such as {{?RFC8511}} or {{?RFC8311}}.
 
 
 --- back