Some editorial fixes #43
Conversation
dthaler
commented
Jul 7, 2025
dthaler
commented
- Fix grammar
- Change "client" to "sender" since greasing isn't just for "clients" and some protocols don't have a role called "client" per se but use other terms instead.
1. Fix grammar 2. Change "client" to "sender" since greasing isn't just for "clients" and some protocols don't have a role called "client" per se but use other terms instead. Signed-off-by: Dave Thaler <[email protected]>
Signed-off-by: Dave Thaler <[email protected]>
dthaler
changed the title
| used in actual packets | ||
| need to be sent in ways that won't become a predictable pattern that receiver and | ||
| middlebox implementations |
There was a problem hiding this comment.
I don't think this is necessarily specific to protocols with packets or that have traditional middleboxes intercepting them (although those are common cases)
There was a problem hiding this comment.
"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?
There was a problem hiding this comment.
Alternative ideas
- used in packets => used in the wire image
- middle box => on-path observers
There was a problem hiding this comment.
I guess that having "receiver and middlebox" does cover the cases. Maybe let's just update the wire image aspect.
| 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 |
There was a problem hiding this comment.
I can't understand the term "wire image" so -1 to that.
There was a problem hiding this comment.
In case it helps, its a term defined by https://datatracker.ietf.org/doc/html/rfc8546
There was a problem hiding this comment.
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:
| 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 |
There was a problem hiding this comment.
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
Co-authored-by: Tommy Pauly <[email protected]>
|
Thanks for these! Overall very happy to take them modulo the one comment. I would suggest if we can't resolve that in the next couple of days to merge this PR to avoid bitrot and create issues for immediate followup before publication |
|
Merging to avoid bitrot; my nit isn't that important! |
3 participants
