Re: [dtn] [EXT] Re: I-D Action: draft-ietf-dtn-ipn-update-01.txt

[[e-mail]]

Hi Rick,

On Wed, 29 Mar 2023, Rick Taylor wrote:

> As Ed points out, a "full qualified node-number" isn't actually a number,
> it's two numbers.
> 
> Any objection to "Full qualified node identifier" (FQNI)?

It is awfully close to NodeID.

Scott

> 
> Rick
> 
> 
> 
> On 29/03/2023 08:56, Rick Taylor wrote:
>       Top-posting as this thread has got long.
> 
> I'm with Scott B on this.  An IPN URI is made of
> authority-number.node-number.service-number, with each part named
> "*-number" because they are numbers ;)
> 
> If one needs to refer to the "unique identifier of a given node which
> is the concatenation of the authority-number and the node-number",
> then the term "full-qualified node-number" seems the most appropriate,
> as it captures the fact that it is the "node-number qualified by the
> authority-number", and there is precedent from DNS for the phrase
> "fully-qualified".
> 
> As regards confusion with the omission of the 0 authority-number (the
> default numbering authority) - I do not believe there are any cases
> where confusion can occur. While writing the draft and cross
> referencing with RFC9171, we found no cases beyond specifying the
> allocation policy of the node-number component itself where
> 'authority-relative node-numbers' are required.
> 
> Ed and I will wordsmith a little, and I think this will just drop out
> cleanly.  It may well solve the slightly awkward text around RFC9171
> NodeIDs and EIDs we have.
> 
> Cheers,
> 
> Rick
> 
> On 29/03/2023 06:32, [e-mail] wrote:
>
>       1.2.3 is the scheme-specific part of the URI.  That is,
>       ipn:1.2.3 is <scheme-name>:<scheme-specific part>; “1” is
>       the authority number element of the SSP, “2” is the node
>       number (or node numeral) element of the SSP, “3” is the
>       service number element of the SSP.
>
>        
>
>       In this case, “1.2” is a “fully qualified node number”.
>
>        
>
>       From: Jorge Amodio <[e-mail]>
>       Sent: Tuesday, March 28, 2023 10:05 PM
>       To: Birrane, Edward J. <[e-mail]>
>       Cc: Marc Blanchet <[e-mail]>; Scott
>       Burleigh <[e-mail]>; DTN WG <[e-mail]>
>       Subject: Re: [dtn] [EXT] Re: I-D Action:
>       draft-ietf-dtn-ipn-update-01.txt
> 
>  
> 
>  
> 
> I like it but what you name 3? 
> 
>  
> 
> And then what you name 1.2.3? Shouldn’t this one be the FQNN?
> 
> -Jorge
> 
> 
>
>       On Mar 28, 2023, at 9:40 PM, Birrane, Edward J.
>       <[e-mail]> wrote:
> 
>
>       <chair hat off>
>
>        
>
>       I like the term Fully Qualified Node Number (FQNN). 
>       “Fully Qualified” signals that the item is at least
>       somewhat complex so we should pay attention. “Node
>       Number” signals that we are talking about a single
>       thing,
>
>        
>
>       If we say that, I would further suggest removing the
>       term “node number” from any other part of the URI
>       scheme. Scott B. had previously used the term
>       “numeral” which I think works well for “the thing
>       assigned by the numbering authority”. 
>
>        
>
>       So, I propose:
>
>        
>
>       FQNN = numbering_authority_id +
>       numbering_authority_numeral
>
>        
>
>       For the example: ipn:1.2.3
>
>        
>
>       1 is the authority id
>
>       2 is the authority numeral
>
>       1.2 is the FQNN
>
>        
>
>       -Ed
>
>        
>
>        
>
>       From: dtn <[e-mail]> On Behalf Of Marc
>       Blanchet
>       Sent: Tuesday, March 28, 2023 10:33 AM
>       To: Scott Burleigh <[e-mail]>
>       Cc: DTN WG <[e-mail]>
>       Subject: Re: [dtn] [EXT] Re: I-D Action:
>       draft-ietf-dtn-ipn-update-01.txt
> 
>  
> 
> APL external email warning: Verify sender
> [e-mail] before clicking links or attachments
> 
>  
> 
>  
> 
> 
> 
>
>       Le 28 mars 2023 à 10:29,
>       <[e-mail]>
>       <[e-mail]> a écrit :
> 
>  
> 
> Hi.  Given that this question has come up in Rick’s
> presentation just now, let me offer a thought on the
> last issue on his last slide.
> 
>  
> 
> I think there will be a need for a term that
> signifies “the concatenation of authority number and
> node number.”  If we don’t provide one, people will
> make up their own; they will be different; there
> will be proliferation and confusion.
> 
>  
> 
> Since this thing – whatever we call it – will
> uniquely identify a BP node and nothing else, I
> think any term that omits the word “node” will be
> similarly confusing.  It’s true that we already have
> “node number” and “node ID” <sigh>, both of which
> mean different things from this.  That is
> unfortunate, but I don’t think we can let it drive
> us into even more baffling nomenclature.  
> 
>  
> 
> “Qualified node number” (vs ordinary, unqualified
> “node number”) is accurate, but I think people will
> find it too cumbersome to use routinely.
> 
>  
> 
> Erik suggested Fully Qualified …  It is a bit cumbersome,
> but in the IP/DNS world, the FQDN (fully qualified domain
> name) is actually used a lot and well understood. So to
> me, a good name is a good name. So I’m voting to Fully
> Qualified or Qualified…
> 
>  
> 
> MArc.
> 
>  
> 
> 
> 
>
>        
> 
> I suggest “node label.”   It’s brief.  It’s not
> inaccurate.  It’s not synonymous with “node ID” and,
> unlike “node numeral”, it is not precisely
> synonymous with “node number.”  It probably won’t be
> heavily used, but in the contexts for which it is
> useful I think it would be inoffensive.
> 
>  
> 
> Scott
> 
>  
> 
> From: Birrane, Edward J.
> <[e-mail]> 
> Sent: Wednesday, March 15, 2023 10:30 AM
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: [dtn] [EXT] Re: I-D Action:
> draft-ietf-dtn-ipn-update-01.txt
> 
>  
> 
> Scott,
> 
>  
> 
> I personally have no issue saying that “node number”
> is the term for the combination of
> “numbering-authority.node-numeral”. I know there was
> some concern about overloading “node” syntax with
> Node Identifier not being the same as Node Number
> not being the same as Node Numeral.
> 
>  
> 
> Would like to hear from the WG on this, perhaps as
> part of the discussion in the WG meeting.
> 
>  
> 
> -Ed
> 
>  
> 
>  
> 
> Edward J. Birrane, III, Ph.D. (he/him/his)
> 
> Chief Engineer, Space Constellation Networking
> 
> Supervisor, Embedded Applications Group 
> 
> Space Exploration Sector
> 
> Johns Hopkins Applied Physics Laboratory
> (W) 443-778-7423 / (C) 443-690-8272
> 
>  
> 
> From: [e-mail] <[e-mail]> 
> Sent: Wednesday, March 15, 2023 3:16 AM
> To: Birrane, Edward J.
> <[e-mail]>; [e-mail]; [e-mail]
> Subject: RE: [dtn] [EXT] Re: I-D Action:
> draft-ietf-dtn-ipn-update-01.txt
> 
>  
> 
> APL external email warning: Verify
> sender [e-mail] before clicking links
> or attachments
> 
>  
> 
> On the question of node ID vs EID: in a perfect
> world, we would have started out with node ID as a
> first-class concept, coequal with endpoint ID and
> distinctly defined; this question would not come
> up.  But our world is not perfect, and after much
> discussion of the impact of the alternatives it was
> decided that in RFC 9171 we would stick with the
> concept that a "Node ID" is simply a singleton EID:
> the EID identifies an endpoint, which is a set of
> nodes, and the sole occupant of that endpoint is the
> node that is implicitly identified.  This enables us
> to use an EID as the Source of a bundle: although
> the source of a bundle is always a single node, it
> can helpful to identify the service (e.g.,
> application) that further characterizes the source.
> 
>  
> 
> My only beef with this draft is that I still think
> there is value in explicitly distinguishing between
> "node number", which can be up to 64 bits in length,
> and "node numeral", my proposed term for the
> low-order 32 bits of a node number that includes an
> authority number.  Absent this distinction in
> language, I suspect we will stumble over ambiguity
> at some point.
> 
>  
> 
> Scott
> 
>  
> 
> ---------- Forwarded message ---------
> From: Birrane, Edward J. <[e-mail]>
> Date: Tue, Mar 14, 2023 at 9:58 AM
> Subject: Re: [dtn] [EXT] Re: I-D Action:
> draft-ietf-dtn-ipn-update-01.txt
> To: [e-mail] <[e-mail]>, [e-mail] <dtn@ietf.o
> rg>
> 
> 
> 
> Scott,
> 
>   I can add a few comments inline below, prefaced
> with EJB.
> 
> -Ed
> 
> 
> > Section 3. The ipn URI scheme
> > 
> > Given that the entire URI is comprised of two 64
> bit integers presently, and
> > in consideration for the historical unexpected
> requirement for
> > numbering/naming resources associated with the
> terrestrial internet, I am
> > confused as to why the proposed change shifts
> naming space from 64 bit
> > integer names to 32 bit integer names, as opposed
> taking those 32 bits from
> > service numbers.  
> 
> EJB:  Preserving "node identification information"
> in one 64-bit segment and services in a second 64
> bit segment was the consensus of this WG. The
> rationale, IIRC, was that it preserves backwards
> compatibility with existing encodings and software
> implementations.  I would welcome an example of the
> proposed segmentation of the 64 bit space leading to
> exhaustion.
> 
> > Section 3.1 Numbering Authorities
> > 
> > Can we have clarification on the administrative
> burden referred to?
> 
> EJB: It is a well-established principle that our
> best (only) tool against scaling is hierarchy. I
> will refer to the discussions on the WG prior, when
> the WG decided to adopt this proposal. Summarized,
> the consensus was that managing a flat, 64 bit,
> global registry of identity was not scalable. The
> nearest example of a scaled, "global" identifier was
> MAC addressing, which used hierarchy in the form of
> a manufacturer id. The ipn update takes a similar
> approach.
> 
> > The concept of Numbering Authorities also suggests
> the concept of
> > interconnection arrangements, perhaps dynamic,
> between Numbering
> > Authorities.  
> 
> EJB: I disagree. Section 3.1 says "Each NA is
> responsible for ensuring that any Node Numbers it
> allocates are unique. However, Node Numbers assigned
> by other NAs do not otherwise need to be coordinated
> or synchronized." Recall - node numbers (or
> numbering authority + node numbers) are identifiers.
> Not addresses. Implementers may, at their own risk,
> use identifiers as addresses, but to assign any
> meaning other than identification to them is an
> abuse of the concept. This perspective has been part
> of the ipn URI concept since its inception.
> 
> > Section 4.2
> > 
> > Note there is no Section 4.2.5.3 in RFC 9171. 
> This is puzzling, as it is not April
> > 1 yet.
> 
> EJB: Yes, I have noted several typos as well in this
> document.
> 
> > The draft seems to imply that "Node ID" = "EID". 
> 4.2.5.1 of 9171 defines EIDs
> > as URIs having this structure: < scheme name > : <
> scheme-specific part >
> > Since we are referring to the ipn scheme, <
> scheme-specific part > is
> > assumed to be ipn, but as written, the draft could
> refer to dtn scheme EIDs
> > as well.
> 
> EJB: I'm not sure I understand this read. Section
> 4.2 specifically mentions "ipn EIDs." The term ipn
> EID is defined earlier: An ipn URI used as a BPv7 or
> BPv6 EID is termed an "ipn EID."
> 
> > RFC 9171 Section 4.2.5.1.2 (The ipn URI Scheme)
> states:
> > 
> >     An ipn-scheme endpoint ID for which
> service-nbr is zero MAY identify
> >     the administrative endpoint for the node
> identified by node-nbr, and
> >     as such may serve as a node ID.  No ipn-scheme
> endpoint ID for which
> >     service-nbr is non-zero may do so.
> > 
> > Notwithstanding the former, I am reasonably sure
> that in implementations,
> > we do not want to populate Node Id fields
> inclusive of the < scheme name >
> > component, nor the service-nbr component of the
> <scheme-specific part>.
> > As such, it is most correct to say that for the
> ipn scheme, the Node ID can be
> > implied from the node-nbr component of the
> ipn-hier-part component of
> > the administrative endpoint EID, which itself is a
> conformant URI.
> 
> EJB: Rick and I went back and forth on this. I agree
> with you that your read makes more intuitive sense.
> BUT...that would involve rewriting the concept of
> NodeID in 9171, which is not the intent of the ipn
> URI update. As stated in 9171, the NodeID is
> expressed as an EID. But, happy to be misreading
> that.  Perhaps Scott Burleigh can chime in here.
> 
> > Draft section 4.4.1 seems to directly contradict
> draft section 4.2.
> > The latter would allow any EID to be a Node ID,
> while RFC 9171 and section
> > 4.4.1, reiteratively, strictly prohibit use of
> non-zero service-nbr values for
> > node identification.
> 
> EJB: Any ipn EID can be used for node
> identification. Non-zero service numbers cannot
> identify the administrative endpoint. The
> administrative endpoint != the only NodeId. From
> 9171 Section 4.2.5.2: The EID of any singleton
> endpoint is allowed to serve as a "node ID"
> identifying the node that is the sole member of that
> endpoint. So, ipn:100.1 *can* be a NodeID but
> *cannot* be an administrative endpoint.
> 
> EJB: This is an important point - RFC9171 requires
> every bundle source to be a NodeID. If the only
> NodeId were the administrative endpoint, then every
> bundle every created could only be sourced from a .0
> service. No one wants that.
> 
> 
> > Section 6.1 Scheme Compatibility
> > 
> > IMHO, this forces existing implementations to
> forward port to maintain
> > network wide interoperability, and existing
> networks to implement these
> > changes.  Will this not break legacy assets which
> are still in good working
> > order, but not able to be updated for a variety of
> reasonably good reasons?
> 
> EJB: I could ask the same question about a variety
> of work ongoing in the IETF or CCSDS. What about
> BPSec support? Or new security contexts? Or new
> extension block types? The ipn URI scheme update, by
> being backwards compatible has far fewer
> implementation issues. Recall, the 2-element
> scheme-specific encoding remains universal.
> Painfully inefficient in some situations, but
> universal.
> 
> 
> > Correct me if I am wrong, but as worded, there can
> be exactly 16 blocks of
> > authorities that can be allocated in total, if the
> first number of the block
> > must be a power of 2?  
> 
> EJB: Table 1 of Section 3.1.3 provides an example of
> how we would have more than 16 blocks of
> authorities.
> 
> 
> > I make this point to
> > illustrate that great care must be taken in IANA
> consideration sections,
> > particularly if you wish some advanced
> functionality to be encoded in the
> > numbering method.  I suspect that
> first-come/first-served is inappropriate
> > for this particular
> 
> EJB: Heartily agree here, and think it should be
> Expert Review at all times.
> 
> 
> > Section 8.2
> > 
> > I believe there are 6 other private sector
> stakeholders who are not
> > represented in this list.  Please consult the
> registry at IANA:
> > https://www.iana.org/assignments/bundle/bundle.xhtml#cbhe-node-
> > numbers
> 
> EJB: Agreed. The intent is the same, which is to
> migrate the IANA registry over as it exists at the
> time of migration. Again, the point of the Default
> Numbering Authority is to maintain backward
> compatibility. 
> 
> 
> > Section 8.3
> > 
> > I think this reorganization is a bit light on the
> opportunity for standard
> > side services, and heavy on the private use side
> services, particularly
> > when keeping a 64 bit service-nbr.
> 
> EJB:  Very open to discussion on how to rebalance
> these ranges.
> 
> 
> > 
> > On Mon, 13 Mar
> 2023, [e-mail] wrote:
> > 
> > >
> > > A New Internet-Draft is available from the
> on-line Internet-Drafts
> > > directories. This Internet-Draft is a work item
> of the Delay/Disruption
> > > Tolerant Networking (DTN) WG of the IETF.
> > >
> > >   Title           : Update to the ipn URI scheme
> > >   Authors         : Rick Taylor
> > >                     Ed Birrane
> > >   Filename        :
> draft-ietf-dtn-ipn-update-01.txt
> > >   Pages           : 26
> > >   Date            : 2023-03-13
> > >
> > > Abstract:
> > >   This document updates both the specification
> of the ipn URI scheme
> > >   previously defined in [RFC7116] and the rules
> for encoding of these
> > >   URIs when used as an Endpoint Identifier (EID)
> in Bundle Protocol
> > >   Version 7 (BPv7) as defined in [RFC9171]. 
> These updates update and
> > >   clarify the structure and behavior of the ipn
> URI scheme, define
> > >   encodings of ipn scheme URIs, and establish
> the registries necessary
> > >   to manage this scheme.
> > >
> > > The IETF datatracker status page for this
> Internet-Draft is:
> >
> > https://datatracker.ietf.org/doc/draft-ietf-dtn-ipn-update/
> > >
> > > There is also an HTML version available at:
> >
> > https://www.ietf.org/archive/id/draft-ietf-dtn-ipn-update-01.html
> > >
> > > A diff from the previous version is available
> at:
> >
> > https://author-tools.ietf.org/iddiff?url2=draft-ietf-dtn-ipn-update-01
> > >
> > > Internet-Drafts are also available by rsync
> at rsync.ietf.org::internet-drafts
> > >
> > >
> > > _______________________________________________
> > > dtn mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/dtn
> > >
> > 
> > _______________________________________________
> > dtn mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dtn
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn
> 
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn
> 
>  
> 
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn
> 
> 
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn
> 
> 
> 
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn
> 
> 
> 
>