Skip to main content

Last Call Review of draft-ietf-dtn-ipn-update-09
review-ietf-dtn-ipn-update-09-genart-lc-housley-2024-02-01-00

Request Review of draft-ietf-dtn-ipn-update
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2024-02-12
Requested 2024-01-29
Authors Rick Taylor , Edward J. Birrane
I-D last updated 2024-02-01
Completed reviews Genart Last Call review of -09 by Russ Housley (diff)
Genart Telechat review of -11 by Russ Housley
Artart Last Call review of -09 by Marco Tiloca (diff)
Opsdir Last Call review of -09 by Tim Wicinski (diff)
Assignment Reviewer Russ Housley
State Completed
Request Last Call review on draft-ietf-dtn-ipn-update by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/O1NgMdXNZql9r6vhymD4qwIfHXg
Reviewed revision 09 (document currently at 11)
Result Not ready
Completed 2024-02-01
review-ietf-dtn-ipn-update-09-genart-lc-housley-2024-02-01-00
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.


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.

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.

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.

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/