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

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.