Clarify use of the term "supports ECN"

draft-ietf-quic-transport.md

@@ -1847,18 +1847,18 @@ other peer. Even if ECN is not used on the path to the peer, the endpoint MUST
 provide feedback about ECN markings received (if accessible).
 
 To verify both that a path supports ECN and the peer can provide ECN feedback,
-an endpoint MUST set the ECT(0) codepoint in the IP header of all outgoing packets
-{{!RFC8311}}.
+an endpoint MUST set the ECT(0) codepoint in the IP header of all outgoing
+packets {{!RFC8311}}.
 
 If an ECT codepoint set in the IP header is not corrupted by a network device,
 then a received packet contains either the codepoint sent by the peer or the
 Congestion Experienced (CE) codepoint set by a network device that is
 experiencing congestion.
 
-On receiving a packet with an ECT or CE codepoint, an endpoint that can access the
-IP ECN codepoints increases the corresponding ECT(0), ECT(1), or CE count, and
-includes these counters in subsequent (see {{processing-and-ack}}) ACK_ECN frames
-(see {{frame-ack-ecn}}).
+On receiving a packet with an ECT or CE codepoint, an endpoint that can acces
+the IP ECN codepoints increases the corresponding ECT(0), ECT(1), or CE count, 
+and includes these counters in subsequent (see {{processing-and-ack}}) ACK_ECN 
+frames (see {{frame-ack-ecn}}).
 
 A packet detected by a receiver as a duplicate does not affect the receiver's
 local ECN codepoint counts; see ({{security-ecn}}) for relevant security