Original text:
read the ECN codepoints from the enclosing IP packet, which is not possible on all platforms. <del> 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 concerns. </del>  If an endpoint receives a QUIC packet without an ECT or CE codepoint in the IP packet header, it responds per generating-acks with an ACK codepoints, it does not increase ECN counts. Coalesced packets (see packet-coalesce) mean that several packets can <del> share the same IP header.  The ECN counter for the ECN codepoint </del>  received in the associated IP header are incremented once for each QUIC packet, not per enclosing IP packet or UDP datagram. codepoint for only the first ten outgoing packets on a path, or for a period of three RTTs, whichever occurs first. <del> Implementations MAY experiment with and use other strategies for use of ECN.  Other methods of probing paths for ECN support are possible, as are different marking strategies.  Implementations can also use the ECT(1) codepoint, as specified in RFC8311. </del>  13.4.2.2.

Reviewer comments:
Taking Gorry's suggestions, which seem quite reasonable.
(1) NiT: /The ECN counter for the ECN codepoint received in the associated IP header are incremented once for each QUIC packet, not per enclosing IP packet or UDP datagram./ mixed singular and plural - is this /counters/? (2) I like this phrase in the security considerations also from the point of view of how to generate transport feedback for ECT(?). Can we call this out here: /QUIC endpoints ignore the ECN codepoint field on an IP packet unless at least one QUIC packet in that IP packet is successfully processed/ (3) General experiments are not permitted in RFC8311, only using experimental RFCs. I think therefore, we should be clear in the detail here: /Implementations MAY experiment with and use other strategies for use of ECN. Other methods of probing paths for ECN support are possible, as are different marking strategies. Implementations can also use the ECT(1) codepoint, as specified in {{?RFC8311}}./ I’d propose something more like this: /Other methods of probing paths for ECN support are possible, as are different marking strategies. Implementations MAY use other methods defined in RFCs, as specified in {{?RFC8311}}. Implementations that use the ECT(1) codepoint, need to perform ECN validation using this code point./

Revised text:
read the ECN codepoints from the enclosing IP packet, which is not possible on all platforms.  <ins> An IP packet that results in no QUIC packets being processed does not increase ECN counts.  A QUIC packet detected by a receiver as a duplicate does not affect the receiver's local ECN codepoint counts; see security-ecn for relevant security concerns. </ins> If an endpoint receives a QUIC packet without an ECT or CE codepoint in the IP packet header, it responds per generating-acks with an ACK codepoints, it does not increase ECN counts. Coalesced packets (see packet-coalesce) mean that several packets can  <ins> share the same IP header.  The ECN counts for the ECN codepoint </ins> received in the associated IP header are incremented once for each QUIC packet, not per enclosing IP packet or UDP datagram. codepoint for only the first ten outgoing packets on a path, or for a period of three RTTs, whichever occurs first.  <ins> Other methods of probing paths for ECN support are possible, as are different marking strategies.  Implementations MAY use other methods defined in RFCs; see RFC8311.  Implementations that use the ECT(1) codepoint need to perform ECN validation using ECT(1) counts. </ins> 13.4.2.2.