Code change:
This turned out to be fairly simple, but I think that it's worth writing down. I don't have concrete recommendations, but I could add them if people thought that they help. See the commented-out bit.
Thanks both for the reviews, I've taken some of the suggestions and moved this to the appendix.
After discussing with editors, we agreed that this was a reasonable interpretation of existing text. We do agree that it would be worth discussing Mirja's views on ECN reliability and possibly changing the algorithm to reflect that, but it would be a design change.
In , NAME suggested that a different algorithm might be better to recommend enabling ECN and only disabling it if a failure is detected. That algorithm adopts the same posture as the draft: that ECN is optional and that endpoints are permitted to be cautious in enabling it. If we want to adopt the view that ECN works and endpoints are required to use it unless it breaks, that's a bigger change. I open this issue, while being aware that this is re-opening something we discussed and agreed previously, without there being new information to present. Chairs, if you do think we should discuss this, it's a design issue.
I would not be in favor of reopening this.
Just to clarify the proposal was that if you decide to enable ECN, you should just do it and only disable if you notice a failure, instead of having the more complicated probing logic that we have right now (in the appendix I think)
The shows that out of 14 implementations doing active tests, only 3 demonstrate ECN support. No ill will, but major places like AWS or the Windows OS do not support ECN, so it is not clear what more text in the spec would change.
This is just about this one paragraph: The concrete proposal would be to remove this paragraph.
Discussed in ZRH. Proposed resolution is to close with no action.
I will make a proposal for an editorial PR for the paragraph mention above to make it sounds less scary that this risk exists.
ECN-capable is not a constant condition, but we don't have any algorithm that governs it. I don't think that we can just say "mark until validation of ECN counts fails". Maybe the following algorithm is OK: When starting a new path: set ECN state to "testing" after N packets or M round trips, set ECN state to "unknown" on every ACK, check ECN counts if ECN validation fails set ECN state to "failed". if ECN validation passes and ECN state is "uncertain", set it to "capable". when sending packets, mark with ECT(0) if state is "testing" or "capable" (I know that this is unchanged text, but I just realized that we could be clearer.) Gorry pointed out that we can add an extra thing: if a path is marked as "failed", you MAY choose to occasionally switch back to "testing". Mirja pointed out that we need to deal with bleaching more than we need to worry about black holes. We should negotiate that. Originally posted by NAME in URL
I also would suggest one more intro sentence could please some to say "When a path supports ECN, this enables ECN marking and uses ECN for a new path" - to effectively say that the validation is about how to detect and react to problems with a path that is not ECN capable.
Discussed in Cupertino.
Presumably this is just another section in Section 13.4? That would be useful.

Related discussion:
text: 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 <del> on active connection migration to a new path. </del> <ins> on active connection migration to a new path.  ecn-alg describes one possible algorithm for testing paths for ECN support. </ins> Even if an endpoint does not use ECN markings on packets it transmits, the endpoint MUST provide feedback about ECN markings