Hello Ron,
Thanks for the -02, but I am afraid that it does not fully address my comments.
# Critical ones
### Section 1
> Please add (reference to current work in another WG ?) justification for this
> I-D. What can be added *after* the ICMP Extension Structure that cannot be
> included *in* the ICMP Extension Structure?
### Section 4
Even if the text is better in -02, the operational considerations / backward
compatibility are still vague.
# Less critical ones
### Abstract
> Add a reference to RFC 4884 in the first paragraph in *addition* to fixing
> the id-nit issue.
### Section 3
> What is the expected receiver behavior when receiving a packet that does not
> comply with `The ICMP Extension Structure MUST be zero-padded so that it ends
> on a 4-byte boundary`?
The new text uses a simple non-BCP14 “may discard” and I would expect a “MUST
discard”. Also, nothing is said whether the receiver must/should check whether
the padding is still 0 (e.g., to avoid side channels).
Regards
-éric
PS: I also noted the change of affiliation, quick reaction of yours ;-)
From: Ron Bonica <rbon...@juniper.net>
Date: Monday, 7 July 2025 at 18:39
To: Eric Vyncke (evyncke) <evyn...@cisco.com>, int-area@ietf.org
<int-area@ietf.org>
Cc: he...@chinatelecom.cn <he...@chinatelecom.cn>, xiao.min2
<xiao.m...@zte.com.cn>, tal.mizrahi....@gmail.com <tal.mizrahi....@gmail.com>,
g...@gigix.net <g...@gigix.net>
Subject: Re: AD review of draft-ietf-intarea-icmp-exten-hdr-len-01
Erik,
Thanks for the careful review. I have posted a version-02 that addresses all of
your comments except for one. I couldn't get SVG to work in markdown.
Can you send me an example of how it works?
Ron
Juniper Business Use Only
________________________________
From: Eric Vyncke (evyncke) <evyn...@cisco.com>
Sent: Monday, July 7, 2025 7:09 AM
To: int-area@ietf.org <int-area@ietf.org>
Cc: Ron Bonica <rbon...@juniper.net>; he...@chinatelecom.cn
<he...@chinatelecom.cn>; xiao.min2 <xiao.m...@zte.com.cn>;
tal.mizrahi....@gmail.com <tal.mizrahi....@gmail.com>; g...@gigix.net
<g...@gigix.net>
Subject: AD review of draft-ietf-intarea-icmp-exten-hdr-len-01
[External Email. Be cautious of content]
# Éric Vyncke, INT AD, AD review of draft-ietf-intarea-icmp-exten-hdr-len-01
CC @evyncke
Thank you for the work put into this document.
As usual, as the responsible AD for the ADD WG, I have done an AD review before
the IETF Last Call. Please find a MD-formatted review below. Before going
further, I am requesting the authors to act/reply/comment on all the points
below. The end goal is to ease the rest of the publication process.
I hope that this review helps to improve the document,
Regards,
-éric
## COMMENTS
### Shepherd write-up
Thanks, Luigi, for writing it *but* please add a justification for the intended
status (e.g., updating a standard track RFC).
### Check id-nit tool
Please address
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-intarea-icmp-exten-hdr-len-01.txt<https://urldefense.com/v3/__https:/author-tools.ietf.org/api/idnits?url=https:**Awww.ietf.org*archive*id*draft-ietf-intarea-icmp-exten-hdr-len-01.txt__;Ly8vLy8!!NEt6yMaO-gk!DyzOiwzfWekP5VOJvd8d-HJmycd3NiLoeQr0_XaZRZL7gm851BQ3QblB4TOc3MgR3Gu5RACEr6FI4es$>
about the "Updates:" field value and lack of reference to RFC 4884 in the
abstract (coud be done in the 2nd paragraph of the abstract).
### Abstract
Add a reference to RFC 4884 in the first paragraph in *addition* to fixing the
id-nit issue.
### Section 1
Please add (reference to current work in another WG ?) justification for this
I-D. What can be added *after* the ICMP Extension Structure that cannot be
included *in* the ICMP Extension Structure.
### Section 3
s/Figure 1 depicts the ICMP Extension Header./Figure 1 depicts the ICMP
Extension Header as updated by this document./
Make the implementers/readers task easy:
* For the Version field, please state "ICMP extension version number. This is
version 2 per RFC 4884"
* For the Rsvd field, please state "MUST be set to 0 by the sender and MUST be
ignored by the receiver."
* For the Checksum, please repeat the text from RFC 4884 and be clear that this
is copied from RFC 4884.
s/Legacy implementations set this field to 0./Legacy implementations set this
field to 0 per section 7 of RFC 4884./
What is the expected receiver behavior when receiving a packet that does not
comply with `The ICMP Extension Structure MUST be zero-padded so that it ends
on a 4-byte boundary`?
### Section 4
Let's do it here as well s/Legacy implementations set the length field to
0./Legacy implementations set the length field to 0 per section 7 of RFC 4884./
Much bigger issue as this I-D cannot specify behavior of legacy
implementations, i.e., the following text is not correct and need to be fixed
```
Legacy implementation that do not recognize the ICMP Extension Header
length field MUST NOT process ICMP messages in which the ICMP
Extension structure may be followed by something else. This is
because they will not be able to parse the message correctly.
```
Should it be stated that legacy implementations will ignore whatever is *after*
the ICMP Extension Structure and should even completely reject it because the
reserved field is not 0 (RFC 4884 is rather silent but conservative legacy
implementations may reject it becasue Reserved != 0).
## NITS
### Use of SVG graphics
To make a much nicer HTML rendering, suggest using the aasvg too to generate
SVG graphics. It is worth a try especially if the I-D uses the Kramdown file
format ;-)
### Section 4
s/Legacy implementation that do not recognize /Legacy implementation*s* that do
not recognize /
_______________________________________________
Int-area mailing list -- int-area@ietf.org
To unsubscribe send an email to int-area-le...@ietf.org
