Greasing failure detection

[dthaler]

Greasing alone just prevents receiver/middlebox crashing vs "tolerating" but unfortunately one type of middlebox "tolerating" is just to drop all unrecognized extensions. I looked for a discussion of this in this document and in
RFC 9170 section 3.3, and the closest I could find was the text around

The principle that grease operates on is that an implementation that is regularly exposed to unknown values is less likely to be intolerant of new values when they appear. This depends largely on the assumption that the difficulty of implementing the extension mechanism correctly is as easy or easier than implementing code to identify and filter out reserved values.

However, for protocols that aren't end-to-end encrypted (e.g., IPv6 next-header values, ICMP codes, EtherTypes, etc.) middleboxes may still choose to drop, which prevents end to end extensibility. I think the document should discuss this issue and deal with questions like:

1. Should the receiver detect/log lack of receiving the other end's greasing messages? I.e., at least detect when extensibility is blocked?
2. Is it a good or bad idea for a protocol to build in something like a greasing ack timeout (and say fail or route around the problem) if no greasing ack is received?

[LPardue]

@dthaler I've assigned this one to you in the hope you can propose some text to address the points you think the document should