Thank you Ron for addressing my comments so quickly! On Tue, Jul 29, 2025 at 11:04 PM Ron Bonica <rbonica@xxxxxxxxxxx> wrote: > > Jen, > > Thanks for your careful review. I have just posted a new version of the draft that adopts all of your editorial comments. > > Ron > > > Juniper Business Use Only > > ________________________________ > From: Jen Linkova via Datatracker <noreply@xxxxxxxx> > Sent: Tuesday, July 29, 2025 6:02 AM > To: ops-dir@xxxxxxxx <ops-dir@xxxxxxxx> > Cc: draft-ietf-intarea-icmp-exten-hdr-len.all@xxxxxxxx <draft-ietf-intarea-icmp-exten-hdr-len.all@xxxxxxxx>; int-area@xxxxxxxx <int-area@xxxxxxxx>; last-call@xxxxxxxx <last-call@xxxxxxxx> > Subject: draft-ietf-intarea-icmp-exten-hdr-len-03 ietf last call Opsdir review > > [External Email. Be cautious of content] > > > 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? If yes, some references > in this draft (an RFC by then) might get obsolete..Sorry if it's been discussed > on the list and I somehow missed it.. > > Editorial comments: > > 1. Abstract says: "The ICMP Extension Structure does not have a length field." > - do you think it might be beneficial to add an RFC reference? E.g. "The ICMP > Extension Structure (RFC4884).."? > > Also, I guess you can start the second paragraph with: > "This document updates RFC 4884 to define a length field for the ICMP > Extension Structure..." and drop the very last sentence of the abstract. > > 2. Abstract and introduction contain identical text. Maybe it's worth merging > the introduction and motivation? > > Also, it might be just me but I found Motivation section a bit confusing. > > How about rewrting Intro/Motivation section as smth like: > > The ICMP Extension Structure [RFC4884] lacks a length field, which means it is > expected to be the last element of an ICMP message. However, there are cases > where additional fields need to be inserted after the ICMP Extension Structure. > > For example, [I-D.ietf-intarea-rfc8335bis] enhances the PROBE utility by adding > a new field to ICMP Extended Echo and ICMP Extended Echo Reply messages. To > maintain compatibility with existing PROBE implementations, this new field is > placed after the ICMP Extension Structure. > > Because there is no length field, [I-D.ietf-intarea-rfc8335bis] requires > implementations to determine the length of the extension structure from the > known message format and the assumption that these packets contain only a > single ICMP Extension Object. > > This special handling for PROBE packets is not ideal. For future use, a > mechanism to explicitly specify the extension structure length would be > beneficial. > > This document defines such a mechanism. > > 3. Section 4: > 3.1 Currently Section 7 of RFC488 is only mentioned in the length fied > description. IMHO it would help the reader if Section 7 (which defines the old > format) is mentioned at the very beginning of this section. Maybe smth like: > > "The extension header format is defined by Section 7 of RFC4884. This document > modifies the format by allocating the lower 8 bits of the reserved field for > the new length field, as shown below" ? > > 3.2 Do you think it's worth stating explicitly either in this section or > Section 5 that implementations MUST NOT drop/ignore the received ICMP extension > if the length field is zero, as such packets may be sent by legacy > implementations? > > 4. Backwards compatibility: > > It might be just me but it's another section I found a bit hard to read. > Here is my attempt to rephrase it - indeed, feel free to ignore my suggestion, > or use it - up to you: > > " > Legacy implementations that do not support the mechanism defined in this > document set the length field to zero (Section 7 of [RFC4884]) when sending a > packet and ignore the length field in received ICMP messages. > > Such implementations require one of the following: > > The ICMP Extension Structure MUST be the final item in the ICMP packet. > > The length of the ICMP Extension Structure can be inferred from other fields in > the packet (e.g., [I-D.ietf-intarea-rfc8335bis]). > > Currently, no mechanisms rely on the ICMP extension structure length field. > Should such mechanisms be defined in the future, backward compatibility with > legacy implementations should be discussed for each case." > > > -- Cheers, Jen Linkova -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
