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

[Jorge Amodio <[e-mail]>]

Got it, thanks Scott.

-Jorge

On Wed, Mar 29, 2023 at 12:32 AM <[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] <
> [e-mail]>
>
>
>
> 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
>
>