On Mon, Jan 26, 2026 at 7:58 PM <[email protected]> wrote: > Hi Bill, > > Thank you for the response. > Please see inline. > Original > *From: *BillFenner <[email protected]> > *To: *肖敏10093570; > *Cc: *[email protected] <[email protected]>; > *Date: *2026年01月25日 08:11 > *Subject: **[Int-area] Re: Comments on draft-ietf-intarea-rfc8335bis* > _______________________________________________ > Int-area mailing list -- [email protected] > To unsubscribe send an email to [email protected] > On Sun, Jan 11, 2026 at 10:47 PM <[email protected]> wrote: > >> Dear Intarea WG, >> >> I have a few comments on draft-ietf-intarea-rfc8335bis for the authors to >> consider. >> Section 2, it says " >> >> The Interface Identification Object MAY be followed by an optional >> data section, which is not interpreted but is simply present to be >> copied to the ICMP Extended Echo Reply. >> >> " >> However it lacks an explanation on why *an optional data section* is >> added on the basis of RFC 8335. >> Section 3, similarly it lacks an explanation on why the *ICMP Extension >> Structure* and "Data" fields are added on the basis of RFC 8335. >> Furthermore, it seems helpful to the reader if the definition/processing of >> the two newly added fields can be put in the place closer to the >> definition/processing of other fields in the ICMP Extended Echo Reply >> message. Currently the only text on the two newly added fields is placed in >> the next section (Section 4). >> > > Hi Xiao Min, > > The explanation for this lives in section 1.3: > > 1.3. > <https://fenner.github.io/probe-clarification/draft-ietf-intarea-rfc8335bis.html#section-1.3>A > note on this document's use of ICMP Extensions > <https://fenner.github.io/probe-clarification/draft-ietf-intarea-rfc8335bis.html#name-a-note-on-this-documents-us> > This document defines a unique use of ICMP Extensions [RFC4884 > <https://fenner.github.io/probe-clarification/draft-ietf-intarea-rfc8335bis.html#RFC4884>]: > while normally, ICMP Extensions are defined to start at a given point and > continue to the end of the packet, if the extension object is an Interface > Identification Object as defined in this memo, then the extension structure > (including the checksum) consists only of that single ICMP Extension > Object. This is done to maintain compatibility with the initial set of > implementations of RFC8335, which behave this way. New uses of ICMP > Extensions, and in fact uses of Extended Echo using some object other than > the Interface Identification Object, SHOULD NOT behave this way. Uses > other than defined in this memo SHOULD treat the ICMP Extension Structure > as extending to the end of the packet as [RFC4884 > <https://fenner.github.io/probe-clarification/draft-ietf-intarea-rfc8335bis.html#RFC4884> > ] defines. > > Does this clarify the situation? > [XM]>>> Not exactly. To my understanding, there are two relevant aspects > to be explained. > - The first aspect is why in this document the extension structure > consists only a single ICMP Extension Object. > - The second aspect is why in this document an optional data section is > defined between the ICMP Extension Structure and the end of the packet. > The text in section 1.3 explains the first aspect, but not the second > aspect. Furthermore, the text in section 2 says "The Interface > Identification Object MAY be followed by an optional data section", here > *MAY* is used, which means it's acceptable if the Interface Identification > Object is not followed by an optional data section, wouldn't that be the > case "ICMP Extensions are defined to start at a given point and continue > to the end of the packet"? >
An optional section not being included is not the same as the optional data not being permitted at all. Bill
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
