Highlight that greasing applies when received unknown values are ignored -- applicability!

[tfpauly]

The document says this:

In these protocols, extension codepoints are reserved only for greasing and must be ignored upon receipt. Greasing is suitable for many protocols but not all; Section 3.3 of [VIABILITY] discusses the applicability and limitations of greasing.

This is a key point for applicability; we should make it very obvious in the abstract and/or title about this applicability.

Relatedly, since unknown QUIC frame types cannot be ignored, we should make it clear that this is about how we segment QUIC stream frames

[LPardue]

Relatedly, since unknown QUIC frame types cannot be ignored, we should make it clear that this is about how we segment QUIC stream frames

I disagree slightly here. I have seen issues related to variability of the QUIC wire image, including other QUIC frames defined in RFC 9000 and the size of packets. For instance, I have heard anecdotal evidence about the failures of QUIC DPLPMTUD in the wild - with it being unclear if that is due to ossification or not.

I am happy to rename Section 4.1 from "Example: QUIC frames" to something like "Example: QUIC packets and frames" and split the text to say more about about how/why greasing frame types does not work quite the same and then put the current stream example as a subsection 4.1.1 "STREAM frame variability".

[dthaler]

I think there are two types of "greasing" (maybe we need separate terms?):

a) Greasing to prevent ossification of legitimate protocol receivers. This is what this issue is referring to.
b) Greasing to prevent ossification of middleboxes (switches, routers, NATs, firewalls, TCP proxies, etc.) that are not intended "protocol receivers". Maybe we should use a different term for this one, but this one has different considerations than type A.

E.g., having protocol endpoints negotiate code points to use (e.g., both ends using dynamic ports, as some protocols do) helps situation B but does not help situation A.