diff --git a/draft-edm-protocol-greasing.md b/draft-edm-protocol-greasing.md index 6f1790a..953ccc2 100644 --- a/draft-edm-protocol-greasing.md +++ b/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}