rfc9713.original.xml		rfc9713.xml
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<?rfc toc="yes"?>
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true"		<!DOCTYPE rfc [
	docName="draft-ietf-dtn-bpv7-admin-iana-04" ipr="trust200902" submissionType="IE		<!ENTITY nbsp "&#160;">
	TF" tocInclude="true" updates="9171" version="3">		<!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" subm
			issionType="IETF" tocInclude="true" symRefs="true" sortRefs="true" updates="9171
			" obsoletes="" version="3" xml:lang="en">
	<front>		<front>
	<title abbrev="BPv7 Admin IANA">		<title abbrev="BPv7 Admin IANA">Bundle Protocol Version 7 Administrative Rec
	Bundle Protocol Version 7 Administrative Record Types Registry		ord Types Registry</title>
	</title>		<seriesInfo name="RFC" value="9713"/>
	<seriesInfo name="Internet-Draft" value="draft-ietf-dtn-bpv7-admin-iana-04"/
	>
	<author fullname="Brian Sipos" initials="B." surname="Sipos">		<author fullname="Brian Sipos" initials="B." surname="Sipos">
	<organization abbrev="JHU/APL">The Johns Hopkins University Applied Physic s Laboratory</organization>		<organization abbrev="JHU/APL">The Johns Hopkins University Applied Physic s Laboratory</organization>
	<address>		<address>
	<postal>		<postal>
	<street>11100 Johns Hopkins Rd.</street>		<street>11100 Johns Hopkins Rd.</street>
	<city>Laurel</city>		<city>Laurel</city>
	<region>MD</region>		<region>MD</region>
	<code>20723</code>		<code>20723</code>
	<country>United States of America</country>		<country>United States of America</country>
	</postal>		</postal>
	<email>brian.sipos+ietf@gmail.com</email>		<email>brian.sipos+ietf@gmail.com</email>
	</address>		</address>
	</author>		</author>
	<date/>		<date year="2025" month="January"/>
	<area>Transport</area>		<area>INT</area>
	<workgroup>Delay-Tolerant Networking</workgroup>		<workgroup>dtn</workgroup>
	<keyword>DTN</keyword>		<keyword>DTN</keyword>
	<abstract>		<abstract>
			<!-- [rfced] Initially, we found this text unclear because we questioned whether
			the BPv7 agent was using the IANA registry to document Administrative Record ty
			pes or whether the agent was using the IANA registry itself. We believe both ma
			y 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>		<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.		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.		It also makes code point reservations for Private and Experimental Use.
	</t>		</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section anchor="sec-intro">		<section anchor="sec-intro">
	<name>Introduction</name>		<name>Introduction</name>
			<!-- [rfced] As we believe the "earlier Bundle Protocol (BP) Version 6 (BPv6)" r
			efers to the version specified in RFC 5050, and becauase the relevant registry s
			eems 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>		<t>
	The earlier Bundle Protocol (BP) Version 6 (BPv6) defined an IANA registry for A dministrative Record type code points under <xref target="IANA-BP"/>.		The earlier Bundle Protocol (BP) Version 6 (BPv6) defined an IANA registry for A dministrative Record type code points under <xref target="IANA-BP"/>.
	When Bundle Protocol Version 7 (BPv7) was published in <xref target="RFC9171"/> it identified the IANA registry for Administrative Record types but did not upda te the table to be explicit about which entries applied to which Bundle Protocol version(s).		When Bundle Protocol Version 7 (BPv7) was published in <xref target="RFC9171"/>, it identified the IANA registry for Administrative Record types but did not upd ate the table to be explicit about which entries applied to which Bundle Protoco l version(s).
	The BPv7 specification also did not discriminate between code point reservations and unassigned ranges for Administrative Record types.		The BPv7 specification also did not discriminate between code point reservations and unassigned ranges for Administrative Record types.
	</t>		</t>
	<t>		<t>
	This document updates BPv7 to explicitly use the IANA Administrative Record type registry in <xref target="sec-bpv7-admin-type"/>.		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 makes a reservation of the zero value for consistency with BPv6.
	This document also makes a reservation of high-valued code points for private us e and experimental use in accordance with <xref target="RFC8126"/> to avoid coll isions with assigned code points.		This document also makes a reservation of high-valued code points for Private Us e and Experimental Use in accordance with <xref target="RFC8126"/> to avoid coll isions with assigned code points.
	</t>		</t>
	<section>		<section>
	<name>Scope</name>		<name>Scope</name>
	<t>		<t>
	This document describes updates to the IANA Administrative Record type registry and how a BPv7 agent is supposed to use that registry for identifying Administra tive Record types.		This document describes updates to the IANA "Bundle Administrative Record Types" registry and how a BPv7 agent is supposed to use that registry to identify Admi nistrative Record types.
	</t>		</t>
			<!-- [rfced] Does "overlapping code points" mean code points that are used for b
			oth 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>		<t>
	This document does not specify how BPv6 and BPv7 can interoperate for overlappin g code points or how a specific code point is to be interpreted either similarly or differently between Bundle Protocol versions.		This document does not specify how BPv6 and BPv7 can interoperate for overlappin g 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 h ow it relates to each BP version.		It is up to each individual Administrative Record type specification to define h ow it relates to each BP version.
	</t>		</t>
	</section>		</section>
	<section anchor="sec-terminology">		<section anchor="sec-terminology">
	<name>Terminology</name>		<name>Terminology</name>
	<t>		<t>
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	HOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this docu		"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
	ment are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref		",
	target="RFC8174"/> when, and only when, they appear in all capitals, as shown h		"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	ere.		"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
			"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
			be
			interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
			target="RFC8174"/> when, and only when, they appear in all capitals, as
			shown here.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="sec-bpv7-admin-type">		<section anchor="sec-bpv7-admin-type">
	<name>Administrative Record Types Registry</name>		<name>Administrative Record Types Registry</name>
	<t>		<t>
	This document updates the requirements in <xref section="6.1" target="RFC9171"/> to use an existing IANA registry and updates that registry in <xref target="sec -iana-bp-admin-type"/>.		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 descri bed in <xref target="sec-iana-bp-admin-type"/>.
	</t>		</t>
	<t>		<t>
	The code point allocated in Annex D of <xref target="CCSDS-BP"/> was never added to the IANA registry.		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.		To avoid a collision, this document adds that allocation to the registry.
	</t>		</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>		<t>
	Instead of using the list of types 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 Type s" registry under <xref target="IANA-BP"/> for entries having a "Bundle Protocol Version" of 7.		Instead of using the list of types as described in <xref section="6.1" target="R FC9171"/>, a BPv7 administrative element <bcp14>SHALL</bcp14> interpret administ rative record type code values in accordance with the IANA "Bundle Administrativ e Record Types" registry <xref target="IANA-BP"/> for entries having a "Bundle P rotocol Version" of 7.
	</t>		</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>		<t>
	If an administrative element receives a not-well-formed application data unit (A		If an administrative element receives a not-well-formed application data unit (A
	DU) or an administrative record type code which is not able to be processed by t		DU) or an administrative record type code that is not able to be processed by th
	he element, the record <bcp14>SHALL</bcp14> be ignored by the element.		e element, the record <bcp14>SHALL</bcp14> be ignored by the element.
	The processing of a received administrative record ADU does not affect the fact		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 relate		that the bundle itself was delivered to the administrative element or any relate
	d BPA processing of (e.g. status reports on) the enveloping bundle.		d BPA processing of (e.g., status reports on) the enveloping bundle.
	</t>		</t>
	</section>		</section>
	<section anchor="sec-security">		<section anchor="sec-security">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>		<t>
	This document does not define any requirements or structures which introduce new security considerations.		This document does not define any requirements or structures that introduce new security considerations.
	</t>		</t>
	<t>		<t>
	The existing security considerations of <xref target="RFC9171"/> still apply whe n using the IANA Administrative Record Types registry.		The existing security considerations of <xref target="RFC9171"/> still apply whe n using the IANA "Bundle Administrative Record Types" registry.
	</t>		</t>
	</section>		</section>
	<section anchor="sec-iana">		<section anchor="sec-iana">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t>		<t>
	This specification modifies a BPv6 registry to extend BPv7.		This specification modifies a BPv6 registry by extending it for BPv7.
	</t>		</t>
	<section anchor="sec-iana-bp-admin-type">		<section anchor="sec-iana-bp-admin-type">
	<name>Bundle Administrative Record Types</name>		<name>Bundle Administrative Record Types</name>
	<t>		<t>
	Within the "Bundle Protocol" registry group <xref target="IANA-BP"/>, the "Bundl e Administrative Record Types" registry has been updated to include a leftmost " Bundle Protocol Version" column.		Within the "Bundle Protocol" registry group <xref target="IANA-BP"/>, the "Bundl e 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 BP ve rsions as in the following table.		New entries have been added and existing entries have been updated to include BP versions as in <xref target="tab1"/>.
	This document makes no changes to the registration procedures for this registry.		This document makes no changes to the registration procedures for this registry.
	</t>		</t>
	<table>		<table anchor="tab1">
	<name>Bundle Administrative Record Types</name>		<name>Bundle Administrative Record Types</name>
	<thead>		<thead>
	<tr>		<tr>
	<th>Bundle Protocol Version</th>		<th>Bundle Protocol Version</th>
	<th>Value</th>		<th>Value</th>
	<th>Description</th>		<th>Description</th>
	<th>Reference</th>		<th>Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td>6,7</td>		<td>6,7</td>
	<td>0</td>		<td>0</td>
	<td>Reserved</td>		<td>Reserved</td>
	<td>		<td>
	<xref target="RFC7116"/>		<xref target="RFC7116"/>
	[This specification]		RFC 9713
	</td>		</td>
	</tr>		</tr>
	<tr>		<tr>
	<td>6,7</td>		<td>6,7</td>
	<td>1</td>		<td>1</td>
	<td>Bundle status report</td>		<td>Bundle status report</td>
	<td>		<td>
	<xref target="RFC5050"/>		<xref target="RFC5050"/>
	<xref target="RFC9171"/>		<xref target="RFC9171"/>
	</td>		</td>
	</tr>		</tr>
	<tr>		<tr>
	<td>6</td>		<td>6</td>
	<td>2</td>		<td>2</td>
	<td>Custody signal</td>		<td>Custody signal</td>
	<td>		<td>
	<xref target="RFC5050"/>		<xref target="RFC5050"/>
	</td>		</td>
	</tr>		</tr>
			<!-- [rfced] Because values 3 and 5-15 are unassigned, is it correct for the Bun
			dle Protocol Versions to be noted as 6,7? Does this imply that 6 and 7 must app
			ly to future assignments of those values (i.e., 6,7 apply to unassigned values d
			efined by BPv6, and 7 (only) applies to all other future assignments as values 1
			6+ are defined for BPv7)?
			From Table 1:
			| 6,7 | 3 | Unassigned | |
			| 6,7 | 5 to 15 | Unassigned | |
			-->
	<tr>		<tr>
	<td>6,7</td>		<td>6,7</td>
	<td>3</td>		<td>3</td>
	<td>Unassigned</td>		<td>Unassigned</td>
	<td/>		<td/>
	</tr>		</tr>
	<tr>		<tr>
	<td>6</td>		<td>6</td>
	<td>4</td>		<td>4</td>
	<td>Aggregate Custody Signal</td>		<td>Aggregate Custody Signal</td>
	<td>		<td>
	<xref target="CCSDS-BP"/>		<xref target="CCSDS-BP"/>
	</td>		</td>
	</tr>		</tr>
	<tr>		<tr>
	<td>6,7</td>		<td>6,7</td>
	<td>5 to 15</td>		<td>5 - 15</td>
	<td>Unassigned</td>		<td colspan="2">Unassigned</td>
	<td/>
	</tr>		</tr>
	<tr>		<tr>
	<td>7</td>		<td>7</td>
	<td>16 to 64383</td>		<td>16 - 64383</td>
	<td>Unassigned</td>		<td colspan="2">Unassigned</td>
	<td/>
	</tr>		</tr>
	<tr>		<tr>
	<td>7</td>		<td>7</td>
	<td>64384 to 64511</td>		<td>64384 - 64511</td>
	<td>Reserved for experimental use</td>		<td>Reserved for Experimental Use</td>
	<td>[This specification]</td>		<td>RFC 9713</td>
	</tr>		</tr>
	<tr>		<tr>
	<td>7</td>		<td>7</td>
	<td>64512 to 65535</td>		<td>64512 - 65535</td>
	<td>Reserved for private use</td>		<td>Reserved for Private Use</td>
	<td>[This specification]</td>		<td>RFC 9713</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	</section>		</section>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	skipping to change at line 186 ¶		skipping to change at line 278 ¶
	</tbody>		</tbody>
	</table>		</table>
	</section>		</section>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	<name>Normative References</name>		<name>Normative References</name>
	<reference anchor="IANA-BP" target="https://www.iana.org/assignments/bun dle/">		<reference anchor="IANA-BP" target="https://www.iana.org/assignments/bun dle/">
	<front>		<front>
	<title>Bundle Protocol</title>		<title>Bundle Protocol</title>
	<author>		<author>
	<organization>IANA</organization>		<organization>IANA</organization>
	</author>		</author>
	<date/>		<date/>
	</front>		</front>
	</reference>		</reference>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	ence.RFC.2119.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		119.xml"/>
	ence.RFC.8174.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		174.xml"/>
	ence.RFC.9171.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
			171.xml"/>
	</references>		</references>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
	<reference anchor="CCSDS-BP" target="https://public.ccsds.org/Pubs/734x2 b1.pdf">		<reference anchor="CCSDS-BP" target="https://public.ccsds.org/Pubs/734x2 b1.pdf">
	<front>		<front>
	<title>CCSDS Bundle Protocol Specification</title>		<title>CCSDS Bundle Protocol Specification</title>
	<seriesInfo name="CCSDS" value="734.2-B-1"/>
	<author>		<author>
	<organization>Consultative Committee for Space Data Systems</organ ization>		<organization>Consultative Committee for Space Data Systems</organ ization>
	</author>		</author>
	<date month="September" year="2015"/>		<date month="September" year="2015"/>
	</front>		</front>
			<refcontent>CCSDS Recommended Standard</refcontent>
			<seriesInfo name="CCSDS" value="734.2-B-1"/>
	</reference>		</reference>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	ence.RFC.5050.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		050.xml"/>
	ence.RFC.7116.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		116.xml"/>
	ence.RFC.8126.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			126.xml"/>
	</references>		</references>
	</references>		</references>
			<!-- [rfced] Throughout the text, the following terminology appears to be used
			inconsistently. May we lowercase these for consistency with RFC 9171, which seem
			s 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">		<section anchor="sec-doc-ack" numbered="false">
	<name>Acknowledgments</name>		<name>Acknowledgments</name>
	<t>		<t>
	</t>		</t>
	</section>		</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>		</back>
	</rfc>		</rfc>
End of changes. 37 change blocks.
	61 lines changed or deleted		196 lines changed or added
This html diff was produced by rfcdiff 1.48.