On Thu, Oct 16, 2025 at 4:28 AM Eric Vyncke (evyncke) <[email protected]> wrote:
> Thank you for the work put into this document. Please find below my AD > review. > Hi Éric, thanks for your list of 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). > I wonder how to interpret "interoperability" in this context. Maybe this isn't an uppercase SHOULD at all. You include it if you need to include it because you don't have a unique address. The time not to include it is if you don't want to include it for secrecy reasons. This is intentionally vague to avoid overspecification - there's not necessarily a way to know that you don't have a unique address. And, I don't know how people will want to talk about their secrecy requirements - a list of IP addresses that you're allowed to send this info to is an obvious mechanism, but is certainly not the only possible one. "interoperability" doesn't really apply since it's not a wire protocol. "consistent behavior by nodes in a distributed network" is more what this SHOULD was going for - is that how the IESG statement should be interpreted in this context? > ### Section 3 Domain > > > > What is "domain" in `identify the node within the domain` ? > This is again intentionally vague. You need to use this if you have non-unique addresses - but imagine a deployment where you have a datacenter template with unique global addresses for each leaf and spine, but, that template gets reused for each data center - so within the data center "domain" you don't need to add the extension, but, if you exit the "domain" you do. It's possible that this is just trying to be too fancy and we should require something more like, if it is ever possible to have confusion based on non-unique IP addresses, then you add it (unless you don't want to for secrecy reasons). > ### C-Type > > > > Add a reference to section 8 of RFC 4884 for C-type > OK. ### 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 ? > I think I used SHOULD out of fear, it should be 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) > Good catch, I missed this when I added 3.1.1. ### Section 3.1.1 > > > > This text should rather be in the IANA consideration for the C-type for > the allocated class, i.e., 5. > The IANA considerations says As mentioned in Section 3.1.1, IANA is requested to assign additional bits starting at zero. I'm not inclined to move the text about how to process the packet to the IANA considerations section, and the reference to the assignment request is already there, so what exactly are you asking for? ### Section 4 > > > > `Further details of this mode of operation are outside the scope of this > memo.` s/memo/document/ > OK > And I would assume that basic MTU & fragmentation consideration should be > added. > Good point regarding the MTU; I lean towards prohibiting insertion. In a previous age I would have said SHOULD NOT insert if it results in the new packet exceeding the MTU, and let it be obvious that if you want to do it you have to deal with the consequences of fragmentation; now that you've pointed out the IESG statement I'm more inclined to say MUST NOT because I don't want to get into the details. ### 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 > OK > Also use a URI reference for `ICMP Extension Object Class` > Is the URL that you mention above the right URI to use? > > ## 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. > OK ### 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'. > OK > ### 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/ ? > Sure > ### Section 3 > > > > s/The extension defined herein/The extension defined herein, Node > Identification Object,/ > OK > It is also unclear why it is only "appended" rather than "included", must > this extension be the last extension? If so, why. > "appended" is just the word that RFC4884 and RFC5837 use. Would you be ok with "added"? > ### Section 3.3 > > > > The SVG tool seems to have an issue with the "o" of "homestar" in the > graphic. > Yeah, I struggled with the SVG tool. I'll struggle some more. > Unsure how to handle a 2-byte UTF-8 character whose 2nd octet would be the > 65th character of the name. > Good point. I wrote this: The node name MUST be represented in the UTF-8 charset {{RFC3629}} -using the Default Language {{RFC2277}}. +using the Default Language {{RFC2277}}. When truncating a name +to 63 octets, the truncation MUST occur on a character boundary +(e.g., if the 63rd octet is the first octet of a 2-octet character, +then the truncation will omit that octet altogether, and be padded +with an ASCII NUL character to reach the 4-octet boundary.) Is this clear, or, does it need more work? Perhaps it should move to the part before the example that talks about truncation in the first place, and talk about "include enough characters from sys:hostname to encode to a string of 63 octets or less"? ### 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). > Updated Bill
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
