Original text:
protocol. An endpoint can verify support for Explicit Congestion Notification <del> (ECN) in the first packets it sends, as described in ecn- verification. </del>  The CRYPTO frame can be sent in different packet number spaces.  The sequence numbers used by CRYPTO frames to ensure ordered delivery of ECN marking and the peer is able to access the ECN codepoint in the IP header.  A network path does not support ECN if ECN marked packets get dropped or ECN markings are rewritten on the path.  An endpoint <del> verifies the path, both during connection establishment and when migrating to a new path (see migration). </del>  13.3.1. 13.3.2. <del> Each endpoint independently verifies and enables use of ECN by setting the IP header ECN codepoint to ECN Capable Transport (ECT) 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). To verify both that a path supports ECN and the peer can provide ECN feedback, an endpoint sets 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. If a QUIC packet sent with an ECT codepoint is newly acknowledged by the peer in an ACK frame without ECN feedback, the endpoint stops setting ECT codepoints in subsequent IP packets, with the expectation that either the network path or the peer no longer supports ECN. Network devices that corrupt or apply non-standard ECN markings might result in reduced throughput or other undesirable side-effects.  To reduce this risk, an endpoint uses the following steps to verify the counts it receives in an ACK frame. The total increase in ECT(0), ECT(1), and CE counts MUST be no smaller than the total number of QUIC packets sent with an ECT codepoint that are newly acknowledged in this ACK frame.  This step detects any network remarking from ECT(0), ECT(1), or CE codepoints to Not-ECT. </del>  Any increase in either ECT(0) or ECT(1) counts, plus any increase in the CE count, MUST be no smaller than the number of packets acknowledged in this ACK frame.  This step detects any erroneous network remarking from ECT(0) to ECT(1) (or vice versa).  An endpoint could miss acknowledgements for a packet when ACK frames are lost.  It is therefore possible for the total increase in ECT(0), ECT(1), and CE counts to be greater than the number of packets <del> acknowledged in an ACK frame.  When this happens, and if verification </del>  succeeds, the local reference counts MUST be increased to match the counts in the ACK frame. <del> Processing counts out of order can result in verification failure. An endpoint SHOULD NOT perform this verification if the ACK frame is received in a packet with packet number lower than a previously received ACK frame.  Verifying based on ACK frames that arrive out of order can result in disabling ECN unnecessarily. </del>  <del> Upon successful verification, an endpoint continues to set ECT </del>  codepoints in subsequent packets with the expectation that the path <del> is ECN-capable. If verification fails, then the endpoint ceases setting ECT codepoints in subsequent IP packets with the expectation that either the network path or the peer does not support ECN. If an endpoint sets ECT codepoints on outgoing IP packets and encounters a retransmission timeout due to the absence of acknowledgments from the peer (see QUIC-RECOVERY), or if an endpoint has reason to believe that an element on the network path might be corrupting ECN codepoints, the endpoint MAY cease setting ECT codepoints in subsequent packets.  Doing so allows the connection to be resilient to network elements that corrupt ECN codepoints in the IP header or drop packets with ECT or CE codepoints in the IP header. </del>  14.

Reviewer comments:
Cleans up ECN verification text. .
I've taken in all feedback and reworked this section a fair bit. It's structured differently now, PTAL.
The wall of commits is a little disconcerting there.
I think this is ready. Unless someone disagrees, I'll mark the corresponding issue as proposal-ready tomorrow.
I don't think that we'll find new objections. I marked it myself.
Section 13.3.2 "ECN Verification" Although I understand the intent here, retransmission timeouts, as a term, don't exist anymore in QUIC except during handshakes. Disabling ECN after any PTO firing seems a bit extreme, so I'd like to see a better recommendation here, which covers both handshakes and short headers.
Fixing the naming(retransmission timeout to probe timeout) is trivial, but I'm not sure what to recommend here for when to disable ECN. Also, probe timeouts don't occur until the handshake is complete, is that a problem? One idea that's somewhat in keeping with RFC3168 would be to disable ECN on crypto handshake timeouts and probe timeouts, and if the un-marked packets get through and the marked do not, disable ECN. But even that is subject to random loss and I believe is likely to spuriously trigger. We could disable ECN temporarily on only the second timeout, to reduce the chance of spurious disabling? RFC8311(URL) says we can do something different from 3168 if we document it, but doesn't specify what. Is there some useful RFC I can cite that I haven't found, or are we on our own in designing a mechanism here?
NAME I reclassified this as design, because it's not just the name update. If we decide to just fix the name, then we can change it back. Correct me if I'm wrong.
How about probing ECN on even packet numbers for the first N packets before making a decision, where N is tunable.
I believe what the text was actually meant to say was that if you set the ECT code point and you loose ALL packets with the code point set, you MAY disable it.
What NAME says makes sense. We don't need to document a full algorithm here, but the proposed text works for me.
So the intention here is that if you hit an ECN blackhole that you disable ECT marking the sent packet in a timely fashion to minimize the impact on connection establishment. And I don't think a single sender behavior is necessary.
NAME mentioned that this should be triggered on persistent congestion.
Agreed in London for NAME to write a PR.
Just to clarify: RFC8311 permits other uses that are specified by an RFC: i.e., currently this is RFC8511, and the expected RFC to be published by the L4S work items in TSVWG (expecting to be Lc'ed later in 2019).
There seems two things: • What to do during handshake (maybe is described in transport) • Disabling after handshake which I think is in the loss/recovery draft, rather than transport? - I thought I heard Jana argue that this reaction depends on the loss/marking observations on the path - which I would agree with.
NAME is that ready for a consensus call?
There are a lot of open comments on the PR, so I think not yet?
NAME Not yet, the PR needs some work.

Revised text:
protocol. An endpoint can verify support for Explicit Congestion Notification  <ins> (ECN) in the first packets it sends, as described in ecn-validation. </ins> The CRYPTO frame can be sent in different packet number spaces.  The sequence numbers used by CRYPTO frames to ensure ordered delivery of ECN marking and the peer is able to access the ECN codepoint in the IP header.  A network path does not support ECN if ECN marked packets get dropped or ECN markings are rewritten on the path.  An endpoint  <ins> validates the use of ECN on the path, both during connection establishment and when migrating to a new path (migration). </ins> 13.3.1. 13.3.2.  <ins> It is possible for faulty network devices to corrupt or erroneously drop packets with ECN markings.  To provide robust connectivity in the presence of such devices, each endpoint independently validates ECN counts and disables ECN if errors are detected. Endpoints validate ECN for packets sent on each network path independently.  An endpoint thus validates ECN on new connection establishment, when switching to a new server preferred address, and on active connection migration to a new path. Even if an endpoint does not use ECN markings on packets it transmits, the endpoint MUST provide feedback about ECN markings received from the peer if they are accessible.  Failing to report ECN counts will cause the peer to disable ECN marking. 13.3.2.1. To start ECN validation, an endpoint SHOULD do the following when sending packets on a new path to a peer: Set the ECT(0) codepoint in the IP header of early outgoing packets sent on a new path to the peer RFC8311. If all packets that were sent with the ECT(0) codepoint are eventually deemed lost QUIC-RECOVERY, validation is deemed to have failed. To reduce the chances of misinterpreting congestive loss as packets dropped by a faulty network element, an endpoint could set the ECT(0) codepoint in the first ten outgoing packets on a path, or for a period of three RTTs, whichever occurs first. 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. 13.3.2.2. An endpoint that sets ECT(0) or ECT(1) codepoints on packets it transmits MUST use the following steps on receiving an ACK frame to validate ECN. If this ACK frame newly acknowledges a packet that the endpoint sent with either ECT(0) or ECT(1) codepoints set, and if no ECN feedback is present in the ACK frame, validation fails.  This step protects against both a network element that zeroes out ECN bits and a peer that is unable to access ECN markings, since the peer could respond without ECN feedback in these cases. For validation to succeed, the total increase in ECT(0), ECT(1), and CE counts MUST be no smaller than the total number of QUIC packets sent with an ECT codepoint that are newly acknowledged in this ACK frame.  This step detects any network remarking from ECT(0), ECT(1), or CE codepoints to Not-ECT. </ins> Any increase in either ECT(0) or ECT(1) counts, plus any increase in the CE count, MUST be no smaller than the number of packets acknowledged in this ACK frame.  This step detects any erroneous network remarking from ECT(0) to ECT(1) (or vice versa). <ins> Processing ECN counts out of order can result in validation failure. An endpoint SHOULD NOT perform this validation if this ACK frame does not advance the largest packet number acknowledged in this connection. </ins> An endpoint could miss acknowledgements for a packet when ACK frames are lost.  It is therefore possible for the total increase in ECT(0), ECT(1), and CE counts to be greater than the number of packets  <ins> acknowledged in an ACK frame.  When this happens, and if validation </ins> succeeds, the local reference counts MUST be increased to match the counts in the ACK frame.  <ins> 13.3.2.3. </ins>  <ins> If validation fails, then the endpoint stops sending ECN markings in subsequent IP packets with the expectation that either the network path or the peer does not support ECN. Upon successful validation, an endpoint can continue to set ECT </ins> codepoints in subsequent packets with the expectation that the path  <ins> is ECN-capable.  Network routing and path elements can change mid- connection however; an endpoint MUST disable ECN if validation fails at any point in the connection. Even if validation fails, an endpoint MAY revalidate ECN on the same path at any later time in the connection. </ins> 14.