(Belated) Happy New Year, When can I expect a revised I-D and/or email reply addressing all the points in my AD review ?
Regards -éric PS: I will be away from the keyboard for most of January starting next week. From: Eric Vyncke (evyncke) <[email protected]> Date: Friday, 5 December 2025 at 13:33 To: Bill Fenner <[email protected]>, [email protected] <[email protected]> Cc: [email protected] <[email protected]> Subject: [Int-area] Re: AD review of draft-ietf-intarea-extended-icmp-nodeid-04 Bill, With IETF-124 shortly after this e-mail thread, it seems that we collectively have dropped the ball :-( Beside the discussion about RFC 7915 between Jen and Bill, there are open questions to me below, therefore please look for EV> in-line. A lot of COMMENTs were accepted by the authors, so, do not forget to upload a revised I-D as I would like to run the IETF Last Call before the end of the year. Regards -éric From: Bill Fenner <[email protected]> Date: Tuesday, 21 October 2025 at 17:00 To: Eric Vyncke (evyncke) <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, Luigi Iannone <[email protected]> Subject: Re: AD review of draft-ietf-intarea-extended-icmp-nodeid-04 On Thu, Oct 16, 2025 at 4:28 AM Eric Vyncke (evyncke) <[email protected]<mailto:[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? EV> interoperability can be seen as the source and recipient of the ICMP Node ID though EV> why not s MUST in `SHOULD be appended whenever required to identify the node and when local policy or security considerations do not supersede this requirement` As there is a constraint on the potential MUST with the `whenever`, I think that MUST is more suitable than a SHOULD. ### 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). EV> two ways forward: EV> 1) remove simply `in the domain` EV> 2) or use `to allow identification by the recipient`. ### 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. EV> indeed (and this is quite often the case in IETF drafts 😉 ) ### 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? EV> fair enough, leave it like it is ### 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? EV> correct ### Section 3 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"? EV> "added" sounds indeed better. ### 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. EV> I wish you the best 😉 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"? EV> the former is OK and the latter is even simpler.
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
