Original text:
13.3. <del> QUIC endpoints use Explicit Congestion Notification (ECN) RFC3168 to detect and respond to network congestion.  ECN allows a network node to indicate congestion in the network by setting a codepoint in the IP header of a packet instead of dropping it.  Endpoints react to </del>  congestion by reducing their sending rate in response, as described in QUIC-RECOVERY. 13.3.1. <del> On receiving a QUIC packet with an ECT or CE codepoint, an endpoint that can access the ECN codepoints from the enclosing IP packet increases the corresponding ECT(0), ECT(1), or CE count, and includes these counts in subsequent ACK frames (see processing-and-ack and frame-ack). </del>  A packet detected by a receiver as a duplicate does not affect the receiver's local ECN codepoint counts; see (security-ecn) for If an endpoint receives a QUIC packet without an ECT or CE codepoint in the IP packet header, it responds per processing-and-ack with an <del> ACK frame without increasing any ECN counts.  Similarly, if an endpoint does not have access to received ECN codepoints, it does not increase ECN counts. </del>  Coalesced packets (see packet-coalesce) mean that several packets can share the same IP header.  The ECN counter for the ECN codepoint Each endpoint independently verifies and enables use of ECN by setting the IP header ECN codepoint to ECN Capable Transport (ECT) <del> for the path from it to the 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). </del>  To verify both that a path supports ECN and the peer can provide ECN <del> feedback, an endpoint MUST set the ECT(0) codepoint in the IP header of all outgoing packets RFC8311. </del>  If an ECT codepoint set in the IP header is not corrupted by a network device, then a received packet contains either the codepoint or more ACK Blocks.  ACK Blocks are ranges of acknowledged packets. If the frame type is 0x03, ACK frames also contain the sum of QUIC packets with associated ECN marks received on the connection up until <del> this point. </del>  QUIC acknowledgements are irrevocable.  Once acknowledged, a packet remains acknowledged, even if it does not appear in a future ACK

Reviewer comments:
Implementations are free to enable sending or not. 2, Implementations MAY read the ECN code points if they can and send ECN ACKs. Implementations MUST accept the 0x03 ACK type and if they are sending ECN SHOULD use the ECN section. I recognize that some people want to have stronger language here, based on this discussion I think this is where we are. I'll defer to the chairs to judge whether more is needed here and can change the PR as required.
I took the discussion to be "MAY" but obviously this is easily changed if the chairs judge consensus otherwise.

Revised text:
13.3.  <ins> QUIC endpoints can use Explicit Congestion Notification (ECN) RFC3168 to detect and respond to network congestion.  ECN allows a network node to indicate congestion in the network by setting a codepoint in the IP header of a packet instead of dropping it.  Endpoints react to </ins> congestion by reducing their sending rate in response, as described in QUIC-RECOVERY. 13.3.1.  <ins> On receiving a QUIC packet with an ECT or CE codepoint, an ECN- enabled endpoint that can access the ECN codepoints from the enclosing IP packet increases the corresponding ECT(0), ECT(1), or CE count, and includes these counts in subsequent ACK frames (see processing-and-ack and frame-ack).  Note that this requires being able to read the ECN codepoints from the enclosing IP packet, which is not possible on all platforms. </ins> A packet detected by a receiver as a duplicate does not affect the receiver's local ECN codepoint counts; see (security-ecn) for If an endpoint receives a QUIC packet without an ECT or CE codepoint in the IP packet header, it responds per processing-and-ack with an  <ins> ACK frame without increasing any ECN counts.  if an endpoint does not implement ECN support or does not have access to received ECN codepoints, it does not increase ECN counts. </ins> Coalesced packets (see packet-coalesce) mean that several packets can share the same IP header.  The ECN counter for the ECN codepoint Each endpoint independently verifies and enables use of ECN by setting the IP header ECN codepoint to ECN Capable Transport (ECT)  <ins> for the path from it to the other peer.  Even if not setting ECN codepoints on packets it transmits, the endpoint SHOULD provide feedback about ECN markings received (if accessible). </ins> To verify both that a path supports ECN and the peer can provide ECN  <ins> feedback, an endpoint sets the ECT(0) codepoint in the IP header of all outgoing packets RFC8311. </ins> If an ECT codepoint set in the IP header is not corrupted by a network device, then a received packet contains either the codepoint or more ACK Blocks.  ACK Blocks are ranges of acknowledged packets. If the frame type is 0x03, ACK frames also contain the sum of QUIC packets with associated ECN marks received on the connection up until  <ins> this point.  QUIC implementations MUST properly handle both types and, if they have enabled ECN for packets they send, they SHOULD use the information in the ECN section to manage their congestion state. </ins> QUIC acknowledgements are irrevocable.  Once acknowledged, a packet remains acknowledged, even if it does not appear in a future ACK