Looks good to me. Thanks Bill.
L. > On 6 Aug 2025, at 14:00, Bill Fenner <fen...@fenron.com> wrote: > > A slight rewrite, and a third sentence added since I thought "should this be > prohibited?" in my previous email, and someone else might have that same > thought, so wanted to make it explicit - > > The goal of these specifications is to have a mechanism to provide additional > useful information about the identification of a node sending an ICMP error, > which depends on the actual context and scope of the message being delivered. > 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. It is > explicitly permitted to use an IP address that may have only local meaning > (e.g., ULA), since that information can then be provided to the operator of > the domain who can then determine the local meaning. > > What do you think? > Billl > > On Tue, Aug 5, 2025 at 4:43 AM Luigi Iannone <g...@gigix.net > <mailto:g...@gigix.net>> wrote: >> 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 <fen...@fenron.com >>> <mailto:fen...@fenron.com>> wrote: >>> >>> On Wed, Jul 16, 2025 at 5:31 AM Luigi Iannone <g...@gigix.net >>> <mailto:g...@gigix.net>> 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 >>> >>
_______________________________________________ Int-area mailing list -- int-area@ietf.org To unsubscribe send an email to int-area-le...@ietf.org
