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

[[e-mail]]

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] <mailto:[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] <mailto:[e-mail]> > On Behalf Of Marc Blanchet
Sent: Tuesday, March 28, 2023 10:33 AM
To: Scott Burleigh <[e-mail] <mailto:[e-mail]> >
Cc: DTN WG <[e-mail] <mailto:[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] <mailto:[e-mail]>  before clicking links or attachments

 

 






Le 28 mars 2023 à 10:29, <[e-mail] <mailto:[e-mail]> > <[e-mail] <mailto:[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] <mailto:[e-mail]> > 
Sent: Wednesday, March 15, 2023 10:30 AM
To: [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[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] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> > 
Sent: Wednesday, March 15, 2023 3:16 AM
To: Birrane, Edward J. <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> >, [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[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 <http://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] <mailto:[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 <http://rsync.ietf.org/> ::internet-drafts
> >
> >
> > _______________________________________________
> > dtn mailing list
> > [e-mail] <mailto:[e-mail]> 
> > https://www.ietf.org/mailman/listinfo/dtn
> >
> 
> _______________________________________________
> dtn mailing list
> [e-mail] <mailto:[e-mail]> 
> https://www.ietf.org/mailman/listinfo/dtn
_______________________________________________
dtn mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/dtn

_______________________________________________
dtn mailing list
 <mailto:[e-mail]> [e-mail]
 <https://www.ietf.org/mailman/listinfo/dtn> https://www.ietf.org/mailman/listinfo/dtn

 

_______________________________________________
dtn mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/dtn