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

[[e-mail]]

Hi Rick,

That certainly clarifies the situation in my mind.  Thanks, I appreciate 
it!

Scott

On Wed, 7 Feb 2024, Rick Taylor wrote:

> Hi Scott,
>
> One of the purposes of wanting to "update" RFC7116 was to absolutely
> clarify the situation as regards applicability with different bundle
> protocol versions, as you are correct that there is no IRTF/IETF guidance.
>
> The main point of discussion here is about IETF process: obsoleting IRTF
> documents by the IETF is considered unusual. Finding a simple way around
> this, such as not obsoleting 7116 is an approach we could consider, it's
> just a matter of determining a valid reason why the ipn update doesn't
> obsolete 7116.
>
> My assertion is that ipn-update could avoid obsoleting 7116 (if
> absolutely necessary) because 7116 could be seen as a BPv6-only
> document, and the ipn-update is a BPv7-only document, and hence no
> change of status of 7116 need be required.  This assertion was based on
> the following:
>
> 1. IETF BPv7 did not exist at the time of publication of IRTF RFC 7116,
> and 7116 explicitly mentions RFC 5050 (IRTF BPv6)
>
> 2. The part of ipn-update that impacts RFC 7116 are the "CBHE"
> registries, and Compressed Bundle Header Encoding (CBHE) is not used in
> BPv7.
>
>
> No matter the outcome, the WG and IESG are clear that existing IPN
> registrations in the registry created in 7116 will be remain in any
> new/renamed registry and therefore continue to be valid for
> interoperable use with BPv7.
>
> I would prefer not to "fork" the CBHE registry, and therefore prefer to
> find an alternate way through the process.  But, however undesirable
> having two possibly diverging registries may be, given the lack of
> interoperability between BPv6 and BPv7, there would be no technical
> issue with forking.
>
> It should also be noted the Russ's concern was that ipn-update only
> obsoletes some of RFC7116, and therefore an informational companion
> document perhaps should exist to cover any other affected parts of
> RFC7116, rather than the act of obsoleting 7116 per-se.
>
> I believe CCSDS are currently updating LTP, and hence those sections of
> RFC7116 may become out of date in some way.  Perhaps a CCSDS/LTP
> contributor might step forwards to help update the rest of 7116?
>
> Meanwhile, Zahed is taking the topic to the IESG to see if there is some
> pragmatic way forwards.
>
> Hope that helps?
>
> Rick
>
>
> On 06/02/2024 01:58, [e-mail] wrote:
>> 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
>>>
>>>
>>>
>
>