As you said, everything gets acked with a Reordering Threshold of 1, so technically CE only changes behavior for values greater than 1. But that's probably thinking about it in an overly clever way and we should say zero or state it differently.

No! ack-eliciting-threshold = 0 means everything gets acked! 1 means we skip packets.

So I think this is the current literal interpretation of the draft:

• ack-eliciting-threshold = 0: ack every packet, the CE marking is neither here nor there
• ack-eliciting-threshold = 1: per RFC 9000, SHOULD ack any CE packet, period.
• ack-eliciting-threshold > 1: per the draft, SHOULD ack the first CE only.

So the main question, is this the intent?

If not the intent (i.e. the actual intent is to ack the first CE only, even when threshold=1), then s/larger than 1/larger than 0, and we're done.

If it is the intent, a sentence like "When the ack-eliciting threshold is 1, an ENDPOINT SHOULD ack every CE-marked packet, even if consecutive" would make it clearer.

My mistake, I was thinking of Reordering Threshold, not Ack-Eliciting Threshold.

My intent was to ack only the first CE, so changing it to larger than 0 seems correct. If you're acking every other packet anyway, you'll be getting plenty of feedback.

I wrote #308 to fix this.

So I think this is the current literal interpretation of the draft:

• ack-eliciting-threshold = 0: ack every packet, the CE marking is neither here nor there
• ack-eliciting-threshold = 1: per RFC 9000, SHOULD ack any CE packet, period.
• ack-eliciting-threshold > 1: per the draft, SHOULD ack the first CE only.

So the main question, is this the intent?

Yes this interpretation is correct as also discussed in issue #253.

If it is the intent, a sentence like "When the ack-eliciting threshold is 1, an ENDPOINT SHOULD ack every CE-marked packet, even if consecutive" would make it clearer.

I believe we also decided to not add any additional normative language here because as you write above this is simply the behaviour as defined normatively already in RFC9000 and we shouldn't define it twice because that make it harder to change things. I guess we could add a non-normative clarification if that really helps but as you actually interpreted the doc correctly, maybe that's not needed?

I closed my first PR, but I do think editorial clarification would be helpful here, since I already forgot what we had agreed upon.

I created PR #313