Mahesh Jethanandani has entered the following ballot position for draft-ietf-intarea-icmp-exten-hdr-len-07: No Objection
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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Overall comment that I support Gorry's DISCUSS. In addition, here are some of my comments. Section 3, paragraph 8 > * This field represents the length of the ICMP Extension Structure, > including all options and optional padding, but excluding the ICMP > Extension Header. The length is measured in 4-byte words. Legacy > implementations set this field to 0 as per section 7 of [RFC4884]. > Therefore, implementation SHOULD NOT drop packets if this field is > set to 0. Why a SHOULD NOT, and not a MUST NOT? In other words, under what circumstances is it ok for an implementation to drop the packet? Section 3, paragraph 9 > The ICMP Extension Structure MUST be zero-padded so that it ends on a > 4-byte boundary. If it does not end on a 4-byte boundary, the > receiving node will parse the ICMP message incorrectly and may > discard it. Why a "may" and not a "MAY"? The same question for Section 5.3, last paragraph. ------------------------------------------------------------------------------- NIT ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 3, paragraph 13 + s/neither padding/neither padded/ Section 3, paragraph 11 > * The final three bytes of the ICMP Extension Structure are neither > padding (i.e., zeros) nor part of a well-formed ICMP Extension > Object. s/neither padding/neither padded/ Section 5.2, paragraph 5 > * The final three bytes of the ICMP Extension Structure are neither > padding (i.e., zeros) nor part of a well-formed ICMP Extension > Object. s/neither padding/neither padded/ _______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
