Hi Bill,
Thank you for the discussion.
Although I didn't get a clear answer on why an optional data section is added
compared with RFC 8335, all the text changes I suggested are just some
explanations to improve the readability, please feel free to ignore them.
Cheers,
Xiao Min
Original
From: BillFenner <[email protected]>
To: 肖敏10093570;
Cc: [email protected] <[email protected]>;
Date: 2026年02月03日 13:01
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 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. A note on this document's use of ICMP Extensions
This document defines a unique use of ICMP Extensions [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]
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]
