Original text:
RFC8257 or other congestion controllers that mark more frequently than classic ECN RFC3168.  7.3. For performance reasons, an endpoint can receive incoming packets

Reviewer comments:
We have normative text for Ignore Order, but none for Ignore CE. SHOULD NOT use with ECN(1) marking per L4S or DCTCP.
First, in section 4 I think the wrong section is referenced: Ignore CE: A 1-bit field representing a boolean truth value. This field is set to true by an endpoint that does not wish to receive an immediate acknowledgement when the peer receives CE-marked packets (Section 7.1). 0 represents 'false' and 1 represents 'true'. That should be Section 7.2 should it not? Please use symbolic links to avoid this issue. Comparing 7.1 and 7.2 I think there is inconsistency in structure. I think that 7.2 needs the corresponding link back to the ACK_FREQUENCY frame feature for controlling this behavior.
This is a symbolic link in the current editor's copy. I added a normative statement about Ignore CE in 7.2 in , which I believe is correct. I used a SHOULD, but it could be a MUST. It appears there were no existing normative statements about Ignore CE.
To me, Ignore CE for arbitrary numbers of packets, does seem like it can be quite dangerous to the proper operation of ECN in the way understood for ECT(1), unless this is somehow constrained on the number of packets that are received. ECN is intended to be an early reaction to congestion and this delays a CC reaction, and if it is for a lot of packets I think that's likely an issue, although a few packets would likely be fine !!!! I think this needs CC safety guidance in the text, even if the guidance differs for ECT(0).
I agree with this but probably the sender wouldn't use both Ignore-CE and L4S at the same time. Hopefully, folks will understand that from reading the draft. :-)
Hmmmm ... If this really only applies to sender setting ECT(0) let's say that - I can see it works in relation to ABE or RFC3168 reactions, and not L4S. Explaining this, the impact would then be clear when (?) ECT(0) usage is finally deprecated. Likely a PR can achieve this.
We can say that "The Ignore-CE bit SHOULD NOT be set if ECT(1) is negotiated."
Added to the existing PR about Ignore CE: URL
Actually to me it's really not clear why the Ignore CE is useful at all as you always want at least the first CE (in a row or in a RTT) as fast as possible. E.g. for Accurate ECN this is explicitly specified in Section 3.2.2.5.1 (URL). I think that's where this discussion belong and not in this draft, given I don't see a reason for a sender side signal as I don't think this is actually congestion control dependent - all congestion control algorithm should react to CE marking and do so as quickly as possible.
This was discussed in detail at URL I do agree with NAME that I am not convinced with the use of this field and why should a sender be allowed to set this.
Just one nit

Revised text:
RFC8257 or other congestion controllers that mark more frequently than classic ECN RFC3168. <ins> If the most recent ACK_FREQUENCY frame an endpoint has received from the peer has an "Ignore CE" value of "true" (0x01), receipt of a CE marked packet SHOULD NOT cause an endpoint to send an immediate acknowledgement.  The endpoint still sends an immediate acknowledgement if it would have for a non CE marked packet.  If an immediate acknowledgement is not sent, the CE marks are reported in the next acknowledgement. The Ignore-CE bit SHOULD NOT be set if the sender sets ECT(1) in its outgoing packets, such as with L4S, because it delays the congestion controller's ability to quickly respond to congestion. </ins> 7.3. For performance reasons, an endpoint can receive incoming packets