Hi Ketan, See inline......[RB]
________________________________ From: Ketan Talaulikar via Datatracker <[email protected]> Sent: Tuesday, August 19, 2025 6:50 AM To: The IESG <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Ketan Talaulikar's Discuss on draft-ietf-intarea-icmp-exten-hdr-len-07: (with DISCUSS and COMMENT) [External Email. Be cautious of content] Ketan Talaulikar has entered the following ballot position for draft-ietf-intarea-icmp-exten-hdr-len-07: 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!AXjO93HXCQNmYLqSSJ9Sfs3ymYwxAFRjDfZVi7-VHBPMBPdlHV-HOHratk7K_qWIM1swhRBH9U1izpg$ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-intarea-icmp-exten-hdr-len/__;!!NEt6yMaO-gk!AXjO93HXCQNmYLqSSJ9Sfs3ymYwxAFRjDfZVi7-VHBPMBPdlHV-HOHratk7K_qWIM1swhRBHu4m5T9U$ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks to the authors and the WG for their efforts on this document. I agree with the sentiment that the length field should have been introduced in the ICMP Extension Structure from the outset in RFC4884. I support Gorry's DISCUSS position. I have somewhat similar questions on certain points that remain open and I will attempt to perhaps ask them in a different way. discuss #1 Section 1 says "Because the ICMP Extension Structure does not have a 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." However, per RFC4884 section 7, there can be only a single ICMP Extension Structure (at the end of the PDU) but it can contain one or more ICMP Extension Objects. This is possible since each extension object has its own length field to allow parsing of multiple objects. Am I missing something? [RB] I have posted a version 8 with a new introduction. The motivation for this draft no longer has anything to do with I-D.ietf-intarea-rfc8335bis. The motivation is simply because we should have done it this way in the first place (as you say above). discuss #2 Section 1 says "This special handling for PROBE packets is not ideal. For future use, a mechanism to explicitly specify the extension structure length would be beneficial." However, draft-ietf-intarea-rfc8355bis does not identify any such limitation and neither does it require or need the extensions in this document. Is this about RFC 8355 instead? Am I missing something? Could the authors/WG please share some more context? >From what I see, the introduction of this new format with a length would relax the requirement for an ICMP Extension Structure to be only towards the end of the PDU. However, I don't see any such requirements or use-case and if there were something, it could perhaps be just as easily modeled as an extension object within the current extension structure? Further, section 4 says "The length of the ICMP Extension Structure can be inferred from other fields in the packet (e.g., [I-D.ietf-intarea-rfc8335bis]." but I am not sure that this is the case with this document. Is this again about RFC 8355? [RB] Again, this draft no longer mentions RFC 8445 or I-D.ietf-intarea-rfc8335bis. discuss #3 Section 4 claims that the proposed encoding is backward compatible (i.e., it would allow the ICMP Extension Structure to be placed in position other than at the end of the PDU), but that claim is false since backward compatibility works only if the structure were at the end and in that case there is no use of this new encoding in the first place. To me, the new encoding would be backward compatible if older implementations are able to parse over it (when the extension structure is not at the end) and/or be able to detect an unsupported version/type and discard it. Using a new structure version (3) could have been a more robust mechanism that is backward compatible and would be recognized /parsed by older implementations and handled as an exception. This also allows for the new version of extension structure to be use when there is a requirement for it to be placed other than towards the end of the PDU. At the same time, the old version can be continued to be used where it can be placed towards the end of the PDU. I do not see whether the WG has considered this aspect during the progression of this document and I would like to discuss the same. [RB] Currently, the only applications that put anything after the ICMP Extension Headers do so in violation of RFC 8335. This document shouldn't have to worry about backwards compatibility with them. If I-D.ietf-intarea-rfc8335bis is published, they will no longer be in violation. They will be backwards compatible because of some special processing rules that Bill Fenner both documents and decries in his document. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please find below some questions/comments: 1) It is not clear if this new encoding now allow for multiple ICMP Extension Structure to be present in the PDU. I believe it is still only one? Can this be clarified? 2) I find it odd that the document does not callout that the introduction of the length field alleviates the requirement for the ICMP Structure to be only at the end of the PDU. Does that restriction still apply? Juniper Business Use Only
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
