Skip to content

Some editorial fixes #43

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Oct 20, 2025
Merged

Some editorial fixes #43

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
cbb3dc5
Some editorial changes up through end of section 3.2
dthaler Jul 7, 2025
c6595a5
More grammar fixes
dthaler Jul 7, 2025
b5c6688
Update draft-edm-protocol-greasing.md
dthaler Jul 21, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 16 additions & 14 deletions draft-edm-protocol-greasing.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -144,11 +144,11 @@ 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 such limitations.

It is recommended to use an algorithm to reserving large sets of values.
For example, {{QUIC}} uses and algorithm of `31 * N + 27` to allocate
transport parameters grease values.
It is recommended to use an algorithm to reserve large sets of values.
For example, {{QUIC}} uses an algorithm of `31 * N + 27` to allocate
grease values for transport parameters.

One possible problem with some algorithms is how they will spread out
One possible problem with some algorithms is that they will spread out
values over the space, and impact the ability to use or reserve contiguous
blocks of non-grease values. It is common for protocol extension designers
to want to reserve contiguous blocks of codepoints in order to aid
Expand All @@ -165,7 +165,7 @@ IANA registries that contain reserved grease values must indicate that
the values are reserved. The specifics of how to represent the reservations
is up to the documents that define the registries.

Some registries list out the reserved grease values specifically, marked as
Some registries list out the reserved grease values individually, marked as
"Reserved". For example, the TLS registry uses this approach
(https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml).

Expand All @@ -183,16 +183,18 @@ to label the reservation with a clear identifier, such as "reserved for greasing
## Use Unpredictable Grease Values

In order to gain the benefits of active use and avoid ossification, grease values
need to be sent in ways that won't become a predictable pattern that implementations
used in actual packets
need to be sent in ways that won't become a predictable pattern that receiver and
middlebox implementations
Comment on lines +186 to +188
Copy link
Member

@tfpauly tfpauly Jul 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is necessarily specific to protocols with packets or that have traditional middleboxes intercepting them (although those are common cases)

Copy link
Collaborator Author

@dthaler dthaler Jul 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"middlebox" was already used in line 88, and so my PR is consistent with existing text.

Feel free to suggest alternate text for both this and line 88, though perhaps in a separate PR?

Copy link
Collaborator

@LPardue LPardue Jul 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternative ideas

  • used in packets => used in the wire image
  • middle box => on-path observers

Copy link
Member

@tfpauly tfpauly Jul 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess that having "receiver and middlebox" does cover the cases. Maybe let's just update the wire image aspect.

Suggested change
used in actual packets
need to be sent in ways that won't become a predictable pattern that receiver and
middlebox implementations
used in the wire image
need to be sent in ways that won't become a predictable pattern that receiver and
middlebox implementations

Copy link
Collaborator

@LPardue LPardue Jul 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That works for me

Copy link
Collaborator Author

@dthaler dthaler Jul 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't understand the term "wire image" so -1 to that.

Copy link
Collaborator

@LPardue LPardue Jul 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In case it helps, its a term defined by https://datatracker.ietf.org/doc/html/rfc8546

Copy link
Collaborator Author

@dthaler dthaler Jul 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't help without a reference in the document. E.g., RFC 9019 uses the term "image" for a completely different meaning ('The terms "firmware image", "firmware", and "image" are used in this document and are interchangeable.') and that's what I'm familiar with.

Is there a semantic difference between "used in actual packets" vs "used in the wire image"? The former is more readable. Or perhaps:

Suggested change
used in actual packets
need to be sent in ways that won't become a predictable pattern that receiver and
middlebox implementations
used in actual packets (i.e., the "wire image" as defined in [RFC8546])
need to be sent in ways that won't become a predictable pattern that receiver and
middlebox implementations

Copy link
Collaborator

@LPardue LPardue Jul 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be honest, the more I read RFC 8546 the more I think it isn't intended for our protocol participant "receiver" role. So i take my suggestion back (sorry). I don't have much inspiration for a further alternative to the term packet

and deployments ossify around.

Implementations that generate grease values should pick unpredictable entries
from the set of reserved grease values. It is most important that values be
unpredictable across the set of all protocol participants for particular deployments.
This can be achieved in multiple ways: for example, an individual client device
This can be achieved in multiple ways: for example, an individual sender
might pick random values from the grease value space on each interaction;
alternatively, a single client could pick a specific grease value to use, while
other clients pick other values.
alternatively, a single sender could pick a specific grease value to use, while
other senders pick other values.

In order to support picking unpredictable values, the set of reserved values
should be large, when possible. See {{define}} for a discussion of how to allocate
Expand All @@ -205,7 +207,7 @@ can be made unpredictable. Implementations can vary their behavior by including
no grease values, one grease value, or multiple grease values for a given protocol
extension point.

How consistently an frequently to use grease values is a choice that implementations
How consistently and frequently to use grease values is a choice that implementations
and deployments need to consider and weigh against several factors.

Deployments of greasing should consider how they expect errors exposed by
Expand Down Expand Up @@ -319,7 +321,7 @@ when they receive grease values.
# Considerations for Increasing Protocol Variability {#variability}

Greasing can maintain protocol extensibility by falsifying active use of its
extension points. However, greasing alone does not ensure positive use of extension mechanisms. A protocol may
extension points (see {{Section 3.3 of VIABILITY}}). However, greasing alone does not ensure positive use of extension mechanisms. A protocol may
define a wide-ranging extension capability that remains unused in the absence of
real use cases. This can lead to ossification that does not expect extensions,
leading to interoperability problems later on.
Expand All @@ -329,7 +331,7 @@ extension points positively. To some extent this can be thought of as protocol
fuzzing. This might be difficult to exercise because varying the protocol
elements might change the outcome of interactions, leading to real errors.
However, some protocols allow elements to be be safely changed, as shown in the
following examples.
following example.

## Example: QUIC frames

Expand All @@ -344,8 +346,8 @@ reassemble frames, which could arrive in any order, into an ordered reliable
byte stream that is readable by applications.

A form of positive testing is for a sender to unpredictably order the STREAM
frames that it transmits. For example, varying the sequence order of offset
values. This allows to exercise the QUIC reassembly features of the receiver
frames that it transmits. For example, the sender can vary the sequence order of offset
values. This allows exercising the QUIC reassembly features of the receiver
with the expectation that no failure would occur. However, doing this may
introduce delay or stream head-of-line blocking that affects the performance
aspects of a transmission, which may not be acceptable for a given use case. As
Expand Down