|
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." |
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
