Hi Russ,
Thank you for the prompt review, comments inline...
On 01/02/2024 22:18, Russ Housley via Datatracker wrote:
Reviewer: Russ Housley Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-dtn-ipn-update-09 Reviewer: Russ Housley Review Date: 2024-02-01 IETF LC End Date: 2024-02-12 IESG Telechat date: unknown Summary: Not Ready 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, 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.
+1. I think I took the same wording from one of the IANA recommendations RFCs, but valid point re Sample code.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.
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...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.
+1. I thought I was being more "correct" by referring to the ABNF sources, but I share your preference to a self-contained definition.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.
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
