Bill, Reji, Luigi, and intarea Working Group, # Éric Vyncke, INT AD, AD review for draft-ietf- CC @evyncke
Thank you for the work put into this document. Please find below my AD review. As the responsible AD, I expect all the points below to be addressed, either by a revised I-D, or an email reply. Of course, authors and WG can reject my points, but this needs to be justified. Once all the points are addressed, I will proceed with the publication process, i.e., IETF Last Call. Special thanks to Luigi Iannone for the shepherd's *very clear* write-up including the WG consensus and the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric ## Critical issues ### Section 3 SHOULD Per https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/, explanations about when the "SHOULD" can be bypassed (I note that there is a `whenever` but this does not seem to cover all cases). ### Section 3 Domain What is "domain" in `identify the node within the domain` ? ### C-Type Add a reference to section 8 of RFC 4884 for C-type ### Section 3.1 SHOULD Per https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/, explanations about when the "SHOULD" can be bypassed, i.e., why not a MUST ? ### Section 3.1 When other extensions will be defined, will this statement be still valid ? `Any data that follows these optional pieces of information MUST be ignored.` Please add some text around "unless other bits in C-flag are set" or similar (and add a forward reference to 3.1.1 -- see also comment below) ### Section 3.1.1 This text should rather be in the IANA consideration for the C-type for the allocated class, i.e., 5. ### Section 4 `Further details of this mode of operation are outside the scope of this memo.` s/memo/document/ And I would assume that basic MTU & fragmentation consideration should be added. ### Section 6 Please request the creation of `The corresponding Class Sub-types Registry ` as it is not yet at https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml#icmp-parameters-ext-classes Also use a URI reference for `ICMP Extension Object Class` ## Non-critical / cosmetic issues Note: these points must also be addressed. ### Title Possibly a matter of taste, but s/Adding Extensions to ICMP Errors for Originating Node Identification/ICMP Message Extension for Originating Node Identification/ is probably clearer. ### Nexthop or Next-Hop As the abstract use `next-hop`, let's be consistent and let's use 'next-hop' everywhere rather than 'next-hop'. ### Section 1 s/traceroute to an IPv4 destination can not represent intermediate IPv6-only routers/traceroute to an IPv4 destination can not display an intermediate IPv6-only routers as it does not have an IPv4 address/ ? ### Section 3 s/The extension defined herein/The extension defined herein, Node Identification Object,/ It is also unclear why it is only "appended" rather than "included", must this extension be the last extension? If so, why. ### Section 3.3 The SVG tool seems to have an issue with the "o" of "homestar" in the graphic. Unsure how to handle a 2-byte UTF-8 character whose 2nd octet would be the 65th character of the name. ### Reference The draft reference draft-equinox-v6ops-icmpext-xlat-v6only-source (version 02) is stale. It was replaced by draft-ietf-v6ops-icmpext-xlat-v6only-source (version 00). ### Use of SVG graphics Thanks for having SVG graphics (figure 1).
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
