ICMP Extension Structure Length Field
draft-ietf-intarea-icmp-exten-hdr-len-08

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.

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?

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?

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.