FYI, CCSDS is in the process of re-confirming CCSDS 734.1-B-1 (LTP for CCSDS) as part of the 5-years review cycle. There are no updates to the normative part of the document planned; just couple of comments and recommendations will be added. As 734.1-B-1 includes normative references to 7116 I would prefer a solution which would avoid obsoleting 7116. Regards, Felix -----Original Message----- From: dtn <dtn-bounces@xxxxxxxx> On Behalf Of Rick Taylor Sent: Wednesday, February 7, 2024 12:46 PM To: scott@xxxxxxxxxxxxxxx Cc: Russ Housley <housley@xxxxxxxxxxxx>; gen-art@xxxxxxxx; draft-ietf-dtn-ipn-update.all@xxxxxxxx; dtn@xxxxxxxx; last-call@xxxxxxxx Subject: Re: [dtn] Genart last call review of draft-ietf-dtn-ipn-update-09 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, scott@xxxxxxxxxxxxxxx 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 >> >> >> _______________________________________________ dtn mailing list dtn@xxxxxxxx https://www.ietf.org/mailman/listinfo/dtn This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo@xxxxxxx). -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
