Editorialize greasing considerations (#15)

* Editorialize greasing considerations

This attempts to make the recommendations clearer by reducing some
fluff and combining some paragraphs. Effectively putting all the
concerns about grease values together, followed by registration
considerations.

Co-authored-by: Tommy Pauly <[email protected]>

draft-edm-protocol-greasing.md

@@ -92,66 +92,57 @@ migration.
 Greasing can take many forms, depending on the protocol and the nature of its
 extension points.
 
-In cases where a protocol uses registered values (i.e. codepoints) or numbers in
-a well defined range, a common approach (see {{GREASE}}, {{Section 18.1 of QUIC}},
-or {{Section 7.2.8 of RFC9114}}), is to reserve a subset of the range for the
-purposes of greasing. This approach is detailed more thoroughly in {{Section 3.3
-of ?VIABILITY=RFC9170}}. However, protocol designers or implementers may find it
-difficult to apply those suggestions in abstract. The likely success or
-efficacy of this method can be improved by the following suggestions.
-
-It is assumed that endpoint should implement robust and broad extension
-handling. When acting as a receiver or a parser, the implementation should not
-treat codepoints reserved for the purposes of greasing as individually special.
-In other words, rather than implementation looking specifically for reserved
-values, it is better to have a "catch all" mechanism that can handle receipt of
-unknown extensions gracefully or without error.
-
-In order to exercise receiver capability, it is advisable that senders send
-values from the ranges reserved for greasing. However, picking a deterministic
-value risks a value becoming ossified itself. One outcome of that is receivers
-being written to handle a single expected value rather than the generic handling
-described above. One way to help mitigate this is to reserve a sufficiently
-large range of values for greasing, and ensure that senders chose values from
-that range with diversity and non-determinism. The specific nature of size and
-distribution of the grease range needs to accommodate the protocol constraints.
-For instance, an 8-bit field can only represent a small range of values and it
-may be too costly to dedicate many of them solely for the purpose of greasing.
-However, protocols that use 32-bit or 64-bit fields are unlikely to have such
-restrictions.
-
-It is beneficial to have a large set of reserved numbers for the purpose of
-greasing. However, protocol designers that wish to do so may encounter
-difficulties in expressing the large range in their protocol documents and/or in
-an IANA registry. One approach to this problem has been to define the set
-algorithmically in the protocol definition and request that IANA reserve only a
-single entry in the respective table that covers the entire range; see for
-example
+Many protocols register values, codepoints, or numbers in a limited space. A
+common approach that has developed in more recent protocols is to reserve a subset of the space for greasing (see
+{{GREASE}}, {{Section 18.1 of QUIC}}, or {{Section 7.2.8 of RFC9114}}). Values
+reserved for the purpose of greasing are herein referred to as grease values.
+Implementations that receive grease values are required to ignore them. More
+background to this approach is given in {{Section 3.3 of ?VIABILITY=RFC9170}}.
+This section provides concrete suggestions for its usage.
+
+It is assumed that endpoints should implement robust and broad extension
+handling. A receiver or a parser implementation should not treat grease values
+as individually special. Instead of identifying each grease value explicitly,
+it is better to have a "catch all" mechanism that can handle receipt of unknown
+extensions, whether grease values or not, gracefully or without error.
+
+It is recommended that senders pick an unpredictable grease value to include in
+relevant protocol elements. This ensures that receiver greasing requirements are
+exercised. Using predictable grease values risks ossification. To increase the
+variety of grease values, it is advised to reserve a large range. However, the
+specific size and distribution of the grease range needs to accommodate the
+protocol constraints. For instance, protocols that use 8-bit fields may find it
+too costly to dedicate many grease values, while 32-bit or 64-bit fields are
+likely to have no limitations.
+
+It is recommended that senders use grease values at unpredictable times or
+sequence points during protocol interactions. This avoids receivers
+unintentionally ossifying on the occurrence of greasing in the temporal or
+spatial domain.
+
+It is recommended that large grease value sets are allocated in protocol
+documents by defining a unique algorithm, to increase the chance that
+receiver greasing requirements are exercised. However, the choice of algorithm
+needs to consider the spread of values and the size of contiguous blocks between
+grease values. It is common for protocol extension designers to want to reserve
+a contiguous block of code points in order to aid iteration and experimentation.
+Small contiguous blocks increase the chance that such reservations might
+unintentionally use grease values, which could lead to interoperability
+failures.
+
+Protocols might ask IANA to create new registries for their extension points.
+When greasing, it is recommended that only a single entry for the entire grease
+value set is registered. When an algorithm has been used, it should be included
+in the entry; see for example
 https://www.iana.org/assignments/http3-parameters/http3-parameters.xhtml#http3-parameters-frame-types.
-This range should be protected from registering from any other purpose. Deciding
-an appropriate label for this protected range is important. Labelling it simply
+
+Grease values must not be used or registered for any other purpose. Registries
+should include a label to identify the protected grease value range; a label of
 "reserved" may be confused with other ranges that are reserved for private or
 experimental extensions. An implementer that conflates these two meanings may
 cause a new class of interoperability failure. Therefore a label such as
-"reserved for greasing" may help to avoid the confusion. If choosing to use an
-algorithm to define the set, it is encourage to use unique algorithms. This
-again improves the chances that receivers will build robust extension handling
-rather that a simple special-case ignore list.
-
-Protocols that do reserve ranges for greasing introduce a new consideration for
-real extensions. It is common to want to reserve a block of code points for
-iteration and experimentation. Depending how the algorithm spreads numbers
-through the full range, any single block of uninterrupted values may be too
-small to be usable. This could lead to unintentional use of a greased value.
-
-Since it is intended for receivers to ignore values reserved for greasing,
-designers and implementers need to remain aware that unintentional use of
-greased values by a sender for a real extension may cause a failure.
-
-Receiver implementations may unintentionally build a reliance on the occurrence of
-greasing in the temporal or spatial domain. Senders are advised to
-implementation non-determinism of when they use grease in addition to what
-values they send.
+"reserved for greasing" may help to avoid the confusion.
+
 
 # Considerations for Increasing Protocol Variability {#variability}