Change:
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 <del> acknowledged in an ACK frame.  When this happens, and if verification </del> <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. <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> <ins> 13.3.2.3. </ins> <del> Upon successful verification, an endpoint continues to set ECT </del> <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 <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> <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.

Discussion:
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.