Document: draft-ietf-intarea-icmp-exten-hdr-len Title: ICMP Extension Structure Length Field Reviewer: Joseph Touch Review result: Ready with Nits
This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. There are no transport area issues with the document. The following additional notes are offered. It isn’t clear why this is useful at all, as per below. RFC4884 already supports one extension header with “one or more extension objects”. Each object already contains a length field in that object. So the proposed change to the Reserved field is basically the sum of these lengths plus the length of the extension header (4), divided by 4*. It thus appears this change adds no new information. That should be made more clear – as well as the reason for the need for adding this information, given it is already available at the time of parsing. This is contrary to the claim about the pending update to rfc8335. * - this document should indicate what the new length field should be if the sum of component objects is not word-aligned, i.e., presumably it MUST pad them with zeros to ensure a word-aligned length that matches the claimed length of the length field itself. The document should be more clear about the specific way in which it updates RFC 4884. In particular, this document claims that RFC 4884 requires the Reserved field be set to zero and ignored on receipt; RFC 4884 is clear on the former but does not mention the latter. A conformant implementation could (and might rightly) verify that the Reserved field is zero on receipt. I.e., the handling here to ignore the remaining reserved bits is a new requirement that differs from RFC 4884. Section 4 implies that legacy uses must put the extension structure last; it is not clear how or why this change would not also have that constraint, given the second rule always applies (that the length of the extension structure can be computed from the packet). _______________________________________________ Int-area mailing list -- int-area@ietf.org To unsubscribe send an email to int-area-le...@ietf.org
