[Int-area] Re: Shepherd Review for draft-ietf-intarea-extended-icmp-nodeid-02

[Luigi Iannone <[e-mail]>]

Hi Bill,

thanks for the reply.

I would not go for an ordering, as you suggest at the end of your mail, as we may end up overengineering the specs.

What about keeping it simple and adding in the intro some simple definiontion?

Starting from text in your email, after the uses cases in the intro,  you can add something like:

	The goal of these specifications is to have a mean to provide additional useful information about node identification, which depends on the actual context. and scope.

Then somenthing like:

	To this end, it is RECOMMENDED to use a combination of IP Address and Name sub-objects (including combinations where one of the sub-objects is not used) that is unique and meaningful in the actual context and scope.


Or something similar. Those three lines make clear to me how I should implement and use these specs.

What do you think?

Ciao

L.


> On 3 Aug 2025, at 22:00, Bill Fenner <[e-mail]> wrote:
> 
> On Wed, Jul 16, 2025 at 5:31 AM Luigi Iannone <[e-mail] <mailto:[e-mail]>> wrote:
>> Dear Authors,
>> 
>> thanks forwriting this document, which is quite clear.
>> As a shepherd I went through the document and have a few comments.
>> 
>> 
>> I think the the definition of _unique_ Node ID is a bit hidden in the document and not clearly spelled out.
>> The second paragraph of the abstract is close but not perfect.
>> 
>> My understanding is the following:
>> 
>> The _combination_ of IP Address and Name sub-objects MUST be unique.
>> If the IP Address sub-object is NOT included, then the Name sub-object MUST be unique.
>> Vice versa, if the Name sub-object is NOT included, then the IP Address sub-object MUST be unique.
>> 
>> Is my understanding correct? 
>> Further, _uniqueness_ is relative to the local domain?  Or a different scope? 
>> 
>> Can text be added somewhere in the document to clearly define the above?
> 
> Hi Luigi,
> 
> There's an art to describing a problem like this without being over-proscriptive, and I clearly haven't landed on the right spot yet.
> 
> The goal here is a little fuzzy: when you don't have some useful information, provide some useful information. The problem is that useful depends on the context.  We can sketch out a few contexts:
> - for the ICMP translator case, it's clear: use the IPv6 source address of the packet you're translating
> - in the case that a node is configured to insert this extension into all packets, a globally-unique IPv6 address is the only thing that makes sense, and the node name is optional additional information
> - in the case that you're just inserting the extension into packets staying within your domain (e.g., something that's explicitly identified as your NMS), then it's domain-specific what you want to add - it should be unique within the domain but it's sensible for it to be a ULA (since that should be meaningful in the context).
> 
> Maybe a preference order makes sense?
> 1. Globally-unique IPv6 address, if you have one
> 2. Locally-relevant IPv6 address (e.g., ULA), if you don't
> 3. If you wouldn't use this IPv6 address as a source address to send to the ICMP message destination, you ... probably? ... shouldn't put it in the extension?  (But, if it's a ULA, it's still unique, even if not meaningful, so can be used to distinguish node A from node B even if you don't know anything about them - and, you can provide it to the relevant NOC, so this is an example of something that shouldn't be prohibited even though maybe it sounds like it's wrong at first glance)
> 4. If you have no IPv6 address, then the name becomes the canonical answer and should be unique, otherwise, it's ancillary information
> 
> Discussion is welcomed.
> 
> Regarding your other points, the "author's copy" in github https://fenner.github.io/icmp-node-id/ is updated with my proposed updates.
> 
> Thanks,
>   Bill
>