On Tue, Jul 29, 2025 at 6:04 AM Jen Linkova via Datatracker <noreply@xxxxxxxx> wrote:
Document: draft-ietf-intarea-icmp-exten-hdr-len
Title: ICMP Extension Header Length Field
Reviewer: Jen Linkova
Review result: Has Nits
The document is short and straitforward.
I do have one general question - more for the resposible AD, probably, and a
few editorial comments - please treat them as very much optional.
A question: if [I-D.ietf-intarea-rfc8335bis] acknowledges that inferring the
length is suboptimal, and this draft solves the issue: what prevents us from
using the mechanism defined in THIS document for [I-D.ietf-intarea-rfc8335bis]?
Is it just because this draft was written before I-D.ietf-intarea-rfc8335bis?
Now this draft seems to "overtake" [I-D.ietf-intarea-rfc8335bis], so I'm
wondering: if it gest published before [I-D.ietf-intarea-rfc8335bis] - would it
make sense for [I-D.ietf-intarea-rfc8335bis] to use it?
When I started the rfc8335bis update, I started with an implementation survey. None of the implementations that I could find actually implemented what RFC8335 + RFC4884 specify : in particular, they all added extra data after the extension objects, where RFC4884 implies that the extension objects extend to the end of the packet.
We decided that my update would reflect with the deployed implementations, as opposed to trying to say that they're incorrect (by strictly requiring RFC4884 behavior) or incomplete (by defining an RFC4884 object for "extra data after the ping").
Defining RFC8335bis to use icmp-exten-hdr-len is contrary to that decision. If we have carte blanche to redefine the PROBE packet format, I'd rather just have defined an RFC4884 object for extra data and use that.
Bill
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
