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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
