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

["Birrane, Edward J." <[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