Last Call Review of draft-ietf-dtn-bpv7-admin-iana-03
review-ietf-dtn-bpv7-admin-iana-03-secdir-lc-orman-2024-08-31-00

Do not be alarmed.  I generated this review of this document as part
of the security directorate's ongoing effort to review all IETF
documents being processed by the IESG.  These comments were written
with the intent of improving security requirements and considerations
in IETF drafts.  Comments not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last call comments.

The document states 
"  The earlier Bundle Protocol (BP) Version 6 (BPv6) defined an IANA
   sub-registry for Administrative Record type code points under
   [IANA-BP].  When Bundle Protocol Version 7 (BPv7) was published in
   [RFC9171] it identified the IANA sub-registry for Administrative
   Record types but did not update the table to be explicit about which
   entries applied to which Bundle Protocol version(s).  The BPv7
   specification also did not discriminate between code point
   reservations and unassigned ranges for Administrative Record types.

   This document updates BPv7 to explicitly use the IANA Administrative
   Record type registry in Section 2.  This document makes a reservation
   of the zero value for consistency with BPv6.  This document also
   makes a reservation of high-valued code points for private or
   experimental use to avoid collisions with assigned code points."

Later, 

   "The code point allocated in Annex D of [CCSDS-BP] was never added to
   the IANA registry.  To avoid a collision, this document adds that
   allocation to the registry."
   
In Section 2, there this entry:

   +-----------------+------------+------------------+-----------------+
   | 6               | 4          | Aggregate        | [CCSDS-BP]      |
   |                 |            | Custody Signal   |                 |
   +-----------------+------------+------------------+-----------------+

which seems in direct conflict with RFC9171:

   +-----------------+---------+-------------------------+-----------+
   | 6               | 4       | Payload Confidentiality | [RFC6257] |
   |                 |         | Block                   |           |
   +-----------------+---------+-------------------------+-----------+

which seems to be a collision.  Also, there are so many deletions for BPv6
in this new version of the table that I feel that I do not understand
its purpose.  Presumably there is some legitimate reason for the
apparent collision.  Maybe it could be clarified.

I don't see security implications of the changes in the record types.

Hilarie