Change:
To reduce the chances of misinterpreting congestive loss as packets dropped by a faulty network element, an endpoint could set the ECT(0) <del> codepoint in the first ten outgoing packets on a path, or for a </del> <ins> codepoint for only the first ten outgoing packets on a path, or for a </ins> period of three RTTs, whichever occurs first. Implementations MAY experiment with and use other strategies for use

Discussion:
The current text doesn't really suggest that the probes stop.
Currently there is text saying: "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." At the interim there was a discussion that today it is likely safe to just make all packets with ECT as the risk of black-holing is not measurable anymore. PR proposes a text change to provide more background. In the comments there is also a link to a measurement which could be added if desired.
This issue has been extensively litigated and I don't think that there is new information that would suggest a change here. Implementations are free to assume that ECN works, but we did previously have consensus to recommend a more conservative approach.
I don't think we had consensus to recommend this and the proposed text makes clear that this is not a recommendation.
Folks who care about a change here need to prioritize progressing this issue. We're close to being able to last-call the specs, and would like this resolved in time.
So I think there might be a point to indicate the current state of affairs when it comes to black holing better. However, it doesn't really change the need for validation as the main issue to check for is actually that the receiver is capable of receiving the ECN bits which has a much higher risk of not being true. I would even argue that the reason for stop sending ECT after a sufficient number of packets that some should make it is to avoid getting an unfair advantage until you know that the code points are read and that you will get an CE mark if it occurs. So maybe the text should be changed to focus on this aspect? Even if the proposed PR is rejected there need to be a change to this sentence: "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." There is a missing "only" or something else to indicate that you are sending ECN for a while then going back to not-ECT until validation has occurred.

NAME the validation mechanism itself is there to stop marking packets as ETC when you don't get feedback for any reason. So that's already covered in the text. For this part of the text the question is if you should set all packet as ETC until validation fails or if there are additional risk which justifies a more complicated scheme where only some of the packets in the validation phase are marked as ECT.
MT's proposed editorial change in appears to clarify the intent of the current draft text. Perhaps additional context and discursive text (as proposed in Mirja's ) is more suited to the Applicability draft?
does not address this issue. This was just a side comment that came up. I think the minimum would be to replace "To reduce the chances of misinterpreting congestive loss as packets dropped by a faulty network element..." by "If there is as a concern for a certain network that all ECT-marked packets might be dropped by a faulty network element and would therefore cause a performance drop, then..." However, I would still prefer to give a bit more context than this (basically one more sentence as proposed). I don't think this fits in the applicability statement as I don't think there is any intention here to provide an interface to specify the ECN probing behaviour and therefore a "user" of QUIC, which is the audience for the applicability statement, would not know what to do about this information. If we want an interface and move this to applicability, I think the whole text should be moved there with some more discussion rather than giving a random recommendation in the base spec.
Thanks for the clarification, that makes sense. As someone not familiar with ECN and just reading the specification, I'm struggling to see what the crux of the issue is. And I would hypothesise that this is a contributing factor to it getting stalled. As an inexperienced implementer I find the current text a bit weak but I'm not sure more context helps me. If I were to distil it down I'd take the current text: 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. and simply editorialize it to
This doesn't address my point.

Today there is little to no evidence that these faulty network elements still exists. So my recommendation would be to not add any complexity by implementing these schemes. The current text makes it look like this, however, is a common problem, which is not the case, and therefore indictes that this scheme is recommended to be implemented.
Implementations have a bunch of complexity trade-offs to make. Since the text is non-normative I don't feel obliged to implement this technique. And if I understand it correctly, if I did implement this and ran it on a network path where there were no bad elements, then nothing bad will happen?
NAME I don't understand the pushback. As NAME notes, if no faulty network elements exist, the mechanism should work just fine. I think the crux of the disagreement might be that the text suggests that the default stance is test and then use, where perhaps you are arguing for use and fall back. I honestly don't think it makes much of a difference, and in the absence of overwhelming information we need to be taking the conservative stance on this spec.
I'm agreeing with the editors here. I think the PR is a useful modification, but we'd need to see stronger feedback from the WG to warrant making more changes to the current text.
The difference is that I would like to decrease unnecessary barrier to use ECN. If people are too lazy to implement this and don't understand that it is not needed, they might just disable ECN instead. If not sure what you mean by overwhelming information but we have done extensive measurements over 5 years showing that this problem doesn't exists anymore. What else are you expecting?
So far I didnt really see this issuing being coined in terms of "guidance for conservative ECN use risks low uptake of the ECN feature". If that is the core issue, then an example of overwhelming information is to see support for addressing the issue from a number of QUIC implementations that do not support ECN, and have chosen to do so because of this guidance. Since the other text around ECN seems to require per-packet-space counts, and other parts of QUIC require RTT measurement, I'm finding it difficult to see how this is a burdensome thing to implement. But I can only speak to my implementation and experience.

So last I counted there were only four stacks that even implemented the ACK-ECN frame type to report ECN marks. So even very basic support for ECN is (still) missing in most stacks, esp. the ones that are likely going to see the largest deployments. I don't think any text tweaks we could make here are going to move the needle on ECN support in QUIC. What will make a difference if a major stack implements it and reports a benefit. That will likely make other stacks follow.
Implementing this mechanism is trivial for someone implementing the rest of QUIC. It's not a lazy implementer that is causing the problem of lack of implementation, it's an unmotivated one. As NAME notes, in the absence of ACK-ECN, this doesn't even matter. I am not hearing any of the implementers complaining about the complexity of the mechanism here, so I would argue that the mechanism is not an issue.
Looks good to me.