<?xml version="1.0" encoding="UTF-8"?>
<?rfc toc="yes"?>

<!DOCTYPE rfc [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true" docName="draft-ietf-dtn-bpv7-admin-iana-04" number="9713" ipr="trust200902" submissionType="IETF" tocInclude="true" symRefs="true" sortRefs="true" updates="9171" version="3"> obsoletes="" version="3" xml:lang="en">
  <front>
    <title abbrev="BPv7 Admin IANA">
Bundle IANA">Bundle Protocol Version 7 Administrative Record Types Registry
    </title> Registry</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-dtn-bpv7-admin-iana-04"/> name="RFC" value="9713"/>
    <author fullname="Brian Sipos" initials="B." surname="Sipos">
      <organization abbrev="JHU/APL">The Johns Hopkins University Applied Physics Laboratory</organization>
      <address>
        <postal>
          <street>11100 Johns Hopkins Rd.</street>
          <city>Laurel</city>
          <region>MD</region>
          <code>20723</code>
          <country>United States of America</country>
        </postal>
        <email>brian.sipos+ietf@gmail.com</email>
      </address>
    </author>
    <date/>
    <area>Transport</area>
    <workgroup>Delay-Tolerant Networking</workgroup>
    <date year="2025" month="January"/>
    <area>INT</area>
    <workgroup>dtn</workgroup>
    <keyword>DTN</keyword>
    <abstract>
      <t>
<!-- [rfced] Initially, we found this text unclear because we questioned whether the BPv7 agent was using the IANA registry to document Administrative Record types or whether the agent was using the IANA registry itself.  We believe both may be true.  Please review whether the following possible update is accurate.

Original:
   This document updates RFC 9171 to clarify that a Bundle Protocol
   Version 7 agent is intended to use an IANA registry for
   Administrative Record types. It also makes a code point reservations
   for private and experimental use.

Perhaps:
   This document updates RFC 9171 to clarify that Bundle Protocol Version 7
   agents are expected to use the IANA "Bundle Administrative Record Types"
   registry to identify and document Administrative Record types. This
   document also designates code points for Private and Experimental Use.
-->
      <t>
This document updates RFC 9171 to clarify that a Bundle Protocol Version 7 agent is intended to use an IANA registry for Administrative Record types.
It also makes code point reservations for Private and Experimental Use.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="sec-intro">
      <name>Introduction</name>
<!-- [rfced] As we believe the "earlier Bundle Protocol (BP) Version 6 (BPv6)" refers to the version specified in RFC 5050, and becauase the relevant registry seems to have been created per RFC 7116, we suggest the following update.  Please review and let us know if this update is acceptable.

Original:
   The earlier Bundle Protocol (BP) Version 6 (BPv6) defined an IANA
   registry for Administrative Record type code points under [IANA-BP].

Perhaps:
   [RFC7116] defined an IANA registry for Administrative Record type code
   points [IANA-BP] for use with the Bundle Protocol (BP)
   Version 6 (BPv6) [RFC5050].
-->
      <t>
The earlier Bundle Protocol (BP) Version 6 (BPv6) defined an IANA registry for Administrative Record type code points under <xref target="IANA-BP"/>.
When Bundle Protocol Version 7 (BPv7) was published in <xref target="RFC9171"/> target="RFC9171"/>, it identified the IANA 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.
      </t>
      <t>
This document updates BPv7 to explicitly use the IANA Administrative Record type registry as described in <xref target="sec-bpv7-admin-type"/>.
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 use Private Use and experimental use Experimental Use in accordance with <xref target="RFC8126"/> to avoid collisions with assigned code points.
      </t>
      <section>
        <name>Scope</name>
        <t>
This document describes updates to the IANA "Bundle Administrative Record type Types" registry and how a BPv7 agent is supposed to use that registry for identifying to identify Administrative Record types.
        </t>
<!-- [rfced] Does "overlapping code points" mean code points that are used for both BPv6 and BPv7?  For clarity, please consider whether the following correctly conveys the intended meaning.

Original:
   This document does not specify how BPv6 and BPv7 can interoperate for
   overlapping code points or how a specific code point is to be
   interpreted either similarly or differently between Bundle Protocol
   versions.  It is up to each individual Administrative Record type
   specification to define how it relates to each BP version.

Perhaps:
   This document does not specify how BPv6 and BPv7 can interoperate
   when both use the same code points or how a specific code point is to be
   interpreted either similarly or differently by Bundle Protocol
   versions.  The specification for each Administrative Record type is to
   define how the Administrative Record type relates to each BP version.
-->
        <t>
This document does not specify how BPv6 and BPv7 can interoperate for overlapping code points or how a specific code point is to be interpreted either similarly or differently between Bundle Protocol versions.
It is up to each individual Administrative Record type specification to define how it relates to each BP version.
        </t>
      </section>
      <section anchor="sec-terminology">
        <name>Terminology</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>
      </section>
    </section>
    <section anchor="sec-bpv7-admin-type">
      <name>Administrative Record Types Registry</name>
      <t>
This document updates the requirements in <xref section="6.1" target="RFC9171"/> to specify use of an existing IANA registry and updates that registry as described in <xref target="sec-iana-bp-admin-type"/>.
      </t>
      <t>
The code point allocated in Annex D of <xref target="CCSDS-BP"/> was never added to the IANA registry.
To avoid a collision, this document adds that allocation to the registry.
      </t>
<!-- [rfced] We are having trouble parsing this text.  Please clarify.

Original:
   Instead of using the list of types in Section 6.1 of [RFC9171], a
   BPv7 administrative element SHALL interpret administrative record
   type code values in accordance with the IANA "Bundle Administrative
   Record Types" registry under [IANA-BP] for entries having a "Bundle
   Protocol Version" of 7.

Perhaps A:
   Instead of using the list of types in Section 6.1 of [RFC9171], a
   BPv7 administrative element SHALL use administrative record
   type code values as registered in the IANA "Bundle Administrative
   Record Types" registry [IANA-BP].  BPv7 administrative elements
   may use the code points marked with "7" in the Bundle Protocol
   Version column.

Or perhaps B:
   Instead of using the list of types in Section 6.1 of [RFC9171], a
   BPv7 administrative element SHALL determine which administrative
   record type code values can be used by the "7" noted in the Bundle
   Protocol Version column of the IANA "Bundle Administrative Record Types"
   registry [IANA-BP].
-->
      <t>
Instead of using the list of types as described in <xref section="6.1" target="RFC9171"/>, a BPv7 administrative element <bcp14>SHALL</bcp14> interpret administrative record type code values in accordance with the IANA "Bundle Administrative Record Types" registry under <xref target="IANA-BP"/> for entries having a "Bundle Protocol Version" of 7.
      </t>

<!-- [rfced] This is the only occurrence of BPA.  May we change this to "bundle protocol agent"?

Original:
   The processing of a received administrative record ADU
   does not affect the fact that the bundle itself was delivered to the
   administrative element or any related BPA processing of (e.g. status
   reports on) the enveloping bundle.
-->

      <t>
If an administrative element receives a not-well-formed application data unit (ADU) or an administrative record type code which that is not able to be processed by the element, the record <bcp14>SHALL</bcp14> be ignored by the element.
The processing of a received administrative record ADU does not affect the fact that the bundle itself was delivered to the administrative element or any related BPA processing of (e.g. (e.g., status reports on) the enveloping bundle.
      </t>
    </section>
    <section anchor="sec-security">
      <name>Security Considerations</name>
      <t>
This document does not define any requirements or structures which that introduce new security considerations.
      </t>
      <t>
The existing security considerations of <xref target="RFC9171"/> still apply when using the IANA "Bundle Administrative Record Types Types" registry.
      </t>
    </section>
    <section anchor="sec-iana">
      <name>IANA Considerations</name>
      <t>
This specification modifies a BPv6 registry to extend by extending it for BPv7.
      </t>
      <section anchor="sec-iana-bp-admin-type">
        <name>Bundle Administrative Record Types</name>
        <t>
Within the "Bundle Protocol" registry group <xref target="IANA-BP"/>, the "Bundle Administrative Record Types" registry has been updated to include a leftmost "Bundle Protocol Version" column.
New entries have been added and existing entries have been updated to have include BP versions as in the following table. <xref target="tab1"/>.
This document makes no changes to the registration procedures for this registry.
        </t>
        <table>
        <table anchor="tab1">
          <name>Bundle Administrative Record Types</name>
          <thead>
            <tr>
              <th>Bundle Protocol Version</th>
              <th>Value</th>
              <th>Description</th>
              <th>Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td>6,7</td>
              <td>0</td>
              <td>Reserved</td>
              <td>
                <xref target="RFC7116"/>
                [This specification]
                RFC 9713
              </td>
            </tr>
            <tr>
              <td>6,7</td>
              <td>1</td>
              <td>Bundle status report</td>
              <td>
                <xref target="RFC5050"/>
                <xref target="RFC9171"/>
              </td>
            </tr>
            <tr>
              <td>6</td>
              <td>2</td>
              <td>Custody signal</td>
              <td>
                <xref target="RFC5050"/>
              </td>
            </tr>
<!-- [rfced] Because values 3 and 5-15 are unassigned, is it correct for the Bundle Protocol Versions to be noted as 6,7?  Does this imply that 6 and 7 must apply to future assignments of those values (i.e., 6,7 apply to unassigned values defined by BPv6, and 7 (only) applies to all other future assignments as values 16+ are defined for BPv7)?

From Table 1:
    | 6,7             | 3        | Unassigned       |                 |
    | 6,7             | 5 to 15  | Unassigned       |                 |
-->

            <tr>
              <td>6,7</td>
              <td>3</td>
              <td>Unassigned</td>
              <td/>
            </tr>
            <tr>
              <td>6</td>
              <td>4</td>
              <td>Aggregate Custody Signal</td>
              <td>
                <xref target="CCSDS-BP"/>
              </td>
            </tr>
            <tr>
              <td>6,7</td>
              <td>5 to - 15</td>
              <td>Unassigned</td>
              <td/>
              <td colspan="2">Unassigned</td>
            </tr>
            <tr>
              <td>7</td>
              <td>16 to - 64383</td>
              <td>Unassigned</td>
              <td/>
              <td colspan="2">Unassigned</td>
            </tr>
            <tr>
              <td>7</td>
              <td>64384 to - 64511</td>
              <td>Reserved for experimental use</td>
              <td>[This specification]</td> Experimental Use</td>
              <td>RFC 9713</td>
            </tr>
            <tr>
              <td>7</td>
              <td>64512 to - 65535</td>
              <td>Reserved for private use</td>
              <td>[This specification]</td> Private Use</td>
              <td>RFC 9713</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

        <reference anchor="IANA-BP" target="https://www.iana.org/assignments/bundle/">
          <front>
            <title>Bundle Protocol</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date/>
          </front>
        </reference>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9171.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9171.xml"/>

      </references>

      <references>
        <name>Informative References</name>

        <reference anchor="CCSDS-BP" target="https://public.ccsds.org/Pubs/734x2b1.pdf">
          <front>
            <title>CCSDS Bundle Protocol Specification</title>
            <seriesInfo name="CCSDS" value="734.2-B-1"/>
            <author>
              <organization>Consultative Committee for Space Data Systems</organization>
            </author>
            <date month="September" year="2015"/>
          </front>
	  <refcontent>CCSDS Recommended Standard</refcontent>
          <seriesInfo name="CCSDS" value="734.2-B-1"/>
        </reference>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5050.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5050.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7116.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7116.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
      </references>
    </references>

<!-- [rfced] Throughout the text, the following terminology appears to be used
inconsistently. May we lowercase these for consistency with RFC 9171, which seems to use lower case except when referring to the name of the IANA registry.

Administrative Record types
administrative record type code values
Administrative Record type code points
administrative record type code
administrative record ADU
-->

<!-- [rfced] It appears that there is no text in the Acknowledgments
section. Would you like to add text or remove the section entirely?
-->
    <section anchor="sec-doc-ack" numbered="false">
      <name>Acknowledgments</name>
      <t>
      </t>
    </section>
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which is helpful for readers.

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->

  </back>
</rfc>