Re: [dtn] Genart last call review of draft-ietf-dtn-ipn-update-09

[[e-mail]]

Hi Rick,

On Fri, 2 Feb 2024, Rick Taylor wrote:

> Major Concerns:
> 
> RFC 7116 is an Informational RFC, and this document, if approved, will
> be published an an RFC on the standards track.  It is very unusual for
> a standards-track RFC to update an Informational RFC.  I suggest that
> this document and a companion document ought to obsolete RFC 7116, where
> the companion document separately handles all of the non-ipn topics in
> RFC 7116.  The companion document can be an informational RFC.
> 
> Yes, I can see your point.  We have had this problem before in the IETF WG
> where we have updated IRTF documents that are almost always Informational.
> 
> Given RFC7116 only describes behaviours and registries for BPv6,

Could you provide the basis for this assertation, as there are presently 
BP networks which are using CBHE Node Numbers for BPv7 operation, absent 
any other official guidance on the matter.  I understand that RFC7116 was 
produced circa the period when BPv6 was the most recent version, but I 
have been able to find no relevant document delineating 7116 as BPv6 
only, nor in 7116 itself.

Thanks,
Scott

> and this
> draft only discusses BPv7, we may be able to introduce "new" registries
> (with exactly the same content as the CBHE registries) for BPv7, without
> updating the CBHE registries, therefore not officially "obsoleting" or
> "updating" RFC7116. This seems a lot like the tail wagging the dog, but I
> can see it solving a process issue. I'll discuss with Zahed for advice.
> 
> 
> Minor Concerns:
> 
> Section 3.4.3: Since these "private use" node numbers all have zero assigned
> the Allocator Identifier, not one can tell where the administrative domain
> boundaries are located.  This needs to be discussed in the Security
> Considerations, and this section should point to that new text.  That said,
> the discussion in Section 5.5 is probably fine.  A node that is at the edge
> of an administrative domain needs to be configured to not let "private use"
> node numbers exit the domain.
> 
> Good point.  I will review the text and add something to the security
> considerations, and definitely cross reference better.
> 
> 
> Section 9.1: I envision the example range being used in a manner similar
> to the use of Autonomous System (AS) Numbers 64496 through 64511, which
> are reserved for use in documentation and sample code.  Please expand
> the explanation to include sample code.  Likewise for the example range
> in Section 9.3.
> 
> +1.  I think I took the same wording from one of the IANA recommendations
> RFCs, but valid point re Sample code.
> 
> 
> Section 9.2: I am not sure that the last row of Table 4 is needed.  At
> the front of the section, say that the valid range is 0 to 2^32-1.
> 
> My preference was to state the max/invalid range in the table as CBOR
> integers are definitely 64-bit, and it felt a bit unclear your suggested way
> round.  Let me give it another try and see how it feels...
> 
> 
> Appendix A: It would take less space in this document to define DIGIT
> than to explain where to find the definition.  Adding "DIGIT = %x30-39"
> make the ABNF complete.
> 
> +1.  I thought I was being more "correct" by referring to the ABNF sources,
> but I share your preference to a self-contained definition.
> 
> 
> 
> Nits:
> 
> Abstract: s/These updates update and clarify/These updates clarify/
> 
> Section 3.4.2: s/ipn URIs of this form are termed "LocalNode ipn URIs"/
>                 /This form of ipn URI is termed a "LocalNode ipn URI"/
> 
> Section 5: s/The IRTF standardisation of the experimental BPv6/
>             /The IRTF BPv6 experimental specification/
>             (The IRTF does not publish standards.)
> 
> Section 5.5: s/they MUST NOT/
>               /"private use" node numbers associated with Default Allocator 
> MUST NOT/
> 
> Section 7.2: s/where-by/whereby/
> 
> Section 7.2: s/hop by hop/hop-by-hop/
> 
> All good catches!
> 
> I will update and push out a new version shortly, but I will hold until
> after the weekend in case other reviews come back quickly, as I don't want
> to disturb any in-progress reviews with rapid churn.
> 
> Cheers,
> 
> Rick
> 
> 
>