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

[Ballot 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.

Explanations about why the telechat is pushed back:
https://mailarchive.ietf.org/arch/msg/int-area/2et3zTV7eyf-Owc0fft51wHUUAk/

---- email copy ----
Dear authors, dear intarea WG,

As you may have seen the IESG ballots[1] for the evaluation of draft-ietf-intarea-icmp-exten-hdr-len has currently 2 blocking DISCUSS with several blocking issues, moreover other ADs support the DISCUSS...

My reading of the blocking issues are around whether this draft is useful and how the backward compatibility. The AD review[2] had related points.

To let authors to address the backward compatibility issue (which still worries me), I have removed the IESG evaluation from the 21st of August telechat and will move it back to a future telechat to have it on the same telechat as draft-ietf-intarea-rfc8335bis, this delay should increase the chances of positive evaluation.

Suggested actions by authors of:
- draft-ietf-intarea-icmp-exten-hdr-len work on the other comments by submitting a revised I-D
- draft-ietf-intarea-rfc8335bis: the above is an incentive to work faster on this I-D ;-) else the I-D is not impacted at all by the decision

My own take is that the rfc8335bis is the main (if not the only) motivation for icmp-exen-hdr-len draft, so, if the PROBE bis could do without requiring the exn-hdr-len, then this will even be easier ;-)

Regards

-éric

[1] https://datatracker.ietf.org/doc/draft-ietf-intarea-icmp-exten-hdr-len/ballot/
[2] https://mailarchive.ietf.org/arch/msg/int-area/Ba-worazRWFqwwLQctwdO_H42LM/

Bcc: DISCUSS holders

[Ballot 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?

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.

[Ballot 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?

[Ballot 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:

(1) Thought resolved -- Will this document when published update RFC 4443 (ICMPv6),
or is this ONLY for IPv4?

(2) Thought resolved -- Based on (1) above: The I-D states the length is measured in 4-byte words.
This could be appropriate for IPv4, please indicate whether this is also the
case for IPv6 or ought that to be 8-byte aligned?

(3) 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.

(4) New text proposed -- Please specify what the *receiver* action should be if the new length field
does not equal the sum of component objects. Is this malformed message
to be sliently discarded, the extension to be ignored (and what about
any following extensions), or something else?
(The TSV-ART review has more text that might be useful background).

(5) New text proposed -- What is the *receiver* action when the received padding is malformed
and does not align to a 4-byte boundary? Is this malformed message
to be sliently discarded, the extension to be ignored (and what about
any following extensions), or something else?

(6) New text proposed -- Please could you clarify whether a conformant implementation of RFC 4884
is permitted to discard a message when Reserved field is zero on receipt?
- Where does RFC 4884 state this or os 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.

[Ballot 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/

[Ballot 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:

(1) Will this document when published update RFC 4443 (ICMPv6),
or is this ONLY for IPv4?

(2) Based on (1) above: The I-D states the length is measured in 4-byte words.
This could be appropriate for IPv4, please indicate whether this is also the
case for IPv6 or ought that to be 8-byte aligned?

(3) 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.

(4) Please specify what the *receiver* action should be if the new length field
does not equal the sum of component objects. Is this malformed message
to be sliently discarded, the extension to be ignored (and what about
any following extensions), or something else?
(The TSV-ART review has more text that might be useful background).

(5) What is the *receiver* action when the received padding is malformed
and does not align to a 4-byte boundary? Is this malformed message
to be sliently discarded, the extension to be ignored (and what about
any following extensions), or something else?

(6) Please could you clarify whether a conformant implementation of RFC 4884
is permitted to discard a message when Reserved field is zero on receipt?
- Where does RFC 4884 state this or os 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.

[Ballot 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).

[Ballot comment]
# Internet AD comments for draft-ietf-intarea-icmp-exten-hdr-len-05
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### __general__

* It's probably worth noting that this document does not define any
  indication of what type of data might be beyond the newly-added
  length of the extension structure.

  The type must either be inferred from other context or is left as
  a matter for a future extension.

[Ballot comment]
Some more information:
- this change in RFC 4884 is mainly to ease the path for another draft draft-ietf-intarea-rfc8335bis
- not too many reviews have been done except the 4 directorates ones
- even after discussions with the authors, I am still unsure why it was not easier to defined a new value for the version field of RFC 4884 (notably for backwards compatibility)

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-intarea-icmp-exten-hdr-len-05, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

Request for IETF Last Call review by TSVART Completed: Ready with Nits. Reviewer: Joseph Touch. Sent review to list. Submission of review completed at an earlier date.

The following Last Call announcement was sent out (ends 2025-08-12):

From: The IESG
To: IETF-Announce
CC: draft-ietf-intarea-icmp-exten-hdr-len@ietf.org, evyncke@cisco.com, ggx@gigix.net, int-area@ietf.org, intarea-chairs@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (ICMP Extension Header Length Field) to Proposed Standard


The IESG has received a request from the Internet Area Working Group WG
(intarea) to consider the following document: - 'ICMP Extension Header Length
Field'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-08-12. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The ICMP Extension Structure does not have a length field.
  Therefore, unless the length of the Extension Structure can be
  inferred from other data in the ICMP message, the Extension Structure
  must be the last item in the ICMP message.

  This document defines a length field for the ICMP Extension
  Structure.  When length information is provided, receivers can use it
  to parse ICMP messages.  Specifically, receivers can use length
  information to determine the offset at which the item after the ICMP
  Extension Structure begins.

  This document updates RFC 4884.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-intarea-icmp-exten-hdr-len/



No IPR declarations have been submitted directly on this I-D.

# Document History

Document: https://datatracker.ietf.org/doc/draft-ietf-intarea-icmp-exten-hdr-len/

Title: ICMP Extension Header Length Field

Revision: draft-ietf-intarea-icmp-exten-hdr-len-01

Shepherd: Luigi Iannone (ggx@gigix.net)

Writeup Template: https://datatracker.ietf.org/doc/shepherdwriteup-template/workinggroup



1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement?

    The mailing list archives shows that even if the number of emails in support of the last call is not huge there were no objections in moving this document forward.

2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough?

    No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

    No one showed any form of discontent.

4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)?

    There is no information available if there are existing implementations.


# Additional Reviews

5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place.

    No further reviews needed.
   
6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

    No formal review is required.

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC 8342?

    This document does not contain a YANG Module.


8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

    The document does not contain anything written in a formal language, hence, no validation and/or check has been performed.

# Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?

    The document is clearly written, needed, and ready to be handed off to the responsible AD.

10. Several IETF Areas have assembled lists of common issues that their reviewers encounter. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews?

    The document does not touch any issue listed at: https://wiki.ietf.org/group/iesg/ExpertTopics

11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?

    This document request to be published as Standard Track, since it updates a Standard Track document (namely RFC 4884). 

12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable.

    All the co-authors, did state explicitly that they are not aware of any IPR related to this document. No one else did any IPR disclosure. 

13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification.

    Each co-author is clearly willing to be listed as such.

14. Document any remaining I-D nits in this document. Simply running the idnits tool is not enough; please review the "Content Guidelines" on authors.ietf.org. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.)

    The idnits shows a few warnings:

    - Header format: the update line should not contain the word RFC
    - Abstract: it must include a statement about updating RFC 4884.
    - 2119 Boilerplate: not recognized.
   
    While reviewing this document I did not spot any other issue.
    These warnings can be fixed during AD review.

15. Should any informative references be normative or vice-versa? See the IESG Statement on Normative and Informative References.

    No reference should change type.

16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references?

    There is no reference with restricted access. 

17. Are there any normative downward references (see RFC 3967 and BCP 97) that are not already listed in the DOWNREF registry? If so, list them.

    No normative downward references.
s
18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion?

    No normative references are in unclear state or not ready.

19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed.

    This document will update RFC 4884, as stated in the relevant parts of the document. The datatracker metadata is not yet updated (this can be done during AD Review). 

20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126).

    This document requires no IANA actions.


21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate.

    No new registries are created.

# Document History

Document: https://datatracker.ietf.org/doc/draft-ietf-intarea-icmp-exten-hdr-len/

Title: ICMP Extension Header Length Field

Revision: draft-ietf-intarea-icmp-exten-hdr-len-01

Shepherd: Luigi Iannone (ggx@gigix.net)

Writeup Template: https://datatracker.ietf.org/doc/shepherdwriteup-template/workinggroup



1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement?

    The mailing list archives shows that even if the number of emails in support of the last call is not huge there were no objections in moving this document forward.

2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough?

    No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

    No one showed any form of discontent.

4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)?

    There is no information available if there are existing implementations.


# Additional Reviews

5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place.

    No further reviews needed.
   
6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

    No formal review is required.

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC 8342?

    This document does not contain a YANG Module.


8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

    The document does not contain anything written in a formal language, hence, no validation and/or check has been performed.

# Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?

    The document is clearly written, needed, and ready to be handed off to the responsible AD.

10. Several IETF Areas have assembled lists of common issues that their reviewers encounter. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews?

    The document does not touch any issue listed at: https://wiki.ietf.org/group/iesg/ExpertTopics

11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?

    This document request to be published as Standard Track. As of today the datatracker needs to be updated. 

12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable.

    All the co-authors, did state explicitly that they are not aware of any IPR related to this document. No one else did any IPR disclosure. 

13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification.

    Each co-author is clearly willing to be listed as such.

14. Document any remaining I-D nits in this document. Simply running the idnits tool is not enough; please review the "Content Guidelines" on authors.ietf.org. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.)

    The idnits shows a few warnings:

    - Header format: the update line should not contain the word RFC
    - Abstract: it must include a statement about updating RFC 4884.
    - 2119 Boilerplate: not recognized.
   
    While reviewing this document I did not spot any other issue.
    These warnings can be fixed during AD review.

15. Should any informative references be normative or vice-versa? See the IESG Statement on Normative and Informative References.

    No reference should change type.

16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references?

    There is no reference with restricted access. 

17. Are there any normative downward references (see RFC 3967 and BCP 97) that are not already listed in the DOWNREF registry? If so, list them.

    No normative downward references.
s
18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion?

    No normative references are in unclear state or not ready.

19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed.

    This document will update RFC 4884, as stated in the relevant parts of the document. The datatracker metadata is not yet updated (this can be done during AD Review). 

20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126).

    This document requires no IANA actions.


21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate.

    No new registries are created.

# Document History

Document: https://datatracker.ietf.org/doc/draft-ietf-intarea-icmp-exten-hdr-len/

Title: ICMP Extension Header Length Field

Revision: draft-ietf-intarea-icmp-exten-hdr-len-01

Shepherd: Luigi Iannone (ggx@gigix.net)

Writeup Template: https://datatracker.ietf.org/doc/shepherdwriteup-template/workinggroup



1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement?

    The mailing list archives shows that even if the number of emails in support of the last call is not huge there were no objections in moving this document forward.

2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough?

    No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

    No one showed any form of discontent.

4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)?

    There is no information available if there are existing implementations.


# Additional Reviews

5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place.

    No further reviews needed.
   
6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

    No formal review is required.

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC 8342?

    This document does not contain a YANG Module.


8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

    The document does not contain anything written in a formal language, hence, no validation and/or check has been performed.

# Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?

    The document is clearly written, needed, and ready to be handed off to the responsible AD.

10. Several IETF Areas have assembled lists of common issues that their reviewers encounter. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews?

    The document does not touch any issue listed at: https://wiki.ietf.org/group/iesg/ExpertTopics

11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?

    This document request to be published as Standard Track. As of today the datatracker needs to be updated. 

12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable.

    All the co-authors, did state explicitly that they are not aware of any IPR related to this document. No one else did any IPR disclosure. 

13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification.

    Each co-author is clearly willing to be listed as such.

14. Document any remaining I-D nits in this document. Simply running the idnits tool is not enough; please review the "Content Guidelines" on authors.ietf.org. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.)

    The idnits shows a few warnings:

    - Header format: the update line should not contain the word RFC
    - Abstract: it must include a statement about updating RFC 4884.
    - 2119 Boilerplate: not recognized.
   
    While reviewing this document I did not spot any other issue.
    These warnings can be fixed during AD review.

15. Should any informative references be normative or vice-versa? See the IESG Statement on Normative and Informative References.

    No reference should change type.

16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references?

    There is no reference with restricted access. 

17. Are there any normative downward references (see RFC 3967 and BCP 97) that are not already listed in the DOWNREF registry? If so, list them.

    No normative downward references.
s
18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion?

    No normative references are in unclear state or not ready.

19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed.

    This document will update RFC 4884, as stated in the relevant parts of the document. The datatracker metadata is not yet updated (this can be done during AD Review). 

20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126).

    This document requires no IANA actions.


21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate.

    No new registries are created.