Gorry Fairhurst has entered the following ballot position for draft-ietf-intarea-icmp-exten-hdr-len-08: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-intarea-icmp-exten-hdr-len/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for the work is described in this document. I read this I-D as proposing addition structure to the format of the ICMP payload. As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise. Please find below the following blocking DISCUSS points (updated to remove issues thought resolved): * I am sure there could be useful uses and I would like to understand the motivation for this new header; please explain. I would expect this to be described clearly in the intro of this I-D. *Please could you clarify whether a conformant implementation of RFC 4884 is permitted to discard a message when the Reserved field is zero on receipt? - Where does RFC 4884 state this or is this undefined in that RFC? (This is related to text at the start of section 4 of the new I-D). (The TSV-ART review might be useful background). Finally, since many of the above details can be hard to see, I would like to discuss if section 5 of this I-D can be made much more clear concerning the specific text that it updates in RFC 4884, by citing the relevent sections in RFC 4884 and quoting the OLD text and the NEW text. text. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please find below the following comments that I hope will help improve the next in the next revision of this draft: * Thanks for Joe Touch's TSV-ART review here: https://datatracker.ietf.org/doc/review-ietf-intarea-icmp-exten-hdr-len-04-tsvart-lc-touch-2025-08-01/ - please read and consider these as inputs to the next revision of this I-D. * The I-D says in para 1 of sect 1: "This means it is expected to be the last element of an ICMP message." A similar claim is made at the start of section 3. - I am not sure this is necessarily so, the length can be calculated by the sum of the objects and the header, and hence I do not see the claim in RFC4884. * As I understand, RFC4884 supports an extension header with "one or more extension objects”. Each object already contains a length field in that object. So, does the proposed change to the Reserved field basically indicate the sum of these lengths plus the length of the extension header? (If so, this could be made more clear in the introduction.) * [I-D.ietf-intarea-rfc8335bis] is cited several times, but as I would expect, rfc8335bis does not depend upon this I-D. It does not even reference it. If this is not important to this draft, why is it discussed here? Could this text simply be removed, this could by a clearer motivation? * The I-D states: "Therefore, implementation MUST NOT drop packets if this field is set to 0." - This new formal requirement seems odd to me. I'd expect that an implementation of this I-D is allowed to drop packets if configured to do so? - If so then, perhaps a helpful way is to explicitly state the original text from RFC4884, and the replacement text after this is updated that permits this new field to be used. * Section 4 as written appears to add a new normative requirement on an old specification, stating: "The ICMP Extension Structure MUST be the final item in the ICMP packet." - Please justify or remove this requirment (e.g. replace by /MUST/can/). * Since this I-D could be read as a method for adding additional "bytes" to an ICMP message payload, I think some text clarifying the sender processing for IPv6 would be very helpful (if IPv6 is supported). For ICMPv6, I expect the original datagram" field always contains as many octets as possible without causing the ICMP message to exceed the minimum IPv6 MTU (i.e., 1280 octets). _______________________________________________ Int-area mailing list -- int-area@ietf.org To unsubscribe send an email to int-area-le...@ietf.org
