rfc9758.original.xml   rfc9758.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.17 (Ruby 3.2. -ietf-dtn-ipn-update-14" number="9758" category="std" consensus="true" submissio
3) --> nType="IETF" updates="6260, 7116, 9171" obsoletes="" tocInclude="true" sortRefs=
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft "true" symRefs="true" version="3" xml:lang="en">
-ietf-dtn-ipn-update-14" category="std" consensus="true" submissionType="IETF" u
pdates="[9171, 7116, 6260]" tocInclude="true" sortRefs="true" symRefs="true" ver <!--[rfced] To more closely match the document title, we updated the
sion="3"> short title that spans the header of the PDF file as follows.
<!-- xml2rfc v2v3 conversion 3.21.0 --> Please let us know of any objections.
Original:
ipn-updates
Current:
ipn Updates
-->
<front> <front>
<title abbrev="ipn-update">Update to the ipn URI scheme</title> <title abbrev="ipn Updates">Updates to the ipn URI Scheme</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-dtn-ipn-update-14"/> <seriesInfo name="RFC" value="9758"/>
<author fullname="Rick Taylor"> <author fullname="Rick Taylor">
<organization>Aalyria Technologies</organization> <organization>Aalyria Technologies</organization>
<address> <address>
<email>rtaylor@aalyria.com</email> <email>rtaylor@aalyria.com</email>
</address> </address>
</author> </author>
<!--[rfced] Edward, we understand that in other RFCs (RFCs 9171, 9172,
and 9173), your preference was to list your name as "E. Birrane, III"
on the first page and "Edward J. Birrane, III" in the Authors'
Addresses section. Please let us know if you would you like to do the
same in this document for consistency.
-->
<author fullname="Ed Birrane"> <author fullname="Ed Birrane">
<organization>JHU/APL</organization> <organization>JHU/APL</organization>
<address> <address>
<email>Edward.Birrane@jhuapl.edu</email> <email>Edward.Birrane@jhuapl.edu</email>
</address> </address>
</author> </author>
<date year="2024" month="September" day="27"/> <date year="2025" month="March"/>
<area>Transport</area> <area>INT</area>
<workgroup>Delay/Disruption Tolerant Networking</workgroup> <workgroup>dtn</workgroup>
<keyword>DTN</keyword> <keyword>DTN</keyword>
<keyword>ipn</keyword> <keyword>ipn</keyword>
<keyword>BPv7</keyword> <keyword>BPv7</keyword>
<keyword>CBHE</keyword> <keyword>CBHE</keyword>
<keyword>Bundle Protocol</keyword> <keyword>Bundle Protocol</keyword>
<abstract> <abstract>
<?line 46?> <t>This document updates the specification of the ipn URI scheme
previously defined in RFC 6260 and the IANA registries established in RFC
<t>This document updates the specification of the ipn URI scheme previously defi 7116. It also updates the rules for the encoding and decoding of these URI
ned in RFC 6260, the IANA registries established in RFC 7116, and the rules for s when
the encoding and decoding of these URIs when used as an Endpoint Identifier (EID used as an Endpoint Identifier (EID) in the Bundle Protocol version 7 (BPv
) in Bundle Protocol Version 7 (BPv7) as defined in RFC 9171. These updates clar 7)
ify the structure and behavior of the ipn URI scheme, define new encodings of ip as defined in RFC 9171. These updates clarify the structure and behavior
n scheme URIs, and establish the registries necessary to manage this scheme.</t> of the ipn URI scheme, define new encodings of ipn scheme URIs, and
establish the registries necessary to manage this scheme.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
The latest revision of this draft can be found at <eref target="https://
ricktaylor.github.io/ipn2/draft-taylor-dtn-ipn-update.html"/>.
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-dtn-ipn-update/"/>.
</t>
<t>
Discussion of this document takes place on the
Delay/Disruption Tolerant Networking Working Group mailing list (<eref t
arget="mailto:dtn@ietf.org"/>),
which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
wse/dtn/"/>.
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/dtn/"/>
.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/ricktaylor/ipn2"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 50?>
<!-- [rfced] Throughout the document, specific terms and section
titles are linked/referenced. To help the reader differentiate
between the two, we added quote marks to the section titles;
however, please consider if removing the section titles and
providing links to the section numbers only would be helpful
for ease of reading and to avoid any confusion. For example:
Current (with terms and section titles/numbers linked):
Both LocalNode (Section 3.4.2) and Private Use (Section 3.4.3) ipn
URIs present a risk to the stability of deployed BPv7 networks...
See "LocalNode ipn EIDs" (Section 5.4) and "Private Use ipn EIDs"
(Section 5.5) for required behaviors to mitigate against this form of
abuse.
Perhaps (with terms and section numbers linked):
Both LocalNode (Section 3.4.2) and Private Use (Section 3.4.3) ipn
URIs present a risk to the stability of deployed BPv7 networks...
See Sections 5.4 and 5.5 for required behaviors to mitigate against
this form of abuse.
-->
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>The ipn URI scheme was originally defined in <xref target="RFC6260"/> a
nd <xref target="RFC7116"/> as a way to identify network nodes and node services <t>The ipn URI scheme was originally defined in <xref target="RFC6260"/>
using concisely-encoded integers that can be processed faster and with fewer re and <xref target="RFC7116"/> as a way to identify network nodes and node
sources than other verbose identifier schemes. The scheme was designed for use w services using concisely encoded integers that can be processed faster
ith the experimental Bundle Protocol version 6 (BPv6, <xref target="RFC5050"/>) and with fewer resources than other verbose identifier schemes. The
and IPN was defined as an acronym for the term "InterPlanetary Network" in refer scheme was designed for use with the experimental Bundle Protocol
ence to its intended use for deep-space networking. Since then, the efficiency b version 6 (BPv6) <xref target="RFC5050"/>, and "IPN" was defined as an
enefit of integer identifiers makes ipn scheme URIs useful for any networks oper acronym for the term "InterPlanetary Network" in reference to its
ating with limited power, bandwidth, and/or compute budget. Therefore, the term intended use for deep-space networking. Since then, the efficiency
IPN is now used as a non-acronymous name.</t> benefits of integer identifiers make ipn scheme URIs useful for any
<t>Similar to the experimental BPv6, the standardized Bundle Protocol vers network operating with limited power, bandwidth, and/or compute
ion 7 (BPv7, <xref target="RFC9171"/>) codifies support for the use of the ipn U budget. Therefore, the term "IPN" is now used as a non-acronymous
RI scheme for the specification of bundle Endpoint Identifiers (EIDs). The publi name.</t>
cation of BPv7 has resulted in operational deployments of BPv7 nodes for both te
rrestrial and non-terrestrial use cases. This includes BPv7 networks operating o <t>Similar to the experimental BPv6, the standardized Bundle Protocol
ver the terrestrial Internet and BPv7 networks operating in self-contained envir version 7 (BPv7) <xref target="RFC9171"/> codifies support for the use
onments behind a shared administrative domain. The growth in the number and scal of the ipn URI scheme for the specification of bundle Endpoint
e of deployments of BPv7 has been accompanied by a growth in the usage of the ip Identifiers (EIDs). The publication of BPv7 has resulted in operational
n URI scheme which has highlighted areas to improve the structure, moderation, a deployments of BPv7 nodes for both terrestrial and non-terrestrial use
nd management of this scheme.</t> cases. This includes BPv7 networks operating over the terrestrial
<t>By updating <xref target="RFC7116"/> and <xref target="RFC9171"/>, this Internet and BPv7 networks operating in self-contained environments
document updates the specification of the ipn URI scheme, in a backwards-compat behind a shared administrative domain. The growth in the number and
ible way, to provide needed improvements both in the scheme itself and its usage scale of deployments of BPv7 has been accompanied by a growth in the
to specify EIDs with BPv7. Specifically, this document introduces a hierarchica usage of the ipn URI scheme, which has highlighted areas to improve the
l structure for the assignment of ipn scheme URIs, clarifies the behavior and in structure, moderation, and management of this scheme.</t>
terpretation of ipn scheme URIs, defines efficient encodings of ipn scheme URIs,
and updates/defines the registries associated for this scheme.</t> <!-- [rfced] FYI - For readability, we have updated the text below as a
<t>Although originally developed by the deep space community for use with bulleted list. Please review and let us know any objections.
Bundle Protocol, the ipn URI scheme is sufficiently generic to be used in other
environments where a concise unique representation of a resource on a particular Original:
node is required.</t>
<t>It is important to remember that, like most other URI schemes, the ipn Specifically, this document
URI scheme defines a unique identifier of a resource, and does not include any t introduces a hierarchical structure for the assignment of ipn scheme
opological information describing how to route messages to that resource.</t> URIs, clarifies the behavior and interpretation of ipn scheme URIs,
defines efficient encodings of ipn scheme URIs, and updates/defines
the registries associated for this scheme.
Current:
Specifically, this document:
* introduces a hierarchical structure for the assignment of ipn
scheme URIs,
* clarifies the behavior and interpretation of ipn scheme URIs,
* defines efficient encodings of ipn scheme URIs, and
* updates/defines the registries associated with this scheme.
-->
<t>By updating <xref target="RFC7116"/> and <xref target="RFC9171"/>,
this document updates the specification of the ipn URI scheme in a
backwards-compatible way, in order to provide needed improvements both in
the
scheme itself and in its usage to specify EIDs with BPv7. Specifically,
this document:</t>
<ul>
<li>introduces a hierarchical structure for the assignment of ipn scheme
URIs,</li>
<li>clarifies the behavior and interpretation of ipn scheme URIs,</li>
<li>defines efficient encodings of ipn scheme URIs, and</li>
<li>updates/defines the registries associated with this scheme.</li>
</ul>
<t>Although originally developed by the deep-space community for use
with the Bundle Protocol, the ipn URI scheme is sufficiently generic to be
used in other environments where a concise unique representation of a
resource on a particular node is required.</t>
<t>It is important to remember that, like most other URI schemes, the
ipn URI scheme defines a unique identifier of a resource, and it does not
include any topological information describing how to route messages to
that resource.</t>
</section> </section>
<section anchor="conventions-and-definitions"> <section anchor="conventions-and-definitions">
<name>Conventions and Definitions</name> <name>Conventions and Definitions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 <t>
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", ",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
nterpreted as "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
only when, they be
appear in all capitals, as shown here.</t> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
<?line -18?> target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
<t>For the remainder of this document, the term "ipn URI" is used to refer to a URI that uses the ipn scheme.</t> <t>For the remainder of this document, the term "ipn URI" is used to refer to a URI that uses the ipn scheme.</t>
</section> </section>
<section anchor="core-concepts"> <section anchor="core-concepts">
<name>Core Concepts</name> <name>Core Concepts</name>
<t>Every ipn URI, no matter whether it is expressed with the textual repre <t>Every ipn URI, no matter whether it is expressed with a textual
sentation or a binary encoding, <bcp14>MUST</bcp14> be considered as a tuple of representation or a binary encoding, <bcp14>MUST</bcp14> be considered
the following three components:</t> as a tuple of the following three components:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The Allocator Identifier</t> <t>The Allocator Identifier</t>
</li> </li>
<li> <li>
<t>The Node Number</t> <t>The Node Number</t>
</li> </li>
<li> <li>
<t>The Service Number</t> <t>The Service Number</t>
</li> </li>
</ul> </ul>
<t>The Allocator Identifier indicates the entity responsible for assigning
Node Numbers to individual resource nodes, maintaining uniqueness whilst avoidi <t>The Allocator Identifier indicates the entity responsible for
ng the need for a single registry for all assigned Node Numbers. See <xref targe assigning Node Numbers to individual resource nodes, maintaining
t="allocator-identifiers">Allocator Identifiers</xref>.</t> uniqueness whilst avoiding the need for a single registry for all
<t>The Node Number is a shared identifier assigned to all ipn URIs for res assigned Node Numbers. See <xref
ources co-located on a single node. See <xref target="node-numbers">Node Numbers target="allocator-identifiers">"Allocator Identifiers"</xref>.</t>
</xref>.</t>
<t>The Service Number is an identifier to distinguish between resources on <t>The Node Number is a shared identifier assigned to all ipn URIs for
a given node. See <xref target="service-numbers">Service Numbers</xref>.</t> resources co-located on a single node. See <xref
<t>The combination of these three components guarantees that every correct target="node-numbers">"Node Numbers"</xref>.</t>
ly constructed ipn URI uniquely identifies a single resource. Additionally, the
combination of the Allocator Identifier and the Node Number provides a mechanis <t>The Service Number is an identifier to distinguish between resources
m to uniquely identify the node on which a particular resource is expected to ex on a given node. See <xref target="service-numbers">"Service
ist. See <xref target="fqnn">Fully-qualified Node Number</xref>.</t> Numbers"</xref>.</t>
<t>The combination of these three components guarantees that every
correctly constructed ipn URI uniquely identifies a single resource.
Additionally, the combination of the Allocator Identifier and the Node
Number provides a mechanism to uniquely identify the node on which a
particular resource is expected to exist. See <xref
target="fqnn">"Fully-Qualified Node Numbers"</xref>.</t>
<section anchor="null-uri"> <section anchor="null-uri">
<name>The Null ipn URI</name> <name>The Null ipn URI</name>
<t>It has been found that there is value in defining a unique 'null' ipn <t>It has been found that there is value in defining a unique 'null'
URI to indicate "nowhere". This ipn URI is termed the "Null ipn URI", and has ipn URI to indicate "nowhere". This ipn URI is termed the "Null ipn
all three components: Allocator Identifier, Node Number, and Service Number, set URI" and has all three components (the Allocator Identifier, Node Number
to the value zero (0). No resource identified by Null ipn URI exists, and any ,
destination identified by such a resource is therefore by definition unreachable and Service Number) set to the value zero (0). No resource identified
.</t> by the Null ipn URI exists, and any destination identified by such a
resource is therefore by definition unreachable.</t>
</section> </section>
<section anchor="allocator-identifiers"> <section anchor="allocator-identifiers">
<name>Allocator Identifiers</name> <name>Allocator Identifiers</name>
<t>An Allocator is any organization that wishes to assign Node Numbers f <t>An Allocator is any organization that wishes to assign Node Numbers
or use with the ipn URI scheme, and has the facilities and governance to manage for use with the ipn URI scheme and has the facilities and governance
a public registry of assigned Node Numbers. The authorization to assign these nu to manage a public registry of assigned Node Numbers. The
mbers is provided through the assignment of an Allocator Identifier by IANA. Re authorization to assign these numbers is provided through the
gardless of other attributes of an Allocator, such as a name, point of contact, assignment of an Allocator Identifier by IANA. Regardless of other
or other identifying information, Allocators are identified by Allocator Identif attributes of an Allocator (such as a name, point of contact, or other
iers: a unique, unsigned integer, in the range 0 to 2^32-1.</t> identifying information), Allocators are identified by Allocator
<t>The Allocator Identifier <bcp14>MUST</bcp14> be the sole mechanism us Identifiers: unique, unsigned integers in the range 0 to
ed to identify the Allocator that has assigned the Node Number in an ipn URI. An 2<sup>32-1</sup>.</t>
Allocator may have multiple assigned Allocator Identifiers, but a given Allocat
or Identifier <bcp14>MUST</bcp14> only be associated with a single Allocator.</t <t>The Allocator Identifier <bcp14>MUST</bcp14> be the sole mechanism
> used to identify the Allocator that has assigned the Node Number in an
<t>A new IANA "'ipn' Scheme URI Allocator Identifiers" registry is defin ipn URI. An Allocator may have multiple assigned Allocator
ed for the registration of Allocator Identifiers, see <xref target="iana-allocat Identifiers, but a given Allocator Identifier <bcp14>MUST</bcp14> only
or-identifiers">'ipn' Scheme URI Allocator Identifiers registry</xref>. Althoug be associated with a single Allocator.</t>
h the uniqueness of Allocator Identifiers is required to enforce uniqueness of i
pn URIs, some identifiers are explicitly reserved for experimentation or future <t>A new IANA registry, "'ipn' Scheme URI Allocator Identifiers", is
use.</t> defined for the registration of Allocator Identifiers; see <xref
<t>Each Allocator assigns Node Numbers according to its own policies, wi target="iana-allocator-identifiers">"'ipn' Scheme URI Allocator
thout risk of creating an identical ipn URI, as permitted by the rules in the <x Identifiers Registry"</xref>. Although the uniqueness of Allocator
ref target="node-numbers">Node Numbers</xref> section of this document. Other t Identifiers is required to enforce the uniqueness of ipn URIs, some
han ensuring that any Node Numbers it allocates are unique amongst all Node Numb identifiers are explicitly reserved for experimentation or future
ers it assigns, an Allocator does not need to coordinate its allocations with ot use.</t>
her Allocators.</t>
<t>If a system does not require interoperable deployment of ipn scheme U <t>Each Allocator assigns Node Numbers according to its own policies,
RIs, then the <xref target="private-use">Private Use Node Numbers</xref> range, without risk of creating an identical ipn URI, as permitted by the
reserved by the <xref target="default-allocator">Default Allocator</xref> for th rules in <xref target="node-numbers">"Node Numbers"</xref>.
is purpose, are to be used.</t> Other than ensuring that any Node Numbers it
allocates are unique amongst all Node Numbers it assigns, an Allocator
does not need to coordinate its allocations with other Allocators.</t>
<!-- [rfced] Is "range" meant to be singular (option A) or plural
(option B) in the text below?
Original:
If a system does not require interoperable deployment of ipn scheme
URIs, then the Private Use Node Numbers (Section 3.4.3) range,
reserved by the Default Allocator (Section 3.2.2) for this purpose,
are to be used.
Perhaps A:
If a system does not require interoperable deployment of ipn scheme
URIs, then the Private Use Node Numbers (Section 3.4.3) range,
reserved by the Default Allocator (Section 3.2.2) for this purpose,
is to be used.
or
Perhaps B:
If a system does not require interoperable deployment of ipn scheme
URIs, then a range of Private Use Node Numbers (Section 3.4.3),
reserved by the Default Allocator (Section 3.2.2) for this purpose,
are to be used.
-->
<t>If a system does not require interoperable deployment of ipn scheme
URIs, then the <xref target="private-use">Private Use Node
Numbers</xref> range, reserved by the <xref
target="default-allocator">Default Allocator</xref> for this purpose,
are to be used.</t>
<section anchor="allocator-identifier-ranges"> <section anchor="allocator-identifier-ranges">
<name>Allocator Identifier Ranges</name> <name>Allocator Identifier Ranges</name>
<t>Some organizations with internal hierarchies may wish to delegate t
he allocation of Node Numbers to one or more of their sub-organizations. Rather <!-- [rfced] For ease of the reader, we have broken up the text
than assigning unique Allocator Identifiers to each sub-organization on a first below. Please review.
-come first-served basis, there are operational benefits in assigning Allocator
Identifiers to such an organization in a structured way so that an external obse Original:
rver can detect that a group of Allocator Identifiers are organizationally assoc
iated.</t> Rather than assigning unique Allocator Identifiers to each sub-
<t>An Allocator Identifier range is a set of consecutive Allocator Ide organization on a first-come first-served basis, there are
ntifiers associated with the same Allocator. Each individual Allocator Identifie operational benefits in assigning Allocator Identifiers to such an
r in a given range <bcp14>SHOULD</bcp14> be assigned to a distinct sub-organizat organization in a structured way so that an external observer can
ion of the Allocator. Assigning identifiers in this way allows external observer detect that a group of Allocator Identifiers are organizationally
s both to associate individual Allocator Identifiers with a single organization associated.
and to usefully differentiate amongst sub-organizations.</t>
<t>The practice of associating a consecutive range of numbers with a s Current:
ingle organization is inspired by the Classless Inter-domain Routing assignment
of Internet Addresses described in <xref target="RFC4632"/>. In that assignment Rather than assigning unique Allocator Identifiers to each sub-
scheme, an organization (such as an Internet Service Provider) is assigned a net organization on a first-come, first-served basis, there are operational
work prefix such that all addresses sharing that same prefix are considered to b benefits in assigning Allocator Identifiers to such an organization in a
e associated with that organization.</t> structured way. This allows an external observer to detect
<t>Each Allocator Identifier range is identified by the first Allocato that a group of Allocator Identifiers is organizationally associated.
r Identifier in the range and the number of consecutive identifiers in the range
.</t> -->
<t>Allocator Identifier ranges differ from CIDR addresses in two impor
tant ways.</t> <t>Some organizations with internal hierarchies may wish to delegate
<ol spacing="normal" type="1"><li> the allocation of Node Numbers to one or more of their
sub-organizations. Rather than assigning unique Allocator
Identifiers to each sub-organization on a first-come, first-served
basis, there are operational benefits in assigning Allocator
Identifiers to such an organization in a structured way. This allows
an external observer to detect that a group of Allocator Identifiers
is organizationally associated.</t>
<t>An Allocator Identifier range is a set of consecutive Allocator
Identifiers associated with the same Allocator. Each individual
Allocator Identifier in a given range <bcp14>SHOULD</bcp14> be
assigned to a distinct sub-organization of the Allocator. Assigning
identifiers in this way allows external observers to both associate
individual Allocator Identifiers with a single organization and
usefully differentiate amongst sub-organizations.</t>
<t>The practice of associating a consecutive range of numbers with a
single organization is inspired by the Classless Inter-Domain
Routing (CIDR) assignment of Internet addresses described in <xref
target="RFC4632"/>. In that assignment scheme, an organization (such
as an Internet Service Provider (ISP)) is assigned a network prefix su
ch
that all addresses sharing that same prefix are considered to be
associated with that organization.</t>
<t>Each Allocator Identifier range is identified by the first
Allocator Identifier in the range and the number of consecutive
identifiers in the range.</t>
<t>Allocator Identifier ranges differ from CIDR addresses in two impor
tant ways:</t>
<ol spacing="normal" type="1">
<li>
<t>Allocator Identifiers are used to identify organizations and ar e not, themselves, addresses.</t> <t>Allocator Identifiers are used to identify organizations and ar e not, themselves, addresses.</t>
</li> </li>
<li> <li>
<t>Allocator Identifiers may be less than 32 bits in length.</t> <t>Allocator Identifiers may be less than 32 bits in length.</t>
</li> </li>
</ol> </ol>
<t>In order to differentiate between Allocator Identifier ranges using
efficient bitwise operations, all ranges <bcp14>MUST</bcp14> be of a size S tha <t>In order to differentiate between Allocator Identifier ranges
t is a power of 2, and for a given range of length N bits, with S = 2^N, the lea using efficient bitwise operations, all ranges <bcp14>MUST</bcp14>
st-significant N bits of the first Allocator Identifier <bcp14>MUST</bcp14> be a be of a size S that is a power of 2, and for a given range of length
ll 0.</t> N bits, with S = 2<sup>N</sup>, the least-significant N bits of the
<t>An example of the use of Allocator Identifier ranges for four organ first Allocator Identifier <bcp14>MUST</bcp14> be all 0.</t>
izations (A, B, C, and D) is as follows:</t>
<table align="left" anchor="tab-air-example"> <t>An example of the use of Allocator Identifier ranges for four
organizations (A, B, C, and D) is as follows:</t>
<!--[rfced] FYI - In all of the tables, we have aligned the content to
the left (instead of centering some columns) for consistency
and easy reading. If this is not preferred, please let us know.
-->
<table align="center" anchor="tab-air-example">
<name>Allocator Identifier Range Assignment Example</name> <name>Allocator Identifier Range Assignment Example</name>
<thead> <thead>
<tr> <tr>
<th align="left">Organization</th> <th align="left">Organization</th>
<th align="center">Range (dec)</th> <th align="left">Range (dec)</th>
<th align="center">Range (hex)</th> <th align="left">Range (hex)</th>
<th align="center">Range Length (Bits)</th> <th align="left">Range Length (Bits)</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Org A</td> <td align="left">Org A</td>
<td align="center">974848 .. 974975</td> <td align="left">974848 .. 974975</td>
<td align="center">0xEE000 .. 0xEE07F</td> <td align="left">0xEE000 .. 0xEE07F</td>
<td align="center">7 bits</td> <td align="left">7 bits</td>
</tr> </tr>
<tr> <tr>
<td align="left">Org B</td> <td align="left">Org B</td>
<td align="center">974976 .. 974991</td> <td align="left">974976 .. 974991</td>
<td align="center">0xEE080 .. 0xEE08F</td> <td align="left">0xEE080 .. 0xEE08F</td>
<td align="center">4 bits</td> <td align="left">4 bits</td>
</tr> </tr>
<tr> <tr>
<td align="left">Org C</td> <td align="left">Org C</td>
<td align="center">974992 .. 974993</td> <td align="left">974992 .. 974993</td>
<td align="center">0xEE090 .. 0xEE091</td> <td align="left">0xEE090 .. 0xEE091</td>
<td align="center">1 bit</td> <td align="left">1 bit</td>
</tr> </tr>
<tr> <tr>
<td align="left">Org D</td> <td align="left">Org D</td>
<td align="center">974994</td> <td align="left">974994</td>
<td align="center">0xEE092</td> <td align="left">0xEE092</td>
<td align="center">0 bits</td> <td align="left">0 bits</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>With these assignments, any Allocator Identifier whose most-signifi <t>With these assignments, any Allocator Identifier whose
cant 25 bits match 0xEE000 belong to organization A. Similarly, any Allocator Id most-significant 25 bits match 0xEE000 belong to organization
entifier whose most-significant 28 bits match 0xEE080 belong to organization B, A. Similarly, any Allocator Identifier whose most-significant 28
and any Allocator Identifier whose most-significant 31 bits are 0xEE090 belong t bits match 0xEE080 belong to organization B, and any Allocator
o organization C. Organization D has a single Allocator Identifier, and hence a Identifier whose most-significant 31 bits are 0xEE090 belong to
range of bit-length 0.</t> organization C. Organization D has a single Allocator Identifier,
and hence a range of bit-length 0.</t>
</section> </section>
<section anchor="default-allocator"> <section anchor="default-allocator">
<name>The Default Allocator</name> <name>The Default Allocator</name>
<t>As of the publication of <xref target="RFC7116"/>, the only organiz
ation permitted to assign Node Numbers was the Internet Assigned Numbers Authori <t>As of the publication of <xref target="RFC7116"/>, the only
ty (IANA) which assigned Node Numbers via the IANA "CBHE Node Numbers" registry. organization permitted to assign Node Numbers was the Internet
This means that all ipn URIs created prior to the addition of Allocator Identif Assigned Numbers Authority (IANA), which assigned Node Numbers via
iers are assumed to have Node Number allocations that comply with the IANA "CBHE the "CBHE Node Numbers" registry. This means that all ipn URIs
Node Numbers" registry.</t> created prior to the addition of Allocator Identifiers are assumed
<t>The presumption that, unless otherwise specified, Node Numbers are to have Node Number allocations that comply with the "CBHE Node
allocated by IANA from a specific registry is formalized in this update to the i Numbers" registry.</t>
pn URI scheme by designating IANA as the Default Allocator, and by assigning the
Allocator Identifier zero (0) in the <xref target="iana-allocator-identifiers"> <t>The presumption that Node Numbers
'ipn' Scheme URI Allocator Identifiers registry</xref> to the Default Allocator. are allocated by IANA from a specific registry, unless otherwise speci
In any case where an encoded ipn URI does not explicitly include an Allocator fied,
Identifier, an implementation <bcp14>MUST</bcp14> assume that the Node Number ha is formalized in this
s been allocated by the Default Allocator.</t> update to the ipn URI scheme by designating IANA as the Default
<t>A new IANA "'ipn' Scheme URI Default Allocator Node Numbers" regist Allocator and by assigning the Allocator Identifier zero (0) in the
ry is defined to control the allocation of Node Numbers values by the Default Al <xref target="iana-allocator-identifiers">"'ipn' Scheme URI Allocator
locator. This new registry inherits behaviors and existing assignments from the Identifiers" registry</xref> to the Default Allocator. In any case
IANA "CBHE Node Numbers" registry, and reserves some other values as defined in where an encoded ipn URI does not explicitly include an Allocator
the <xref target="special-node-numbers">Special Node Numbers</xref> section bel Identifier, an implementation <bcp14>MUST</bcp14> assume that the
ow.</t> Node Number has been allocated by the Default Allocator.</t>
<t>A new IANA registry, "'ipn' Scheme URI Default Allocator Node
Numbers", is defined to control the allocation of Node Number
values by the Default Allocator. This new registry inherits
behaviors and existing assignments from the "CBHE Node Numbers"
registry, and it reserves some other values as defined in <xref
target="special-node-numbers">"Special Node Numbers"</xref>
below.</t>
</section> </section>
</section> </section>
<section anchor="node-numbers"> <section anchor="node-numbers">
<name>Node Numbers</name> <name>Node Numbers</name>
<t>A Node Number identifies a node that hosts a resource in the context <t>A Node Number identifies a node that hosts a resource in the
of an Allocator. A Node Number is an unsigned integer. A single Node Number assi context of an Allocator. A Node Number is an unsigned integer. A
gned by a single Allocator <bcp14>MUST</bcp14> refer to a single node.</t> single Node Number assigned by a single Allocator <bcp14>MUST</bcp14>
<t>All Node Number assignments, by all Allocators, <bcp14>MUST</bcp14> b refer to a single node.</t>
e in the range 0 to 2^32-1.</t>
<t>It is <bcp14>RECOMMENDED</bcp14> that Node Number zero (0) not be ass <t>All Node Number assignments, by all Allocators, <bcp14>MUST</bcp14>
igned by an Allocator to avoid confusion with the <xref target="null-uri">Null i be in the range 0 to 2<sup>32-1</sup>.</t>
pn URI</xref>.</t>
<t>It is <bcp14>RECOMMENDED</bcp14> that Node Number zero (0) not be
assigned by an Allocator to avoid confusion with the <xref
target="null-uri">Null ipn URI</xref>.</t>
<section anchor="fqnn"> <section anchor="fqnn">
<name>Fully-qualified Node Numbers</name> <name>Fully-Qualified Node Numbers</name>
<t>One of the advantages of ipn URIs is the ability to easily split th <t>One of the advantages of ipn URIs is the ability to easily split
e identity of a particular service from the node upon which the service exists. the identity of a particular service from the node upon which the
For example a message received from one particular ipn URI may require a respon service exists. For example, a message received from one particular
se to be sent to a different service on the same node that sent the original mes ipn URI may require a response to be sent to a different service on
sage. Historically the identifier of the sending node has been colloquially ref the same node that sent the original message. Historically, the
erred to as the "node number" or "node identifier".</t> identifier of the sending node has been colloquially referred to as
<t>To avoid future confusion, when referring to the identifier of a pa the "node number" or "node identifier".</t>
rticular node the term "Fully-qualified Node Number" (FQNN) <bcp14>MUST</bcp14>
be used to refer to the combination of the Node Number component and Allocator I <t>To avoid future confusion, when referring to the identifier of a
dentifier component of an ipn URI that uniquely identifies a particular node. I particular node, the term "Fully-Qualified Node Number" (FQNN)
n other words, an FQNN is the unique identifier of a particular node that suppor <bcp14>MUST</bcp14> be used to refer to the combination of the Node
ts services identified by ipn URIs.</t> Number component and Allocator Identifier component of an ipn URI
<t>In the examples in this document, FQNNs are written as (Allocator I that uniquely identifies a particular node. In other words, an FQNN
dentifier, Node Number), e.g., <tt>(977000,100)</tt> is the FQNN for a node assi is the unique identifier of a particular node that supports services
gned Node Number 100 by an Allocator with Allocator Identifier 977000.</t> identified by ipn URIs.</t>
<t>In the examples in this document, FQNNs are written as (Allocator
Identifier, Node Number). For example, <tt>(977000,100)</tt> is the FQ
NN
for a node assigned Node Number 100 by an Allocator with Allocator
Identifier 977000.</t>
</section> </section>
</section> </section>
<section anchor="special-node-numbers"> <section anchor="special-node-numbers">
<name>Special Node Numbers</name> <name>Special Node Numbers</name>
<t>Some special-case Node Numbers are defined by the Default Allocator, <t>Some special-case Node Numbers are defined by the Default
see <xref target="iana-node-numbers">'ipn' Scheme URI Default Allocator Node Num Allocator; see <xref target="iana-node-numbers">"'ipn' Scheme URI
bers registry</xref>.</t> Default Allocator Node Numbers Registry"</xref>.</t>
<section anchor="the-zero-node-number"> <section anchor="the-zero-node-number">
<name>The Zero Node Number</name> <name>The Zero Node Number</name>
<t>The Default Allocator assigns the use of Node Number zero (0) solel <t>The Default Allocator assigns the use of Node Number zero (0)
y for identifying the <xref target="null-uri">Null ipn URI</xref>.</t> solely for identifying the <xref target="null-uri">Null ipn
<t>This means that any ipn URI with a zero (0) Allocator Identifier an URI</xref>.</t>
d a zero (0) Node Number, but a non-zero Service Number component is invalid. S <t>This means that any ipn URI with a zero (0) Allocator Identifier
uch ipn URIs <bcp14>MUST NOT</bcp14> be composed, and processors of such ipn URI and a zero (0) Node Number, but a non-zero Service Number component,
s <bcp14>MUST</bcp14> consider them as the Null ipn URI.</t> is invalid. Such ipn URIs <bcp14>MUST NOT</bcp14> be composed, and
processors of such ipn URIs <bcp14>MUST</bcp14> consider them as the
Null ipn URI.</t>
</section> </section>
<section anchor="localnode-uri"> <section anchor="localnode-uri">
<name>LocalNode ipn URIs</name> <name>LocalNode ipn URIs</name>
<t>The Default Allocator reserves Node Number 2^32-1 (0xFFFFFFFFF) to <t>The Default Allocator reserves Node Number 2<sup>32-1</sup>
specify resources on the local node, rather than on any specific individual node (0xFFFFFFFFF) to specify resources on the local node, rather than on
.</t> any specific individual node.</t>
<t>This means that any ipn URI with a zero (0) Allocator Identifier an <t>This means that any ipn URI with a zero (0) Allocator Identifier
d a Node Number of 2^32-1 refers to a service on the local bundle node. This for and a Node Number of 2<sup>32-1</sup> refers to a service on the
m of ipn URI is termed a "LocalNode ipn URI".</t> local bundle node. This form of ipn URI is termed a "LocalNode ipn
URI".</t>
</section> </section>
<section anchor="private-use"> <section anchor="private-use">
<name>Private Use Node Numbers</name> <name>Private Use Node Numbers</name>
<t>The Default Allocator provides a range of Node Numbers that are res <t>The Default Allocator provides a range of Node Numbers that are
erved for "Private Use", as defined in <xref target="RFC8126"/>.</t> reserved for Private Use, as defined in <xref
<t>Any ipn URI with a zero (0) Allocator Identifier and a Node Number target="RFC8126"/>.</t>
reserved for "Private Use" is not guaranteed to be unique beyond a single admini <t>Any ipn URI with a zero (0) Allocator Identifier and a Node
strative domain. An administrative domain, as used here, is defined as the set Number reserved for Private Use is not guaranteed to be unique
of nodes that share a unique allocation of FQNNs from the "Private Use" range. beyond a single administrative domain. An administrative domain, as
These FQNNs can be considered to be functionally similar to "Private Address Spa used here, is defined as the set of nodes that share a unique
ce" IPv4 addresses, as defined in <xref target="RFC1918"/>.</t> allocation of FQNNs from the Private Use range. These FQNNs can
<t>Because of this lack of uniqueness, any implementation of a protoco be considered to be functionally similar to private address space
l using ipn URIs that resides on the border between administrative domains <bcp1 IPv4 addresses, as defined in <xref target="RFC1918"/>.</t>
4>MUST</bcp14> have suitable mechanisms in place to prevent protocol units using <t>Because of this lack of uniqueness, any implementation of a
such "Private Use" Node Numbers to cross between different administrative domai protocol using ipn URIs that resides on the border between
ns.</t> administrative domains <bcp14>MUST</bcp14> have suitable mechanisms
in place to prevent protocol units using such Private Use Node
Numbers to cross between different administrative domains.</t>
</section> </section>
</section> </section>
<section anchor="service-numbers"> <section anchor="service-numbers">
<name>Service Numbers</name> <name>Service Numbers</name>
<t>A Service Number is an unsigned integer that identifies a particular <t>A Service Number is an unsigned integer that identifies a
service operating on a node. A service in this case is some logical function th particular service operating on a node. A service in this case is
at requires its own resource identifier to distinguish it from other functions o some logical function that requires its own resource identifier to
perating on the same node.</t> distinguish it from other functions operating on the same node.</t>
</section> </section>
</section> </section>
<section anchor="textual-representation-of-ipn-uris"> <section anchor="textual-representation-of-ipn-uris">
<name>Textual Representation of ipn URIs</name> <name>Textual Representation of ipn URIs</name>
<t>All ipn scheme URIs comply with <xref target="RFC3986"/>, and are there
fore represented by scheme identifier, and a scheme-specific part. The scheme i <t>All ipn scheme URIs comply with <xref target="RFC3986"/> and are
dentifier is: <tt>ipn</tt>, and the scheme-specific parts are represented as a s therefore represented by a scheme identifier and a scheme-specific part.
equence of numeric components separated with the '<tt>.</tt>' character. A form The scheme identifier is <tt>ipn</tt>, and the scheme-specific parts
al definition is provided below, see <xref target="text-syntax">ipn URI Scheme T are represented as a sequence of numeric components separated with the
ext Syntax</xref>, and can be informally considered as:</t> '<tt>.</tt>' character. A formal definition is provided below (see
<xref target="text-syntax">"ipn URI Scheme Text Syntax"</xref>) and can be
informally considered as:</t>
<artwork><![CDATA[ <artwork><![CDATA[
ipn:[<allocator-identifier>.]<node-number>.<service-number> ipn:[<allocator-identifier>.]<node-number>.<service-number>
]]></artwork> ]]></artwork>
<t>To keep the text representation concise, the following rules apply:</t> <t>To keep the text representation concise, the following rules apply:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1">
<t>All leading <tt>0</tt> characters <bcp14>MUST</bcp14> be omitted. A <li>
single '<tt>0</tt>' is valid.</t> <t>All leading <tt>0</tt> characters <bcp14>MUST</bcp14> be
omitted. A single '<tt>0</tt>' is valid.</t>
</li> </li>
<li> <li>
<t>If the Allocator Identifier is zero (0), then the <tt>&lt;allocator <t>If the Allocator Identifier is zero (0), then the
-identifier&gt;</tt> and '<tt>.</tt>' <bcp14>MAY</bcp14> be omitted.</t> <tt>&lt;allocator-identifier&gt;</tt> and '<tt>.</tt>'
<bcp14>MAY</bcp14> be omitted.</t>
</li> </li>
<li> <li>
<t>If the Allocator Identifier is zero (0), and the Node Number is 2^3 <t>If the Allocator Identifier is zero (0), and the Node Number is
2-1, i.e., the URI is a <xref target="localnode-uri">LocalNode ipn URI</xref>, t 2<sup>32-1</sup> (i.e., the URI is a <xref
hen the character '<tt>!</tt>' <bcp14>SHOULD</bcp14> be used instead of the digi target="localnode-uri">LocalNode ipn URI</xref>), then the character
ts <tt>4294967295</tt>, although both forms are valid encodings.</t> '<tt>!</tt>' <bcp14>SHOULD</bcp14> be used instead of the digits
<tt>4294967295</tt>, although both forms are valid encodings.</t>
</li> </li>
</ol> </ol>
<t>Examples of the textual representation of ipn URIs can be found in <xre
f target="text-examples">Appendix A</xref>.</t> <t>Examples of the textual representation of ipn URIs can be found in
<xref target="text-examples"/>.</t>
<section anchor="text-syntax"> <section anchor="text-syntax">
<name>ipn URI Scheme Text Syntax</name> <name>ipn URI Scheme Text Syntax</name>
<t>The text syntax of an ipn URI <bcp14>MUST</bcp14> comply with the fol
lowing ABNF <xref target="RFC5234"/> syntax, and reiterates the core ABNF syntax <t>The text syntax of an ipn URI <bcp14>MUST</bcp14> comply with the
rule for DIGIT defined by that specification:</t> following ABNF syntax from <xref target="RFC5234"/> and reiterate the
<artwork type="abnf" align="left"><![CDATA[ core ABNF syntax rule for DIGIT defined by that specification:</t>
<sourcecode type="abnf"><![CDATA[
ipn-uri = "ipn:" ipn-hier-part ipn-uri = "ipn:" ipn-hier-part
ipn-hier-part = fqnn "." service-number ipn-hier-part = fqnn "." service-number
fqnn = "!" / allocator-part fqnn = "!" / allocator-part
allocator-part = [allocator-identifier "."] node-number allocator-part = [allocator-identifier "."] node-number
allocator-identifier = number allocator-identifier = number
node-number = number node-number = number
service-number = number service-number = number
number = "0" / non-zero-number number = "0" / non-zero-number
non-zero-number = (%x31-39 *DIGIT) non-zero-number = (%x31-39 *DIGIT)
DIGIT = %x30-39 DIGIT = %x30-39
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="usage-of-ipn-uris-with-bpv7"> <section anchor="usage-of-ipn-uris-with-bpv7">
<name>Usage of ipn URIs with BPv7</name> <name>Usage of ipn URIs with BPv7</name>
<t>From the earliest days of experimentation with the Bundle Protocol ther
e has been a need to identify the source and destination of a bundle. The IRTF <!-- [rfced] May we clarify what specifications the following text refers to
BPv6 experimental specification termed the logical source or destination of a bu and also rework the last sentence to make clear that an RFC (rather than a
ndle as an "Endpoint" identified by an "Endpoint Identifier" (EID). BPv6 EIDs ar protocol) defines this registry?
e formatted as URIs. This definition and representation of EIDs was carried forw
ard from the IRTF BPv6 specification to the IETF BPv7 specification. BPv7 additi Original:
onally defined an IANA registry called the "Bundle Protocol URI Scheme Types" re
gistry which identifies those URI schemes than might be used to represent EIDs. The IRTF BPv6 experimental specification termed the logical source or
The ipn URI scheme is one such URI scheme.</t> destination of a bundle as an "Endpoint" identified by an "Endpoint
<t>This section identifies the behavior and interpretation of ipn scheme U Identifier" (EID). BPv6 EIDs are formatted as URIs. This definition and
RIs that <bcp14>MUST</bcp14> be followed when using this URI scheme to represent representation of EIDs was carried forward from the IRTF BPv6 specification
EIDs in BPv7. An ipn URI used as a BPv7 or BPv6 EID is termed an "ipn EID".</t> to the IETF BPv7 specification. BPv7 additionally defined an IANA registry
called the "Bundle Protocol URI Scheme Types" registry...
Perhaps:
The IRTF BPv6 experimental specification [RFC5050] termed the logical
source or destination of a bundle as an "Endpoint" identified by an
"Endpoint Identifier" (EID). BPv6 EIDs are formatted as URIs. This
definition and representation of EIDs was carried forward from the IRTF
BPv6 specification [RFC5050] to the IETF BPv7 specification [RFC9171].
[RFC9171] additionally defined an IANA registry called the "Bundle Protocol
URI Scheme Types" registry...
-->
<t>From the earliest days of experimentation with the Bundle Protocol,
there has been a need to identify the source and destination of a
bundle. The IRTF BPv6 experimental specification termed the logical
source or destination of a bundle as an "Endpoint" identified by an
"Endpoint Identifier" (EID). BPv6 EIDs are formatted as URIs. This
definition and representation of EIDs was carried forward from the IRTF
BPv6 specification to the IETF BPv7 specification. BPv7 additionally
defined an IANA registry called the "Bundle Protocol URI Scheme Types"
registry, which identifies those URI schemes that might be used to
represent EIDs. The ipn URI scheme is one such URI scheme.</t>
<t>This section identifies the behavior and interpretation of ipn scheme
URIs that <bcp14>MUST</bcp14> be followed when using this URI scheme to
represent EIDs in BPv7. An ipn URI used as a BPv7 or BPv6 EID is termed
an "ipn EID".</t>
<section anchor="uniqueness-constraints"> <section anchor="uniqueness-constraints">
<name>Uniqueness Constraints</name> <name>Uniqueness Constraints</name>
<t>An ipn EID <bcp14>MUST</bcp14> identify a singleton endpoint. The bun <t>An ipn EID <bcp14>MUST</bcp14> identify a singleton endpoint. The
dle processing node that is the sole member of that endpoint <bcp14>MUST</bcp14> bundle processing node that is the sole member of that endpoint
be the node identified by the <xref target="fqnn">Fully-qualified Node Number</ <bcp14>MUST</bcp14> be the node identified by the <xref
xref> of the node.</t> target="fqnn">Fully-Qualified Node Number</xref> of the node.</t>
<t>A single bundle processing node <bcp14>MAY</bcp14> have multiple ipn <t>A single bundle processing node <bcp14>MAY</bcp14> have multiple
EIDs associated with it. However, all ipn EIDs that share any single FQNN <bcp14 ipn EIDs associated with it. However, all ipn EIDs that share any
>MUST</bcp14> refer to the same bundle processing node.</t> single FQNN <bcp14>MUST</bcp14> refer to the same bundle processing
<t>For example, <tt>ipn:977000.100.1</tt>, <tt>ipn:977000.100.2</tt>, an node.</t>
d <tt>ipn:977000.100.3</tt> <bcp14>MUST</bcp14> all refer to services registered
on the bundle processing node identified with FQNN <tt>(977000,100)</tt>. None <t>For example, <tt>ipn:977000.100.1</tt>, <tt>ipn:977000.100.2</tt>,
of these EIDs could be registered on any other bundle processing node.</t> and <tt>ipn:977000.100.3</tt> <bcp14>MUST</bcp14> all refer to
services registered on the bundle processing node identified with FQNN
<tt>(977000,100)</tt>. None of these EIDs could be registered on any
other bundle processing node.</t>
</section> </section>
<section anchor="the-null-endpoint"> <section anchor="the-null-endpoint">
<name>The Null Endpoint</name> <name>The Null Endpoint</name>
<t><xref section="3.2" sectionFormat="of" target="RFC9171"/> defines the <t><xref section="3.2" sectionFormat="of" target="RFC9171"/> defines
concept of the 'null' endpoint, which is an endpoint that has no members and wh the concept of the 'null' endpoint, which is an endpoint that has no
ich is identified by a special 'null' EID.</t> members and is identified by a special 'null' EID.</t>
<t>Within the ipn URI scheme, the 'null' EID is represented by the <xref <t>Within the ipn URI scheme, the 'null' EID is represented by the
target="null-uri">Null ipn URI</xref>. This means that the URIs <tt>dtn:none</ <xref target="null-uri">Null ipn URI</xref>. This means that the URIs
tt> (<xref section="4.2.5.1.1" sectionFormat="of" target="RFC9171"/>), <tt>ipn:0 <tt>dtn:none</tt> (<xref section="4.2.5.1.1" sectionFormat="of"
.0</tt>, and <tt>ipn:0.0.0</tt> all refer to the BPv7 'null' endpoint.</t> target="RFC9171"/>), <tt>ipn:0.0</tt>, and <tt>ipn:0.0.0</tt> all
refer to the BPv7 'null' endpoint.</t>
</section> </section>
<section anchor="bpv7-node-id"> <section anchor="bpv7-node-id">
<name>BPv7 Node ID</name> <name>BPv7 Node ID</name>
<t><xref section="4.2.5.2" sectionFormat="of" target="RFC9171"/> introdu <t><xref section="4.2.5.2" sectionFormat="of" target="RFC9171"/>
ces the concept of a "Node ID" that has the same format as an EID and that uniqu introduces the concept of a "Node ID" that has the same format as an
ely identifies a bundle processing node.</t> EID and uniquely identifies a bundle processing node.</t>
<t>Any ipn EID can serve as a "Node ID" for the bundle processing node i <t>Any ipn EID can serve as a "Node ID" for the bundle processing node
dentified by its <xref target="fqnn">Fully-qualified Node Number</xref>. That is identified by its <xref target="fqnn">Fully-Qualified Node
, any ipn EID of the form ipn:A.B.C may be used as the Source Node ID of any bun Number</xref>. That is, any ipn EID of the form <tt>ipn:A.B.C</tt> may b
dle created by the bundle processing node identified by the FQNN <tt>(A,B)</tt>. e used
</t> as the Source Node ID of any bundle created by the bundle processing
node identified by the FQNN <tt>(A,B)</tt>.</t>
</section> </section>
<section anchor="localnode-ipn-eids"> <section anchor="localnode-ipn-eids">
<name>LocalNode ipn EIDs</name> <name>LocalNode ipn EIDs</name>
<t>When a <xref target="localnode-uri">LocalNode ipn URI</xref> is used
as a BPv7 or BPv6 EID, it is termed a "LocalNode ipn EID".</t> <t>When a <xref target="localnode-uri">LocalNode ipn URI</xref> is
<t>Because a LocalNode ipn EID only has meaning on the local bundle node used as a BPv6 or BPv7 EID, it is termed a "LocalNode ipn EID".</t>
, any such EID <bcp14>MUST</bcp14> be considered 'non-routable'. This means that
any bundle using a LocalNode ipn EID as a bundle source or bundle destination < <t>Because a LocalNode ipn EID only has meaning on the local bundle
bcp14>MUST NOT</bcp14> be allowed to leave the local node. Equally, all externa node, any such EID <bcp14>MUST</bcp14> be considered
lly received bundles featuring LocalNode EIDs as a bundle source or bundle desti non-routable. This means that any bundle using a LocalNode ipn EID as
nation <bcp14>MUST</bcp14> be discarded as invalid.</t> a bundle source or bundle destination <bcp14>MUST NOT</bcp14> be
<t>LocalNode ipn EIDs <bcp14>MUST NOT</bcp14> be present in any other pa allowed to leave the local node. Equally, all externally received
rt of a bundle that is transmitted off of the local node. For example, a LocalNo bundles featuring LocalNode EIDs as a bundle source or bundle
de ipn EID <bcp14>MUST NOT</bcp14> be used as a Bundle Protocol Security <xref t destination <bcp14>MUST</bcp14> be discarded as invalid.</t>
arget="RFC9172"/> security source for a bundle transmitted from the local bundle
node, because such a source EID would have no meaning at a downstream bundle no <!-- [rfced] In the instances below, does "security source" read as redundant
de.</t> after "Bundle Protocol Security"?
<t>LocalNode ipn EIDs <bcp14>MUST NOT</bcp14> be published in any node i
dentification directory, such as a DNS registration, or presented as part of dyn Original:
amic peer discovery, as the EID has no valid meaning for other nodes. For examp
le, a LocalNode ipn EID <bcp14>MUST NOT</bcp14> be advertised as the peer Node I For example, a LocalNode ipn EID MUST NOT be used as a Bundle
D during session negotiation in <xref target="RFC9174"/>.</t> Protocol Security [RFC9172] security source for a bundle
transmitted from the local bundle node, because such a source EID
would have no meaning at a downstream bundle node.
For example, a Private Use ipn EID MUST NOT be used as a Bundle Protocol
Security [RFC9172] security source for a bundle, when the bundle is
destined for a different administrative domain.
Perhaps:
For example, a LocalNode ipn EID MUST NOT be used as a
source of Bundle Protocol Security (BPSec) [RFC9172] for a bundle
transmitted from the local bundle node, because such a source EID
would have no meaning at a downstream bundle node.
For example, a Private Use ipn EID MUST NOT be used as a source of
BPSec [RFC9172] for a bundle when the bundle is destined for a
different administrative domain.
-->
<t>LocalNode ipn EIDs <bcp14>MUST NOT</bcp14> be present in any other
part of a bundle that is transmitted off of the local node. For
example, a LocalNode ipn EID <bcp14>MUST NOT</bcp14> be used as a
Bundle Protocol Security (BPSec) <xref target="RFC9172"/> security
source for a bundle transmitted from the local bundle node, because
such a source EID would have no meaning at a downstream bundle
node.</t>
<t>LocalNode ipn EIDs <bcp14>MUST NOT</bcp14> be published in any node
identification directory (such as a DNS registration) or presented as
part of dynamic peer discovery, as the EID has no valid meaning for
other nodes. For example, a LocalNode ipn EID <bcp14>MUST NOT</bcp14>
be advertised as the peer Node ID during session negotiation in <xref
target="RFC9174"/>.</t>
</section> </section>
<section anchor="private-use-ipn-eids"> <section anchor="private-use-ipn-eids">
<name>Private Use ipn EIDs</name> <name>Private Use ipn EIDs</name>
<t>Bundles destined for EIDs that use an ipn URI with a <xref target="fq
nn">Fully-qualified Node Number</xref> that is within the "Private Use" range of <t>Bundles destined for EIDs that use an ipn URI with a <xref
the <xref target="default-allocator">Default Allocator</xref> are not universal target="fqnn">Fully-Qualified Node Number</xref> that is within the
ly unique, and therefore are only valid within the scope of the current administ Private Use range of the <xref target="default-allocator">Default
rative domain. This means that any bundle using a Private Use ipn EID as a bund Allocator</xref> are not universally unique; therefore, they are only
le source or bundle destination <bcp14>MUST NOT</bcp14> be allowed to cross admi valid within the scope of the current administrative domain. This
nistrative domains. All implementations that could be deployed as a gateway bet means that any bundle using a Private Use ipn EID as a bundle source
ween administrative domains <bcp14>MUST</bcp14> be sufficiently configurable to or bundle destination <bcp14>MUST NOT</bcp14> be allowed to cross
ensure that this is enforced, and operators <bcp14>MUST</bcp14> ensure correct c administrative domains. All implementations that could be deployed as
onfiguration.</t> a gateway between administrative domains <bcp14>MUST</bcp14> be
<t>Private Use ipn EIDs <bcp14>MUST NOT</bcp14> be present in any other sufficiently configurable to ensure that this is enforced, and
part of a bundle that is destined for another administrative domain when the lac operators <bcp14>MUST</bcp14> ensure correct configuration.</t>
k of uniqueness prevents correct operation. For example, a Private Use ipn EID <
bcp14>MUST NOT</bcp14> be used as a Bundle Protocol Security <xref target="RFC91 <t>Private Use ipn EIDs <bcp14>MUST NOT</bcp14> be present in any
72"/> security source for a bundle, when the bundle is destined for a different other part of a bundle that is destined for another administrative
administrative domain.</t> domain when the lack of uniqueness prevents correct operation. For
example, a Private Use ipn EID <bcp14>MUST NOT</bcp14> be used as a
BPSec <xref target="RFC9172"/> security source for
a bundle when the bundle is destined for a different administrative
domain.</t>
</section> </section>
<section anchor="well-known-service-numbers"> <section anchor="well-known-service-numbers">
<name>Well-known Service Numbers</name> <name>Well-Known Service Numbers</name>
<t>It is convenient for BPv7 services that have a public specification a
nd wide adoption to be identified by a pre-agreed default Service Number, so tha <t>It is convenient for BPv7 services that have a public specification
t unless extra configuration is applied, such services can be sensibly assumed t and wide adoption to be identified by a pre-agreed default Service
o be operating on the well-known Service Number on a particular node.</t> Number, so that unless extra configurations are applied, such services
<t>If a different service uses the number, or the service uses a differe can be sensibly assumed to be operating on the well-known Service
nt number, BPv7 will continue to operate, but some configuration may be required Number on a particular node.</t>
to make the individual service operational.</t>
<t>A new IANA "'ipn' Scheme URI Well-known Service Numbers for BPv7" reg <t>If a different service uses the number, or the service uses a
istry is defined for the registration of well-known BPv7 Service Numbers, see <x different number, BPv7 will continue to operate, but some
ref target="iana-service-numbers">'ipn' Scheme URI Well-known Service Numbers fo configuration may be required to make the individual service
r BPv7 registry</xref>. This registry records the assignments of Service Number operational.</t>
s for well-known services, and also explicitly reserves ranges for both experime
ntation and private use.</t> <t>A new IANA registry, "'ipn' Scheme URI Well-Known Service Numbers
for BPv7", is defined for the registration of well-known BPv7 Service
Numbers; see <xref target="iana-service-numbers">"'ipn' Scheme URI
Well-Known Service Numbers for BPv7 Registry"</xref>. This registry
records the assignments of Service Numbers for well-known services
and also explicitly reserves ranges for both experimentation and
Private Use.</t>
</section> </section>
<section anchor="administrative-endpoints"> <section anchor="administrative-endpoints">
<name>Administrative Endpoints</name> <name>Administrative Endpoints</name>
<t>The service identified by a Service Number of zero (0) <bcp14>MUST</b
cp14> be interpreted as the Administrative Endpoint of the node, as defined in < <t>The service identified by a Service Number of zero (0)
xref section="3.2" sectionFormat="of" target="RFC9171"/>.</t> <bcp14>MUST</bcp14> be interpreted as the Administrative Endpoint of
<t>Non-zero Service Numbers <bcp14>MUST NOT</bcp14> be used to identify the node, as defined in <xref section="3.2" sectionFormat="of"
the Administrative Endpoint of a bundle node in an ipn EID.</t> target="RFC9171"/>.</t>
<t>Non-zero Service Numbers <bcp14>MUST NOT</bcp14> be used to
identify the Administrative Endpoint of a bundle node in an ipn
EID.</t>
</section> </section>
</section> </section>
<section anchor="cbor-representation-of-ipn-uris-with-bpv7"> <section anchor="cbor-representation-of-ipn-uris-with-bpv7">
<name>CBOR representation of ipn URIs with BPv7</name> <name>CBOR Representation of ipn URIs with BPv7</name>
<t><xref section="4.2.5.1" sectionFormat="of" target="RFC9171"/> requires <t><xref section="4.2.5.1" sectionFormat="of" target="RFC9171"/>
that any URI scheme used to represent BPv7 EIDs <bcp14>MUST</bcp14> define how t requires that any URI scheme used to represent BPv7 EIDs
he scheme-specific part of the URI scheme is encoded with CBOR <xref target="RFC <bcp14>MUST</bcp14> define how the scheme-specific part of the URI
8949"/>. To meet this requirement, this section describes the CBOR encoding and scheme is encoded with Concise Binary Object Representation (CBOR) <xref t
decoding approach for ipn EIDs. The formal definition of the CBOR representation arget="RFC8949"/>. To meet this
is specified, see <xref target="cbor-encoding">ipn URI Scheme CBOR syntax</xref requirement, this section describes the CBOR encoding and decoding
>.</t> approach for ipn EIDs. The formal definition of the CBOR representation
is specified; see <xref target="cbor-encoding">"ipn URI Scheme CBOR
Syntax"</xref>.</t>
<section anchor="ipn-eid-cbor-encoding"> <section anchor="ipn-eid-cbor-encoding">
<name>ipn EID CBOR Encoding</name> <name>ipn EID CBOR Encoding</name>
<t>Generic URI approaches to encoding ipn EIDs are unlikely to be effici <t>Generic URI approaches to encoding ipn EIDs are unlikely to be
ent because they do not consider the underlying structure of the ipn URI scheme. efficient because they do not consider the underlying structure of the
Since the creation of the ipn URI scheme was motivated by the need for concise ipn URI scheme. Since the creation of the ipn URI scheme was motivated
identification and rapid processing, the encoding of ipn EIDs maintains these pr by the need for concise identification and rapid processing, the
operties.</t> encoding of ipn EIDs maintains these properties.</t>
<t>Fundamentally, <xref target="RFC9171"/> ipn EIDs are represented as a <t>Fundamentally, ipn EIDs from <xref target="RFC9171"/> are represented
sequence of identifiers. In the text syntax, the numbers are separated with the as
'<tt>.</tt>' delimiter; in CBOR, this ordered series of numbers can be represen a sequence of identifiers. In the text syntax, the numbers are
ted by an array. Therefore, when encoding ipn EIDs for use with BPv7, the scheme separated with the '<tt>.</tt>' delimiter; in CBOR, this ordered
-specific part of an ipn URI <bcp14>MUST</bcp14> be represented as a CBOR array series of numbers can be represented by an array. Therefore, when
of either two (2) or three (3) elements. Each element of the array <bcp14>MUST</ encoding ipn EIDs for use with BPv7, the scheme-specific part of an
bcp14> be encoded as a single CBOR unsigned integer.</t> ipn URI <bcp14>MUST</bcp14> be represented as a CBOR array of either
<t>The structure and mechanisms of the two-element and three-element enc two (2) or three (3) elements. Each element of the array
odings are described below, and examples of the different encodings are provided <bcp14>MUST</bcp14> be encoded as a single CBOR unsigned integer.</t>
in <xref target="cbor-examples">Appendix B</xref>.</t> <t>The structure and mechanisms of the two-element and three-element
encodings are described below, and examples of the different encodings
are provided in <xref target="cbor-examples"/>.</t>
<section anchor="two-encode"> <section anchor="two-encode">
<name>Two-Element Scheme-Specific Encoding</name> <name>Two-Element Scheme-Specific Encoding</name>
<t>In the two-element scheme-specific encoding of an ipn EID, the firs
t element of the array is an encoding of the <xref target="fqnn">Fully-qualified <t>In the two-element scheme-specific encoding of an ipn EID, the
Node Number</xref> and the second element of the array is the ipn EID Service N first element of the array is an encoding of the <xref
umber.</t> target="fqnn">Fully-Qualified Node Number</xref>, and the second
<t>The FQNN encoding <bcp14>MUST</bcp14> be a 64-bit unsigned integer element of the array is the ipn EID Service Number.</t>
constructed in the following way:</t>
<t>The FQNN encoding <bcp14>MUST</bcp14> be a 64-bit unsigned
integer constructed in the following way:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>The least significant 32 bits <bcp14>MUST</bcp14> represent the <t>The least significant 32 bits <bcp14>MUST</bcp14> represent
Node Number associated with the ipn EID.</t> the Node Number associated with the ipn EID.</t>
</li> </li>
<li> <li>
<t>The most significant 32 bits <bcp14>MUST</bcp14> represent the <t>The most significant 32 bits <bcp14>MUST</bcp14> represent
Allocator Identifier associated with the ipn EID.</t> the Allocator Identifier associated with the ipn EID.</t>
</li> </li>
</ol> </ol>
<t>For example the ipn EID of <tt>ipn:977000.100.1</tt> has an FQNN of
<tt>(977000,100)</tt> which would be encoded as <tt>0xEE868_00000064</tt>. The <t>For example, the ipn EID of <tt>ipn:977000.100.1</tt> has an FQNN
resulting two-element array <tt>[0xEE868_00000064, 0x01]</tt> would be encoded of <tt>(977000,100)</tt>, which would be encoded as
in CBOR as the following 11 octet sequence:</t> <tt>0xEE868_00000064</tt>. The resulting two-element array
<artwork><![CDATA[ <tt>[0xEE868_00000064, 0x01]</tt> would be encoded in CBOR as the
following 11-octet sequence:</t>
<!--[rfced] In Section 6.1.1 and Appendix B.2, "# 2 Element ipn EID
scheme-specific encoding" is 1 character over the 72-character
limit. Please let us know how you would like to update the
spacing within the sourcecode figures.
Current
Section 6.1.1:
82 # 2-Element Endpoint Encoding
02 # uri-code: 2 (IPN URI scheme)
82 # 2 Element ipn EID scheme-specific encoding
1B 000EE86800000064 # Fully-Qualified Node Number
01 # Service Number
Appendix B.1:
82 # 2-Element Endpoint Encoding
02 # uri-code: 2 (IPN URI scheme)
82 # 2 Element ipn EID scheme-specific encoding
1B 000EE86800000001 # Fully-Qualified Node Number
01 # Service Number
-->
<sourcecode type="cbor"><![CDATA[
82 # 2-Element Endpoint Encoding 82 # 2-Element Endpoint Encoding
02 # uri-code: 2 (IPN URI scheme) 02 # uri-code: 2 (IPN URI scheme)
82 # 2 Element ipn EID scheme-specific encoding 82 # 2 Element ipn EID scheme-specific encoding
1B 000EE86800000064 # Fully-qualified Node Number 1B 000EE86800000064 # Fully-Qualified Node Number
01 # Service Number 01 # Service Number
]]></artwork> ]]></sourcecode>
<t>The two-element scheme-specific encoding provides for backwards-com
patibility with the encoding provided in <xref section="4.2.5.1.2" sectionFormat <t>The two-element scheme-specific encoding provides backwards
="of" target="RFC9171"/>. When used in this way, the encoding of the FQNN replac compatibility with the encoding provided in <xref
es the use of the "Node Number" that was specified in RFC9171. When the Node Num section="4.2.5.1.2" sectionFormat="of" target="RFC9171"/>. When used
ber is allocated by the <xref target="default-allocator">Default Allocator</xref in this way, the encoding of the FQNN replaces the use of the Node
>, the encoding of the FQNN and the RFC9171 encoding of the "Node Number" are id Number that was specified in <xref target="RFC9171"/>. When the
entical.</t> Node Number is allocated by the <xref
target="default-allocator">Default Allocator</xref>, the encoding of
the FQNN and the encoding of the Node Number from <xref
target="RFC9171"/> are identical.</t>
</section> </section>
<section anchor="three-encode"> <section anchor="three-encode">
<name>Three-Element Scheme-Specific Encoding</name> <name>Three-Element Scheme-Specific Encoding</name>
<t>In the three-element scheme-specific encoding of an ipn EID, the fi
rst element of the array is the Allocator Identifier, the second element of the <!-- [rfced] FYI - We have adjusted the text below to read as a numbered
array is the Node Number, and the third element of the array is the Service Numb list. Please review and let us know any objections.
er.</t>
<t>For example, the ipn EID of <tt>ipn:977000.100.1</tt> would result Original:
in the three-element array of <tt>[977000,100,1]</tt> which would be encoded in
CBOR as the following 9 octet sequence:</t> In the three-element scheme-specific encoding of an ipn EID, the
<artwork><![CDATA[ first element of the array is the Allocator Identifier, the second
element of the array is the Node Number, and the third element of the
array is the Service Number.
Current:
In the three-element scheme-specific encoding of an ipn EID:
1. the first element of the array is the Allocator Identifier,
2. the second element of the array is the Node Number, and
3. the third element of the array is the Service Number.
-->
<t>In the three-element scheme-specific encoding of an ipn EID:</t>
<ol>
<li>the first element of the array is the Allocator Identifier,</li>
<li>the second element of the array is the Node Number, and</li>
<li>the third element of the array is the Service Number.</li>
</ol>
<t>For example, the ipn EID of <tt>ipn:977000.100.1</tt> would
result in the three-element array of <tt>[977000,100,1]</tt>, which
would be encoded in CBOR as the following 9-octet sequence:</t>
<sourcecode type="cbor"><![CDATA[
82 # 2-Element Endpoint Encoding 82 # 2-Element Endpoint Encoding
02 # uri-code: 2 (IPN URI scheme) 02 # uri-code: 2 (IPN URI scheme)
83 # 3 Element ipn EID scheme-specific encoding 83 # 3 Element ipn EID scheme-specific encoding
1A 000EE868 # Allocator Identifier 1A 000EE868 # Allocator Identifier
64 # Node Number 64 # Node Number
01 # Service Number 01 # Service Number
]]></artwork> ]]></sourcecode>
<t>The three-element scheme-specific encoding allows for a more effici
ent representation of ipn EIDs using smaller Allocator Identifiers, and implemen <t>The three-element scheme-specific encoding allows for a more
tations are <bcp14>RECOMMENDED</bcp14> to use this encoding scheme, unless expli efficient representation of ipn EIDs using smaller Allocator
citly mitigating for interoperability issues, <xref target="compatibility">see S Identifiers, and implementations are <bcp14>RECOMMENDED</bcp14> to
cheme Compatibility</xref>.</t> use this encoding scheme unless explicitly mitigating for
<t>When encoding an ipn EID using the <xref target="default-allocator" interoperability issues; see <xref target="compatibility">"Scheme
>Default Allocator</xref> with this encoding scheme, the first element of the ar Compatibility"</xref>.</t>
ray is the value zero (0). In this case using the equivalent <xref target="two-
encode">Two-Element Scheme-Specific Encoding</xref> will result in a more concis <t>When encoding an ipn EID using the <xref
e CBOR representation, and therefore it is <bcp14>RECOMMENDED</bcp14> that imple target="default-allocator">Default Allocator</xref> with this
mentations use that encoding instead.</t> encoding scheme, the first element of the array is the value zero
(0). In this case, using the equivalent <xref
target="two-encode">two-element scheme-specific encoding</xref> will
result in a more concise CBOR representation; therefore, it is
<bcp14>RECOMMENDED</bcp14> that implementations use that encoding
instead.</t>
</section> </section>
</section> </section>
<section anchor="ipn-eid-cbor-decoding"> <section anchor="ipn-eid-cbor-decoding">
<name>ipn EID CBOR Decoding</name> <name>ipn EID CBOR Decoding</name>
<t>The presence of different scheme-specific encodings does not introduc
e any decoding ambiguity.</t> <t>The presence of different scheme-specific encodings does not
<t>An ipn EID CBOR decoder can reconstruct an ipn EID using the followin introduce any decoding ambiguity.</t>
g logic. In this description, the term <tt>enc_eid</tt> refers to the CBOR encod <t>An ipn EID CBOR decoder can reconstruct an ipn EID using the
ed ipn EID, and the term <tt>ipn_eid</tt> refers to the decoded ipn EID.</t> following logic. In this description, the term <tt>enc_eid</tt> refers
<artwork align="left" type="pseudocode"><![CDATA[ to the CBOR-encoded ipn EID, and the term <tt>ipn_eid</tt> refers to
the decoded ipn EID.</t>
<sourcecode type="pseudocode"><![CDATA[
if enc_eid.len() == 3 if enc_eid.len() == 3
{ {
ipn_eid.allocator_identifier := enc_eid[0]; ipn_eid.allocator_identifier := enc_eid[0];
ipn_eid.node_number := enc_eid[1]; ipn_eid.node_number := enc_eid[1];
ipn_eid.service_number := enc_eid[2]; ipn_eid.service_number := enc_eid[2];
} }
else if enc_eid.len() == 2 else if enc_eid.len() == 2
{ {
ipn_eid.allocator_identifier := enc_eid[0] >> 32; ipn_eid.allocator_identifier := enc_eid[0] >> 32;
ipn_eid.node_number := enc_eid[0] & (2^32-1); ipn_eid.node_number := enc_eid[0] & (2^32-1);
ipn_eid.service_number := enc_eid[1]; ipn_eid.service_number := enc_eid[1];
} }
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="cbor-encoding"> <section anchor="cbor-encoding">
<name>ipn URI Scheme CBOR syntax</name> <name>ipn URI Scheme CBOR Syntax</name>
<t>A BPv7 endpoint identified by an ipn URI, when encoded in Concise Bin
ary Object Representation (CBOR) <xref target="RFC8949"/>, <bcp14>MUST</bcp14> c <t>When encoded in CBOR <xref
omply with the following Concise Data Definition Language (CDDL) <xref target="R target="RFC8949"/>, a BPv7 endpoint identified by an ipn URI
FC8610"/> specification:</t> <bcp14>MUST</bcp14> comply with the following Concise Data Definition
<artwork type="cddl" align="left"><![CDATA[ Language (CDDL) <xref target="RFC8610"/> specification:</t>
<sourcecode type="cddl"><![CDATA[
eid = $eid .within eid-structure eid = $eid .within eid-structure
eid-structure = [ eid-structure = [
uri-code: uint, uri-code: uint,
SSP: any SSP: any
] ]
; ... Syntax for other uri-code values defined in RFC9171 ... ; ... Syntax for other uri-code values defined in RFC 9171 ...
$eid /= [ $eid /= [
uri-code: 2, uri-code: 2,
SSP: ipn-ssp2 / ipn-ssp3 SSP: ipn-ssp2 / ipn-ssp3
] ]
ipn-ssp2 = [ ipn-ssp2 = [
fqnn: uint, ; packed value fqnn: uint, ; packed value
service-number: uint service-number: uint
] ]
ipn-ssp3 = [ ipn-ssp3 = [
allocator-identifier: uint .lt 4294967296, allocator-identifier: uint .lt 4294967296,
node-number: uint .lt 4294967296, node-number: uint .lt 4294967296,
service-number: uint service-number: uint
] ]
]]></artwork> ]]></sourcecode>
<t>Note: The <tt>node-number</tt> component will be the numeric represen
tation of the concatenation of the Allocator Identifier and Node Number when the <t>Note: The <tt>node-number</tt> component will be the numeric
2-element encoding scheme has been used.</t> representation of the concatenation of the Allocator Identifier and
Node Number when the two-element encoding scheme has been used.</t>
</section> </section>
<section anchor="ipn-eid-matching"> <section anchor="ipn-eid-matching">
<name>ipn EID Matching</name> <name>ipn EID Matching</name>
<t>Regardless of whether the two-element or three-element scheme-specifi <t>Regardless of whether the two-element or three-element
c encoding is used, ipn EID matching <bcp14>MUST</bcp14> be performed on the dec scheme-specific encoding is used, ipn EID matching <bcp14>MUST</bcp14>
oded EID information itself. Different encodings of the same ipn EID <bcp14>MUST be performed on the decoded EID information itself. Different
</bcp14> be treated as equivalent when performing EID-specific functions.</t> encodings of the same ipn EID <bcp14>MUST</bcp14> be treated as
<t>For example, the ipn EID of <tt>ipn:977000.100.1</tt> can be represen equivalent when performing EID-specific functions.</t>
ted as either the two-element encoding of <tt>0x821B000EE8680000006401</tt> or t
he three-element encoding of <tt>0x831A000EE868186401</tt>. While message integr <t>For example, the ipn EID of <tt>ipn:977000.100.1</tt> can be
ity and other syntax-based checks may treat these values differently, any EID-ba represented as either the two-element encoding of
sed comparisons <bcp14>MUST</bcp14> treat these values the same - as representin <tt>0x821B000EE8680000006401</tt> or the three-element encoding of
g the ipn EID <tt>ipn:977000.100.1</tt>.</t> <tt>0x831A000EE868186401</tt>. While message integrity and other
syntax-based checks may treat these values differently, any EID-based
comparisons <bcp14>MUST</bcp14> treat these values the same: as
representing the ipn EID <tt>ipn:977000.100.1</tt>.</t>
</section> </section>
</section> </section>
<section anchor="special-considerations"> <section anchor="special-considerations">
<name>Special Considerations</name> <name>Special Considerations</name>
<t>The ipn URI scheme provides a compact and hierarchical mechanism for id
entifying services on network nodes. There is a significant amount of utility in <t>The ipn URI scheme provides a compact and hierarchical mechanism for
the ipn URI scheme approach to identification. However, implementers should tak identifying services on network nodes. There is a significant amount of
e into consideration the following observations on the use of the ipn URI scheme utility in the ipn URI scheme approach to identification. However,
, particularly in regard to interoperability with implementations that pre-date implementers should take into consideration the following observations
this specification.</t> on the use of the ipn URI scheme, particularly in regard to
interoperability with implementations that pre-date this
specification.</t>
<section anchor="compatibility"> <section anchor="compatibility">
<name>Scheme Compatibility</name> <name>Scheme Compatibility</name>
<t>The ipn scheme update that has been presented in this document preser
ves backwards compatibility with any ipn URI scheme going back to the provisiona <t>The ipn scheme update that has been presented in this document
l definition of the ipn scheme in the experimental Compressed Bundle Header Enco preserves backwards compatibility with any ipn URI scheme going back
ding <xref target="RFC6260"/> specification in 2011. This means that any ipn URI to the provisional definition of the ipn scheme in the experimental
that was valid prior to the publication of this update remains a valid ipn URI. specification "Compressed Bundle Header Encoding (CBHE)" <xref
</t> target="RFC6260"/> in 2011. This means that any ipn URI that was valid
<t>Similarly, the <xref target="two-encode">two-element scheme-specific prior to the publication of this update remains a valid ipn URI.</t>
encoding</xref> is also backwards-compatible with the encoding of ipn URIs provi
ded in <xref target="RFC9171"/>. Any existing RFC9171-compliant implementation w <t>Similarly, the <xref target="two-encode">two-element
ill produce an ipn URI encoding in compliance with this specification.</t> scheme-specific encoding</xref> is also backwards compatible with the
<t>The introduction of optional non-default Allocator Identifiers and a encoding of ipn URIs provided in <xref target="RFC9171"/>. Any
three-element scheme-specific encoding does not make this ipn URI scheme update existing implementation compliant with <xref target="RFC9171"/> will
forwards-compatible. Existing implementations for which support of this update i produce an ipn URI encoding in compliance with this specification.</t>
s desired <bcp14>MUST</bcp14> be updated to be able to process non-default Alloc <t>The introduction of optional non-default Allocator Identifiers and
ator Identifiers and three-element scheme-specific encodings. It is <bcp14>RECOM a three-element scheme-specific encoding does not make this ipn URI
MENDED</bcp14> that BPv7 implementations upgrade to process these new features t scheme update forwards compatible. Existing implementations for which
o benefit from the scalability provided by Allocator Identifiers and the encodin support of this update is desired <bcp14>MUST</bcp14> be updated to be
g efficiencies provided by the three-element encoding.</t> able to process non-default Allocator Identifiers and three-element
scheme-specific encodings. It is <bcp14>RECOMMENDED</bcp14> that BPv7
implementations upgrade to process these new features to benefit from
the scalability provided by Allocator Identifiers and the encoding
efficiencies provided by the three-element encoding.</t>
</section> </section>
<section anchor="cbor-representation-interoperability"> <section anchor="cbor-representation-interoperability">
<name>CBOR Representation Interoperability</name> <name>CBOR Representation Interoperability</name>
<t>Care must be taken when deploying implementations that default to usi <t>Care must be taken when deploying implementations that default to
ng the three-element encoding in networks that include implementations that only using the three-element encoding in networks that include
support the two-element <xref target="RFC9171"/> encoding. Because the existing implementations that only support the two-element encoding <xref
implementations will reject bundles that use the three-element encoding as malf target="RFC9171"/>. Because the existing implementations will reject
ormed, correct forwarding of semantically valid bundles will fail. The used mit bundles that use the three-element encoding as malformed, correct
igation for this issue depends on the nature of the interoperability required by forwarding of semantically valid bundles will fail. The used
the deployment. Techniques can include:</t> mitigation for this issue depends on the nature of the
interoperability required by the deployment. Techniques can
include:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>A configuration option indicating when an implementation must use <t>A configuration option indicating when an implementation must
the two-element encoding for all ipn EIDs when processing bundles destined to a use the two-element encoding for all ipn EIDs when processing
given endpoint: This would be suitable when adding a newer implementation to a bundles destined to a given endpoint. This would be suitable when
network of existing implementations.</t> adding a newer implementation to a network of existing
implementations.</t>
</li> </li>
<li> <li>
<t>Selective bundle encapsulation, whereby bundles that are known to <t>Selective bundle encapsulation, whereby bundles that are known
originate from implementations that do not support the three-element encoding a to originate from implementations that do not support the
re tunnelled across regions of the network that require the three-element encodi three-element encoding are tunneled across regions of the network
ng: This would utilize specially configured 'gateway nodes' to perform the tunn that require the three-element encoding. This would utilize
el encapsulation and decapsulation, and would be suitable when joining an existi specially configured "gateway nodes" to perform the tunnel
ng network to a larger network.</t> encapsulation and decapsulation and would be suitable when
joining an existing network to a larger network.</t>
</li> </li>
</ul> </ul>
<t>Techniques that do not mitigate the problem include:</t> <t>Techniques that do not mitigate the problem include:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Heuristic determination of the correct encoding to use when respo <t>Heuristic determination of the correct encoding to use when
nding to a bundle by examining the incoming bundle: It is not possible to deter responding to a bundle by examining the incoming bundle. It is not
mine whether the two-element encoding is required by the destination when compos possible to determine whether the two-element encoding is required
ing a new bundle in response to the receipt of a bundle, such as a status report by the destination when composing a new bundle in response to the
, because ipn EIDs assigned by the Default Allocator use the two-element encodin receipt of a bundle, such as a status report, because ipn EIDs
g, whether the implementation supports the three-element encoding or not.</t> assigned by the Default Allocator use the two-element encoding,
whether or not the implementation supports the three-element encodin
g.</t>
</li> </li>
<li> <li>
<t>Transcoding bundles at intermediate nodes: <xref target="RFC9171"
/> requires the bundle primary block be immutable, and even if ipn EIDs in the p <t>Transcoding bundles at intermediate nodes. <xref
rimary block do not require rewriting, other blocks including the payload block target="RFC9171"/> requires the bundle primary block to be immutable
may include ipn EIDs of which the transcoding node is unaware. Additionally, bu ,
ndle blocks may be covered by <xref target="RFC9172"/> bundle security blocks or and even if ipn EIDs in the primary block do not require
bundle integrity blocks, making them immutable.</t> rewriting, other blocks including the payload block may include
ipn EIDs of which the transcoding node is unaware.
Additionally,
bundle blocks may be covered by bundle
security blocks or bundle integrity blocks <xref target="RFC9172"/>,
making them
immutable.</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="text-representation-compatibility"> <section anchor="text-representation-compatibility">
<name>Text Representation Compatibility</name> <name>Text Representation Compatibility</name>
<t>The textual representation of ipn URIs is not forwards-compatible wit <t>The textual representation of ipn URIs is not forwards compatible
h <xref target="RFC9171"/>, therefore care must be taken when deploying implemen with <xref target="RFC9171"/>. Therefore, care must be taken when
tations or tooling that use the textural representation of ipn URIs and support deploying implementations or tooling that use the textural
for non-default Allocator Identifiers is required. For example <xref section="4 representation of ipn URIs and support for non-default Allocator
.6" sectionFormat="of" target="RFC9174"/> specifies that the Session Initializat Identifiers is required. For example, <xref section="4.6"
ion message "...<bcp14>SHALL</bcp14> contain the UTF-8 encoded node ID of the en sectionFormat="of" target="RFC9174"/> specifies that the session
tity that sent the SESS_INIT message." In such cases the considerations that ap initialization message "...<bcp14>SHALL</bcp14> contain the UTF-8
ply to the use of the 3-element CBOR encoding also apply to the text representat encoded node ID of the entity that sent the SESS_INIT message." In
ion when a non-default Allocator Identifier is present.</t> such cases, the considerations that apply to the use of the three-elemen
t
CBOR encoding also apply to the text representation when a non-default
Allocator Identifier is present.</t>
</section> </section>
<section anchor="bundle-protocol-version-6-compatibility"> <section anchor="bundle-protocol-version-6-compatibility">
<name>Bundle Protocol Version 6 Compatibility</name> <name>Bundle Protocol Version 6 Compatibility</name>
<t>This document updates the use of ipn EIDs for BPv7, however the ipn U <t>This document updates the use of ipn EIDs for BPv7; however, the ipn
RI scheme was originally defined for use with version 6 of the Bundle Protocol ( URI scheme was originally defined for use with BPv6. This document does
BPv6). This document does not update any of the behaviors, wire-formats or mech not update any of the behaviors,
anisms of BPv6. Therefore, ipn EIDs with non-default Allocator Identifiers <bcp wire-formats, or mechanisms of BPv6. Therefore, ipn EIDs with
14>MUST NOT</bcp14> be used with BPv6, and the Allocator Identifier prefix <bcp1 non-default Allocator Identifiers <bcp14>MUST NOT</bcp14> be used with
4>MUST</bcp14> be omitted from any textural representation. It should be noted BPv6, and the Allocator Identifier prefix <bcp14>MUST</bcp14> be
that BPv6 has no concept of LocalNode EIDs, and will therefore treat such EIDs a omitted from any textural representation. It should be noted that
s routable.</t> BPv6 has no concept of LocalNode EIDs and will therefore treat such
EIDs as routable.</t>
</section> </section>
<section anchor="late-binding"> <section anchor="late-binding">
<name>Late Binding</name> <name>Late Binding</name>
<t><xref target="RFC9171"/> mandates the concept of "late binding" of an
EID, whereby the address of the destination of a bundle is resolved from its id <t><xref target="RFC9171"/> mandates the concept of the "late binding" o
entifier hop-by-hop as it transits a BPv7 network. This per-hop binding of iden f
tifiers to addresses underlines the fact that EIDs are purely names, and should an EID, whereby the address of the destination of a bundle is resolved
not carry any implicit or explicit information concerning the current location o from its hop-by-hop identifier as it transits a BPv7 network. This
r reachability of an identified node and service. This removes the need to rena per-hop binding of identifiers to addresses underlines the fact that
me a node as its location changes.</t> EIDs are purely names and should not carry any implicit or explicit
<t>The concept of "late binding" is preserved in this ipn URI scheme. El information concerning the current location or reachability of an
ements of an ipn URI <bcp14>MUST NOT</bcp14> be regarded as carrying information identified node and service. This removes the need to rename a node
relating to location, reachability, or other addressing/routing concern.</t> as its location changes.</t>
<t>An example of incorrect behavior would be to assume that a given Allo
cator assigns Node Numbers derived from link-layer addresses and to interpret th <t>The concept of late binding is preserved in this ipn URI
e Node Number component of an ipn URI directly as a link-layer address. No matte scheme. Elements of an ipn URI <bcp14>MUST NOT</bcp14> be regarded as
r the mechanism an Allocator uses for the assignment of Node Numbers, they remai carrying information relating to location, reachability, or other
n just numbers, without additional meaning.</t> addressing/routing concerns.</t>
<t>An example of incorrect behavior would be to assume that a given
Allocator assigns Node Numbers derived from link-layer addresses and
to interpret the Node Number component of an ipn URI directly as a
link-layer address. No matter the mechanism an Allocator uses for the
assignment of Node Numbers, they remain just numbers, without
additional meaning.</t>
</section> </section>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This section updates the security considerations from <xref section="4. <t>This section updates the security considerations from <xref
2.5.1.2" sectionFormat="of" target="RFC9171"/> to account for the inclusion of A section="4.2.5.1.2" sectionFormat="of" target="RFC9171"/> to account for
llocator Identifiers in the ipn URI scheme when used with BPv7.</t> the inclusion of Allocator Identifiers in the ipn URI scheme when used
with BPv7.</t>
<section anchor="reliability-and-consistency"> <section anchor="reliability-and-consistency">
<name>Reliability and consistency</name> <name>Reliability and Consistency</name>
<t>None of the BPv7 endpoints identified by ipn EIDs are guaranteed to b <t>None of the BPv7 endpoints identified by ipn EIDs are guaranteed to
e reachable at any time, and the identity of the processing entities operating o be reachable at any time, and the identity of the processing entities
n those endpoints is never guaranteed by the Bundle Protocol itself. Verificatio operating on those endpoints is never guaranteed by the Bundle
n of the signature provided by the Block Integrity Block targeting the bundle's Protocol itself. Verification of the signature provided by the Block
primary block, as defined by Bundle Protocol Security <xref target="RFC9172"/>, Integrity Block (BIB) targeting the bundle's primary block, as defined b
is required for this purpose.</t> y
<xref target="RFC9172">"Bundle Protocol Security (BPSec)"</xref>, is req
uired for
this purpose.</t>
</section> </section>
<!-- [rfced] In the text below, should "such as the use of" read as "such as
with the use of"?
Original:
In both cases (and indeed in all bundle processing), the node that
receives a bundle should verify its authenticity and validity
before operating on it in any way, such as the use of BPSec
[RFC9172], and TCPCLv4 with TLS [RFC9174].
Perhaps:
In both cases (and indeed in all bundle processing), the node that
receives a bundle should verify its authenticity and validity
before operating on it in any way, such as with the use of BPSec
[RFC9172] and TCP Convergence Layer version 4 (TCPCLv4) with TLS
[RFC9174].
-->
<section anchor="malicious-construction"> <section anchor="malicious-construction">
<name>Malicious construction</name> <name>Malicious Construction</name>
<t>Malicious construction of a conformant ipn URI is limited to the mali <t>Malicious construction of a conformant ipn URI is limited to the
cious selection of Allocator Identifiers, Node Numbers, and Service Numbers. Tha malicious selection of Allocator Identifiers, Node Numbers, and
t is, a maliciously constructed ipn EID could be used to direct a bundle to an e Service Numbers. That is, a maliciously constructed ipn EID could be
ndpoint that might be damaged by the arrival of that bundle or, alternatively, t used to direct a bundle to an endpoint that might be damaged by the
o declare a false source for a bundle and thereby cause incorrect processing at arrival of that bundle or, alternatively, to declare a false source
a node that receives the bundle. In both cases (and indeed in all bundle process for a bundle and thereby cause incorrect processing at a node that
ing), the node that receives a bundle should verify its authenticity and validit receives the bundle. In both cases (and indeed in all bundle
y before operating on it in any way, such as the use of BPSec <xref target="RFC9 processing), the node that receives a bundle should verify its
172"/>, and TCPCLv4 with TLS <xref target="RFC9174"/>.</t> authenticity and validity before operating on it in any way, such as
the use of BPSec <xref target="RFC9172"/> and TCP Convergence Layer vers
ion 4 (TCPCLv4) with TLS <xref
target="RFC9174"/>.</t>
</section> </section>
<section anchor="back-end-transcoding"> <section anchor="back-end-transcoding">
<name>Back-end transcoding</name> <name>Back-End Transcoding</name>
<t>The limited expressiveness of URIs of the ipn scheme effectively elim <t>The limited expressiveness of URIs of the ipn scheme effectively
inates the possibility of threat due to errors in back-end transcoding.</t> eliminates the possibility of threats due to errors in back-end
transcoding.</t>
</section> </section>
<section anchor="local-and-private-use-ipn-eids"> <section anchor="local-and-private-use-ipn-eids">
<name>Local and Private Use ipn EIDs</name> <name>Local and Private Use ipn EIDs</name>
<t>Both <xref target="localnode-uri">LocalNode</xref> and <xref target=" <t>Both <xref target="localnode-uri">LocalNode</xref> and <xref
private-use">Private Use</xref> ipn URIs present a risk to the stability of depl target="private-use">Private Use</xref> ipn URIs present a risk to the
oyed BPv7 networks. If either type of ipn URI are allowed to propagate beyond t stability of deployed BPv7 networks. If either type of ipn URI is
he domain in which they are valid, then the required uniqueness of ipn URIs no l allowed to propagate beyond the domain in which they are valid, then
onger holds, and this fact can be abused by a malicious node to prevent the corr the required uniqueness of ipn URIs no longer holds, and this fact can
ect functioning of the network as a whole.</t> be abused by a malicious node to prevent the correct functioning of
<t>See <xref target="localnode-ipn-eids">LocalNode ipn EIDs</xref> and < the network as a whole.</t>
xref target="private-use-ipn-eids">Private Use ipn EIDs</xref> for required beha <t>See <xref target="localnode-ipn-eids">"LocalNode ipn EIDs"</xref> and
viors to mitigate against this form of abuse.</t> <xref target="private-use-ipn-eids">"Private Use ipn EIDs"</xref> for
required behaviors to mitigate against this form of abuse.</t>
</section> </section>
<section anchor="sensitive-information"> <section anchor="sensitive-information">
<name>Sensitive information</name> <name>Sensitive Information</name>
<t>Because ipn URIs are used only to represent the numeric identities of <t>Because ipn URIs are used only to represent the numeric identities
resources, the risk of disclosure of sensitive information due to interception of resources, the risk of disclosure of sensitive information due to
of these URIs is minimal. Examination of ipn URIs could be used to support traff interception of these URIs is minimal. Examination of ipn URIs could
ic analysis; where traffic analysis is a plausible danger, bundles should be con be used to support traffic analysis; where traffic analysis is a
veyed by secure convergence-layer protocols that do not expose endpoint IDs, suc plausible danger, bundles should be conveyed by secure
h as TCPCLv4 <xref target="RFC9174"/>.</t> convergence-layer protocols that do not expose endpoint IDs, such as
TCPCLv4 <xref target="RFC9174"/>.</t>
</section> </section>
<section anchor="semantic-attacks"> <section anchor="semantic-attacks">
<name>Semantic attacks</name> <name>Semantic Attacks</name>
<t>The simplicity of ipn URI scheme syntax minimizes the possibility of <t>The simplicity of the ipn URI scheme syntax minimizes the possibility
misinterpretation of a URI by a human user.</t> of misinterpretation of a URI by a human user.</t>
</section> </section>
</section> </section>
<section anchor="iana"> <section anchor="iana">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>The following sections detail requests to IANA for the creation of two
new registries, and the renaming of an existing registry.</t> <!-- [rfced] We have included some specific questions about the IANA
<t>IANA is requested to update the reference to the 'ipn' scheme in the "U text below. In addition to responding to those questions, please
niform Resource Identifier (URI) Schemes" registry to this document.</t> review all of the IANA-related updates carefully and let us know
<t>IANA is requested to add the new registries, and relocate the existing if any further updates are needed. Note that the registries can be
registries under the "Uniform Resource Identifier (URI) Schemes" protocol regist viewed at <https://www.iana.org/assignments/uri-schemes/>.
ry.</t>
a.) We note different capitalization and use of quotation marks around
"Private Use" in the running text. We have removed the quote marks for
consistency as the policies of RFC 8126 usually appear as uppercase
without quote marks.
b.) The registration procedures in Table 4 do not match the registration
procedures for the "'ipn' Scheme URI Default Allocator Node Numbers"
registry. We updated the reference entries accordingly (see Tables 4 and 5).
Please review and let us know if any further changes are needed.
c.) FYI: We have made "Well-Known" uppercase in the "'ipn' Scheme URI
Well-Known Service Numbers for BPv7" registry name, and we will ask
IANA to make this change prior to publication.
d.) We updated Tables 6 and 7 to match the "'ipn' Scheme URI
Well-Known Service Numbers for BPv7" registry. Please let us
know if any further changes are needed.
e.) In Tables 2, 4, and 6, we updated "Registration Policy" to
"Registration Procedures" in the column headings to match the
respective IANA registries. In the running text, may we update
instances of "registration policies" to "registration procedures"
for consistency?
f.) In Tables 2, 4, 6, and 7, we assume that ">= 2^32" is the same as
">=0x100000000" in the IANA registries. Are any changes desired in
the document to make this consistent with the IANA registries, or will
this variance be clear to readers?
i.) We note the following variances in the IANA registries. Should
these be made consistent by replacing "greater than" with ">="?
In the "'ipn' Scheme URI Allocator Identifiers" and "'ipn' Scheme URI
Default Allocator Node Numbers" registries:
">=0x100000000"
In the "'ipn' Scheme URI Well-Known Service Numbers for BPv7"
registry:
"greater than 0x100000000"
ii.) FYI: In Table 5, we replaced ">= 2^32" with ">=4294967296"
("Invalid") to match the "'ipn' Scheme URI Default Allocator Node
Numbers" registry. Please let us know if this is not correct.
-->
<t>The following sections detail the creation of
two new IANA registries and the renaming of an existing IANA registry unde
r the "Uniform Resource Identifier (URI) Schemes" registry group.</t>
<t>IANA has also updated the reference for the 'ipn' scheme to this docume
nt in the
"Uniform Resource Identifier (URI) Schemes" registry.</t>
<section anchor="iana-allocator-identifiers"> <section anchor="iana-allocator-identifiers">
<name>'ipn' Scheme URI Allocator Identifiers registry</name> <name>'ipn' Scheme URI Allocator Identifiers Registry</name>
<t>IANA is requested to create a new registry entitled "'ipn' Scheme URI <t>IANA has created a new registry titled "'ipn' Scheme
Allocator Identifiers". The registration policy for this registry, using terms URI Allocator Identifiers". Using terms defined in <xref
defined in <xref target="RFC8126"/>, is:</t> target="RFC8126"/>, the registration policies for this registry are:</t>
<table align="left" anchor="tab-ipn-allocator-identifiers-reg">
<name>'ipn' Scheme URI Numbering Allocator Identifiers registration po <table align="center" anchor="tab-ipn-allocator-identifiers-reg">
licies</name> <name>Registration Policies for the 'ipn' Scheme URI Allocator Identif
iers Registry</name>
<thead> <thead>
<tr> <tr>
<th align="center">Range</th> <th align="left">Range</th>
<th align="left">Registration Policy</th> <th align="left">Registration Procedures</th>
<th align="left">Note</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center">0..0xFFFF</td> <td align="left">0..0xFFFF</td>
<td align="left">Expert Review, Single Allocator Identifiers only< <td align="left">Expert Review</td>
/td> <td>Single Allocator Identifiers only</td>
</tr> </tr>
<tr> <tr>
<td align="center">0x10000..0x3FFFFFFF</td> <td align="left">0x10000..0x3FFFFFFF</td>
<td align="left">Expert Review</td> <td align="left">Expert Review</td>
<td></td>
</tr> </tr>
<tr> <tr>
<td align="center">0x40000000..0x7FFFFFFF</td> <td align="left">0x40000000..0x7FFFFFFF</td>
<td align="left">Experimental Use</td> <td align="left">Experimental Use</td>
<td></td>
</tr> </tr>
<tr> <tr>
<td align="center">0x80000000..0xFFFFFFFF</td> <td align="left">0x80000000..0xFFFFFFFF</td>
<td align="left">Reserved, Future Expansion</td> <td align="left">Reserved</td>
<td> Future Expansion</td>
</tr> </tr>
<tr> <tr>
<td align="center">&gt;= 2^32</td> <td align="left">&gt;= 2<sup>32</sup></td>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Each entry in this registry associates one or more Allocator Identifi
ers with a single organization. Within the registry, the organization is identif <t>Each entry in this registry associates one or more Allocator
ied using the "Name" and "Point of Contact" fields. It is expected that each ide Identifiers with a single organization. Within the registry, the
ntified organization publishes some listing of allocated node numbers - the poin organization is identified using the "Name" and "Change Controller"
ter to which is listed in the "Reference" field of the registry.</t> fields. It is expected that each identified organization will publish
<t>Note that the “Single Allocator Identifiers only” language in Registr some listing of allocated Node Numbers, the pointer to which is
ation Policy for this registry indicates that, within the indicated range, the a listed in the "Reference" field of the registry.</t>
llocation of a sequence of consecutive Allocator identifiers to a single organiz
ation is prohibited. IANA is requested to note this in the registration policy <t>Note that the "Single Allocator Identifiers only" language in
for this registry.</t> the registration policy for this registry indicates that, within the
<t>The initial values for the registry are:</t> indicated range, the allocation of a sequence of consecutive Allocator
<table align="left" anchor="tab-ipn-allocator-identifiers-vals"> Identifiers to a single organization is prohibited.</t>
<name>'ipn' Scheme URI Allocator Identifiers initial values</name>
<t>The initial values in the registry are:</t>
<table align="center" anchor="tab-ipn-allocator-identifiers-vals">
<name>Initial Values in the 'ipn' Scheme URI Allocator Identifiers Reg
istry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="center">Range (dec)</th> <th align="left">Range (dec)</th>
<th align="center">Range (hex)</th> <th align="left">Range (hex)</th>
<th align="center">Range Length (Bits)</th> <th align="left">Range Length (Bits)</th>
<th align="center">Reference</th> <th align="left">Reference</th>
<th align="center">Point of Contact</th> <th align="left">Change Controller</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left"> <td align="left">Default Allocator</td>
<xref target="default-allocator">Default Allocator</xref></td> <td align="left">0</td>
<td align="center">0</td> <td align="left">0x0</td>
<td align="center">0x0</td> <td align="left">0</td>
<td align="center">0</td> <td align="left">RFC 9758, <xref target="default-allocator"/></td>
<td align="center">This document</td> <td align="left">IETF</td>
<td align="center">IANA</td>
</tr> </tr>
<tr> <tr>
<td align="left">Example Range</td> <td align="left">Example Range</td>
<td align="center">974848 .. 978943</td> <td align="left">974848-978943</td>
<td align="center">0xEE000 .. 0xEEFFF</td> <td align="left">0xEE000-0xEEFFF</td>
<td align="center">12 bits</td> <td align="left">12 bits</td>
<td align="center">This document</td> <td align="left">RFC 9758</td>
<td align="center">IANA</td> <td align="left">IETF</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>The "Example Range" is assigned for use in examples in documentation <t>The "Example Range" is assigned for use in examples in
and sample code.</t> documentation and sample code.</t>
<section anchor="guidance-for-designated-experts"> <section anchor="guidance-for-designated-experts">
<name>Guidance for Designated Experts</name> <name>Guidance for Designated Experts</name>
<t>Due to the nature of the CBOR encoding of unsigned integers used fo <t>Due to the nature of the CBOR encoding of unsigned integers used
r Allocator Identifiers with BPv7, Allocator Identifiers with a low value number for Allocator Identifiers with BPv7, Allocator Identifiers with a
are encoded more efficiently than larger numbers. This makes low value Allocat low value number are encoded more efficiently than larger numbers.
or Identifiers more desirable than larger Allocator Identifiers, and therefore c This makes low value Allocator Identifiers more desirable than
are must be taken when assigning Allocator Identifier ranges to ensure that a si larger Allocator Identifiers; therefore, care must be taken when
ngle applicant is not granted a large swathe of highly desirable numbers at the assigning Allocator Identifier ranges to ensure that a single
expense of other applicants. To this end, Designated Experts are strongly recom applicant is not granted a large swathe of highly desirable numbers
mended to familiarize themselves with the CBOR encoding of unsigned integers in at the expense of other applicants. To this end, designated experts
<xref target="RFC8949"/>.</t> are strongly recommended to familiarize themselves with the CBOR
encoding of unsigned integers in <xref target="RFC8949"/>.</t>
</section> </section>
</section> </section>
<section anchor="iana-node-numbers"> <section anchor="iana-node-numbers">
<name>'ipn' Scheme URI Default Allocator Node Numbers registry</name> <name>'ipn' Scheme URI Default Allocator Node Numbers Registry</name>
<t>IANA is requested to rename the "CBHE Node Numbers" registry defined
in <xref section="3.2.1" sectionFormat="of" target="RFC7116"/> to the "'ipn' Sch <t>IANA has renamed the "CBHE Node Numbers" registry
eme URI Default Allocator Node Numbers" registry.</t> (defined in <xref section="3.2.1" sectionFormat="of" target="RFC7116"/>)
<t>The registration policy for this registry, using terms defined in <xr to the "'ipn' Scheme URI Default Allocator Node Numbers" registry and mo
ef target="RFC8126"/>, is updated to be:</t> ved it to the "Uniform Resource Identifier (URI) Schemes" registry group. IANA h
<table align="left" anchor="tab-ipn-node-numbers-reg"> as added the following note to the "CBHE Node Numbers" registry:</t>
<name>'ipn' Scheme URI Default Allocator Node Numbers registration pol
icies</name> <blockquote>
Note: Renamed "CBHE Node Numbers" as "'ipn' Scheme URI Default Allocator Node Nu
mbers" and moved it to &lt;<eref target="https://www.iana.org/assignments/uri-sc
hemes"/>&gt; per RFC 9758.
</blockquote>
<t>Using terms defined in <xref target="RFC8126"/>, the registration
policies for this registry are:</t>
<table align="center" anchor="tab-ipn-node-numbers-reg">
<name>Registration Policies for the 'ipn' Scheme URI Default Allocator
Node Numbers Registry</name>
<thead> <thead>
<tr> <tr>
<th align="center">Range</th> <th align="left">Range</th>
<th align="left">Registration Policy</th> <th align="left">Registration Procedures</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center">0</td> <td align="left">1..0x3FFF</td>
<td align="left">Reserved for the <xref target="null-uri">Null ipn
URI</xref></td>
</tr>
<tr>
<td align="center">1..0x3FFF</td>
<td align="left">Private Use</td> <td align="left">Private Use</td>
</tr> </tr>
<tr> <tr>
<td align="center">0x4000..0xFFFFFFFE</td> <td align="left">0x4000..0xFFFFFFFE</td>
<td align="left">Expert Review</td> <td align="left">Expert Review</td>
</tr>
<tr>
<td align="left">&gt;= 2<sup>32</sup></td>
<td align="left">Invalid</td>
</tr> </tr>
</tbody>
</table>
<t>IANA has registered the following values in the "'ipn' Scheme URI Defa
ult Allocator Node Numbers" registry:</t>
<table align="center" anchor="tab-ipn-scheme-uri-DA-identifiers">
<name>New Values in the 'ipn' Scheme URI Default Allocator Node Number
s Registry</name>
<thead>
<tr> <tr>
<td align="center">0xFFFFFFFF</td> <th align="left">Value</th>
<td align="left">Reserved for <xref target="localnode-uri">LocalNo <th align="left">Description</th>
de ipn URIs</xref></td> <th align="left">Reference</th>
</tr> </tr>
</thead>
<tbody>
<tr> <tr>
<td align="center">&gt;= 2^32</td> <td align="left">0</td>
<td align="left">Reserved for the Null ipn URI</td>
<td align="left"><xref target="RFC7116"/> and RFC 9758, <xref targe
t="null-uri"/></td>
</tr>
<tr>
<td align="left">4294967295</td>
<td align="left">Reserved for LocalNode ipn URIs</td>
<td align="left">RFC 9758, <xref target="localnode-uri"/></td>
</tr>
<tr>
<td align="left">>=4294967296</td>
<td align="left">Invalid</td> <td align="left">Invalid</td>
<td align="left">RFC 9758</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>As IANA is requested to only rename the registry, all existing regist
rations will remain.</t> <!-- <t>IANA has registered the following in the "'ipn' Scheme URI Allocator I
</section> dentifiers" registry:</t>
<section anchor="iana-service-numbers">
<name>'ipn' Scheme URI Well-known Service Numbers for BPv7 registry</nam <table align="center" anchor="tab-ipn-node-numbers-reg-2">
e> <name>New Registration in the 'ipn' Scheme URI Default Allocator Node
<t>IANA is requested to create a new registry entitled "'ipn' Scheme URI Numbers Registry</name>
Well-known Service Numbers for BPv7" registry. The registration policy for thi
s registry, using terms defined in <xref target="RFC8126"/>, is:</t>
<table align="left" anchor="tab-ipn-service-numbers-reg">
<name>'ipn' Scheme URI Well-known Service Numbers for BPv7 registratio
n policies</name>
<thead> <thead>
<tr> <tr>
<th align="center">Range</th> <th align="left">Name</th>
<th align="left">Registration Policy</th> <th align="left">Range (dec)</th>
<th align="left">Range (hex)</th>
<th align="left">Range Length (Bits)</th>
<th align="left">Reference</th>
<th align="left">Change Controller</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center">0</td> <td align="left">Default Allocator</td>
<td align="left">Reserved for the <xref target="administrative-end <td align="left">0</td>
points">Administrative Endpoint</xref></td> <td align="left">0x0</td>
<td align="left">0</td>
<td align="left">RFC 9758</td>
<td align="left">IETF</td>
</tr> </tr>
</tbody>
</table>
-->
<t>As IANA has only renamed the registry, all existing
registrations will remain.</t>
</section>
<section anchor="iana-service-numbers">
<name>'ipn' Scheme URI Well-Known Service Numbers for BPv7 Registry</nam
e>
<t>IANA has created a new registry titled "'ipn' Scheme
URI Well-Known Service Numbers for BPv7". Using terms defined in
<xref target="RFC8126"/>, the registration policies for this registry ar
e:</t>
<table align="center" anchor="tab-ipn-service-numbers-reg">
<name>Registration Policies for the 'ipn' Scheme URI Well-Known Servic
e Numbers for BPv7 Registry</name>
<thead>
<tr> <tr>
<td align="center">1..127</td> <th align="left">Range</th>
<th align="left">Registration Procedures</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">1..127</td>
<td align="left">Private Use</td> <td align="left">Private Use</td>
</tr> </tr>
<tr> <tr>
<td align="center">128..255</td> <td align="left">128..255</td>
<td align="left">Standards Action</td> <td align="left">Standards Action</td>
</tr> </tr>
<tr> <tr>
<td align="center">0x0100..0x7FFF</td> <td align="left">0x0100..0x7FFF</td>
<td align="left">Private Use</td> <td align="left">Private Use</td>
</tr> </tr>
<tr> <tr>
<td align="center">0x8000..0xFFFF</td> <td align="left">0x8000..0xFFFF</td>
<td align="left">Specification Required</td> <td align="left">Specification Required</td>
</tr> </tr>
<tr> <tr>
<td align="center">0x10000..0xFFFFFFFF</td> <td align="left">0x10000..0xFFFFFFFF</td>
<td align="left">Private Use</td> <td align="left">Private Use</td>
</tr> </tr>
<tr> <tr>
<td align="center">&gt;= 2^32</td> <td align="left">&gt;= 2<sup>32</sup></td>
<td align="left">Reserved for future expansion</td> <td align="left">Reserved for future expansion</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>The initial values for the registry are:</t> <t>The initial values for the registry are:</t>
<table align="left" anchor="tab-ipn-service-numbers-vals">
<name>'ipn' Scheme URI Well-known Service Numbers for BPv7 initial val <table align="center" anchor="tab-ipn-service-numbers-vals">
ues</name> <name>Initial Values in the 'ipn' Scheme URI Well-Known Service Number
s for BPv7 Registry</name>
<thead> <thead>
<tr> <tr>
<th align="center">Value</th> <th align="left">Value</th>
<th align="left">Description</th> <th align="left">Description</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center">0</td> <td align="left">0</td>
<td align="left">The <xref target="administrative-endpoints">Admin <td align="left">The Administrative Endpoint</td>
istrative Endpoint</xref></td>
<td align="left"> <td align="left">
<xref target="RFC9171"/>, This document</td> <xref target="RFC9171"/> and RFC 9758, <xref target="administrat ive-endpoints"/></td>
</tr> </tr>
<tr>
<td align="left">1..27</td>
<td align="left">Reserved for Private Use</td>
<td align="left">RFC 9758</td>
</tr>
<tr>
<td align="left">0x0100..0x7FFF</td>
<td align="left">Reserved for Private Use</td>
<td align="left">RFC 9758</td>
</tr>
<tr> <tr>
<td align="center">0xEEE0 .. 0xEEEF</td> <td align="left">0xEEE0..0xEEEF</td>
<td align="left">Example Range</td> <td align="left">Example Range</td>
<td align="left">This document</td> <td align="left">RFC 9758</td>
</tr> </tr>
<tr>
<td align="left">0x10000..0xFFFFFFFF</td>
<td align="left">Reserved for Private Use</td>
<td align="left">RFC 9758</td>
</tr>
<tr>
<td align="left">&gt;= 2<sup>32</sup></td>
<td align="left">Reserved for future expansion</td>
<td align="left">RFC 9758</td>
</tr>
</tbody> </tbody>
</table> </table>
<t>The "Example Range" is assigned for use in examples in documentation <t>The "Example Range" is assigned for use in examples in
and sample code.</t> documentation and sample code.</t>
<section anchor="guidance-for-designated-experts-1"> <section anchor="guidance-for-designated-experts-1">
<name>Guidance for Designated Experts</name> <name>Guidance for Designated Experts</name>
<t>This registry is intended to record the default Service Numbers for <t>This registry is intended to record the default Service Numbers
well-known, interoperable services available and of use to the entire BPv7 comm for well-known, interoperable services that are available and of use t
unity, hence all ranges not marked for Private Use <bcp14>MUST</bcp14> have a co o the
rresponding publicly available specification describing how one interfaces with entire BPv7 community; hence, all ranges not marked for Private Use
the service.</t> <bcp14>MUST</bcp14> have a corresponding publicly available
<t>Services that are specific to a particular deployment or co-operati specification describing how one interfaces with the service.</t>
on may require a registry to reduce administrative burden, but do not require an <t>Services that are specific to a particular deployment or
entry in this registry.</t> co-operation may require a registry to reduce administrative burden,
but do not require an entry in this registry.</t>
</section> </section>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC6260"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<front> 260.xml"/>
<title>Compressed Bundle Header Encoding (CBHE)</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<author fullname="S. Burleigh" initials="S." surname="Burleigh"/> 116.xml"/>
<date month="May" year="2011"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<abstract> 171.xml"/>
<t>This document describes a convention by which Delay-Tolerant Ne <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
tworking (DTN) Bundle Protocol (BP) "convergence-layer" adapters may represent e 119.xml"/>
ndpoint identifiers in a compressed form within the primary blocks of bundles, p <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
rovided those endpoint identifiers conform to the structure prescribed by this c 174.xml"/>
onvention.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<t>Compressed Bundle Header Encoding (CBHE) compression is a conve 126.xml"/>
rgence-layer adaptation. It is opaque to bundle processing. Therefore, it has no <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
impact on the interoperability of different Bundle Protocol implementations, bu 234.xml"/>
t instead affects only the interoperability of different convergence-layer adapt <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
ation implementations.</t> 949.xml"/>
<t>This document is a product of the Delay-Tolerant Networking Res <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
earch Group and has been reviewed by that group. No objections to its publicatio 610.xml"/>
n as an RFC were raised. This document defines an Experimental Protocol for the
Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6260"/>
<seriesInfo name="DOI" value="10.17487/RFC6260"/>
</reference>
<reference anchor="RFC7116">
<front>
<title>Licklider Transmission Protocol (LTP), Compressed Bundle Head
er Encoding (CBHE), and Bundle Protocol IANA Registries</title>
<author fullname="K. Scott" initials="K." surname="Scott"/>
<author fullname="M. Blanchet" initials="M." surname="Blanchet"/>
<date month="February" year="2014"/>
<abstract>
<t>The DTNRG Research Group has defined the experimental Licklider
Transmission Protocol (LTP) and the Compressed Bundle Header Encoding (CBHE) me
chanism for the InterPlanetary Network ('ipn' URI scheme). Moreover, RFC 5050 de
fines values for the Bundle Protocol administrative record type. All of these fi
elds are subject to a registry. For the purpose of its research work, the group
has created ad hoc registries. As the specifications are stable and have multipl
e interoperable implementations, the group would like to hand off the registries
to IANA for official management. This document describes the necessary IANA act
ions.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7116"/>
<seriesInfo name="DOI" value="10.17487/RFC7116"/>
</reference>
<reference anchor="RFC9171">
<front>
<title>Bundle Protocol Version 7</title>
<author fullname="S. Burleigh" initials="S." surname="Burleigh"/>
<author fullname="K. Fall" initials="K." surname="Fall"/>
<author fullname="E. Birrane, III" initials="E." surname="Birrane, I
II"/>
<date month="January" year="2022"/>
<abstract>
<t>This document presents a specification for the Bundle Protocol,
adapted from the experimental Bundle Protocol specification developed by the De
lay-Tolerant Networking Research Group of the Internet Research Task Force and d
ocumented in RFC 5050.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9171"/>
<seriesInfo name="DOI" value="10.17487/RFC9171"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="June" year="2017"/>
<abstract>
<t>Many protocols make use of points of extensibility that use con
stants to identify various protocol parameters. To ensure that the values in the
se fields do not have conflicting uses and to promote interoperability, their al
locations are often coordinated by a central record keeper. For IETF protocols,
that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance des
cribing the conditions under which new values should be assigned, as well as whe
n and how modifications to existing values can be made, is needed. This document
defines a framework for the documentation of these guidelines by specification
authors, in order to assure that the provided guidance for the IANA Consideratio
ns is clear and addresses the various issues that are likely in the operation of
a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 52
26.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
<reference anchor="RFC5234">
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author fullname="D. Crocker" initials="D." role="editor" surname="C
rocker"/>
<author fullname="P. Overell" initials="P." surname="Overell"/>
<date month="January" year="2008"/>
<abstract>
<t>Internet technical specifications often need to define a formal
syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Au
gmented BNF (ABNF), has been popular among many Internet specifications. The cur
rent specification documents ABNF. It balances compactness and simplicity with r
easonable representational power. The differences between standard BNF and ABNF
involve naming rules, repetition, alternatives, order-independence, and value ra
nges. This specification also supplies additional rule definitions and encoding
for a core lexical analyzer of the type common to several Internet specification
s. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="68"/>
<seriesInfo name="RFC" value="5234"/>
<seriesInfo name="DOI" value="10.17487/RFC5234"/>
</reference>
<reference anchor="RFC8949">
<front>
<title>Concise Binary Object Representation (CBOR)</title>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<date month="December" year="2020"/>
<abstract>
<t>The Concise Binary Object Representation (CBOR) is a data forma
t whose design goals include the possibility of extremely small code size, fairl
y small message size, and extensibility without the need for version negotiation
. These design goals make it different from earlier binary serializations such a
s ASN.1 and MessagePack.</t>
<t>This document obsoletes RFC 7049, providing editorial improveme
nts, new details, and errata fixes while keeping full compatibility with the int
erchange format of RFC 7049. It does not create a new version of the format.</t>
</abstract>
</front>
<seriesInfo name="STD" value="94"/>
<seriesInfo name="RFC" value="8949"/>
<seriesInfo name="DOI" value="10.17487/RFC8949"/>
</reference>
<reference anchor="RFC8610">
<front>
<title>Concise Data Definition Language (CDDL): A Notational Convent
ion to Express Concise Binary Object Representation (CBOR) and JSON Data Structu
res</title>
<author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
<author fullname="C. Vigano" initials="C." surname="Vigano"/>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<date month="June" year="2019"/>
<abstract>
<t>This document proposes a notational convention to express Conci
se Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal
is to provide an easy and unambiguous way to express structures for protocol me
ssages and data formats that use CBOR or JSON.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8610"/>
<seriesInfo name="DOI" value="10.17487/RFC8610"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC5050"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<front> 050.xml"/>
<title>Bundle Protocol Specification</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<author fullname="K. Scott" initials="K." surname="Scott"/> 632.xml"/>
<author fullname="S. Burleigh" initials="S." surname="Burleigh"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
<date month="November" year="2007"/> 918.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<t>This document describes the end-to-end protocol, block formats, 986.xml"/>
and abstract service description for the exchange of messages (bundles) in Dela <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
y Tolerant Networking (DTN).</t> 172.xml"/>
<t>This document was produced within the IRTF's Delay Tolerant Net <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
working Research Group (DTNRG) and represents the consensus of all of the active 174.xml"/>
contributors to this group. See http://www.dtnrg.org for more information. This
memo defines an Experimental Protocol for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5050"/>
<seriesInfo name="DOI" value="10.17487/RFC5050"/>
</reference>
<reference anchor="RFC4632">
<front>
<title>Classless Inter-domain Routing (CIDR): The Internet Address A
ssignment and Aggregation Plan</title>
<author fullname="V. Fuller" initials="V." surname="Fuller"/>
<author fullname="T. Li" initials="T." surname="Li"/>
<date month="August" year="2006"/>
<abstract>
<t>This memo discusses the strategy for address assignment of the
existing 32-bit IPv4 address space with a view toward conserving the address spa
ce and limiting the growth rate of global routing state. This document obsoletes
the original Classless Inter-domain Routing (CIDR) spec in RFC 1519, with chang
es made both to clarify the concepts it introduced and, after more than twelve y
ears, to update the Internet community on the results of deploying the technolog
y described. This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for improvements.</t
>
</abstract>
</front>
<seriesInfo name="BCP" value="122"/>
<seriesInfo name="RFC" value="4632"/>
<seriesInfo name="DOI" value="10.17487/RFC4632"/>
</reference>
<reference anchor="RFC1918">
<front>
<title>Address Allocation for Private Internets</title>
<author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
<author fullname="B. Moskowitz" initials="B." surname="Moskowitz"/>
<author fullname="D. Karrenberg" initials="D." surname="Karrenberg"/
>
<author fullname="G. J. de Groot" initials="G. J." surname="de Groot
"/>
<author fullname="E. Lear" initials="E." surname="Lear"/>
<date month="February" year="1996"/>
<abstract>
<t>This document describes address allocation for private internet
s. This document specifies an Internet Best Current Practices for the Internet C
ommunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="5"/>
<seriesInfo name="RFC" value="1918"/>
<seriesInfo name="DOI" value="10.17487/RFC1918"/>
</reference>
<reference anchor="RFC3986">
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee
"/>
<author fullname="R. Fielding" initials="R." surname="Fielding"/>
<author fullname="L. Masinter" initials="L." surname="Masinter"/>
<date month="January" year="2005"/>
<abstract>
<t>A Uniform Resource Identifier (URI) is a compact sequence of ch
aracters that identifies an abstract or physical resource. This specification de
fines the generic URI syntax and a process for resolving URI references that mig
ht be in relative form, along with guidelines and security considerations for th
e use of URIs on the Internet. The URI syntax defines a grammar that is a supers
et of all valid URIs, allowing an implementation to parse the common components
of a URI reference without knowing the scheme-specific requirements of every pos
sible identifier. This specification does not define a generative grammar for UR
Is; that task is performed by the individual specifications of each URI scheme.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/>
<seriesInfo name="DOI" value="10.17487/RFC3986"/>
</reference>
<reference anchor="RFC9172">
<front>
<title>Bundle Protocol Security (BPSec)</title>
<author fullname="E. Birrane, III" initials="E." surname="Birrane, I
II"/>
<author fullname="K. McKeever" initials="K." surname="McKeever"/>
<date month="January" year="2022"/>
<abstract>
<t>This document defines a security protocol providing data integr
ity and confidentiality services for the Bundle Protocol (BP).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9172"/>
<seriesInfo name="DOI" value="10.17487/RFC9172"/>
</reference>
<reference anchor="RFC9174">
<front>
<title>Delay-Tolerant Networking TCP Convergence-Layer Protocol Vers
ion 4</title>
<author fullname="B. Sipos" initials="B." surname="Sipos"/>
<author fullname="M. Demmer" initials="M." surname="Demmer"/>
<author fullname="J. Ott" initials="J." surname="Ott"/>
<author fullname="S. Perreault" initials="S." surname="Perreault"/>
<date month="January" year="2022"/>
<abstract>
<t>This document describes a TCP convergence layer (TCPCL) for Del
ay-Tolerant Networking (DTN). This version of the TCPCL protocol resolves implem
entation issues in the earlier TCPCL version 3 as defined in RFC 7242 and provid
es updates to the Bundle Protocol (BP) contents, encodings, and convergence-laye
r requirements in BP version 7 (BPv7). Specifically, TCPCLv4 uses BPv7 bundles e
ncoded by the Concise Binary Object Representation (CBOR) as its service data un
it being transported and provides a reliable transport of such bundles. This TCP
CL version also includes security and extensibility mechanisms.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9174"/>
<seriesInfo name="DOI" value="10.17487/RFC9174"/>
</reference>
</references> </references>
</references> </references>
<?line 574?>
<section anchor="text-examples"> <section anchor="text-examples">
<name>ipn URI Scheme Text Representation Examples</name> <name>ipn URI Scheme Text Representation Examples</name>
<t>This section provides some example ipn URIs in their textual representa tion.</t> <t>This section provides some example ipn URIs in their textual representa tion.</t>
<section anchor="using-the-default-allocator"> <section anchor="using-the-default-allocator">
<name>Using the Default Allocator</name> <name>Using the Default Allocator</name>
<t>Consider the ipn URI identifying Service Number 2 on Node Number 1 al
located by the <xref target="default-allocator">Default Allocator</xref> (0).</t <t>Consider the ipn URI identifying Service Number 2 on Node Number 1
> allocated by the <xref target="default-allocator">Default
<t>The recommended seven character representation of this URI would be a Allocator (0)</xref>.</t>
s follows:</t>
<t>The recommended seven-character representation of this URI would be
as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
ipn:1.2 ipn:1.2
]]></artwork> ]]></artwork>
<t>The nine character representation of this URI, with explicit the Allo
cator Identifier, would be as follows:</t> <t>The nine-character representation of this URI, with the explicit Allo
cator Identifier, would be as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
ipn:0.1.2 ipn:0.1.2
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="using-a-non-default-allocator"> <section anchor="using-a-non-default-allocator">
<name>Using a non-default Allocator</name> <name>Using a Non-Default Allocator</name>
<t>Consider the ipn URI identifying Service Number 3 on Node Number 1 al located by Allocator 977000.</t> <t>Consider the ipn URI identifying Service Number 3 on Node Number 1 al located by Allocator 977000.</t>
<t>The 14 character representation of this URI would be as follows:</t> <t>The 14-character representation of this URI would be as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
ipn:977000.1.3 ipn:977000.1.3
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="the-null-ipn-uri"> <section anchor="the-null-ipn-uri">
<name>The Null ipn URI</name> <name>The Null ipn URI</name>
<t>The <xref target="null-uri">Null ipn URI</xref> is represented as:</t > <t>The <xref target="null-uri">Null ipn URI</xref> is represented as:</t >
<artwork><![CDATA[ <artwork><![CDATA[
ipn:0.0 ipn:0.0
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="a-localnode-ipn-uri"> <section anchor="a-localnode-ipn-uri">
<name>A LocalNode ipn URI</name> <name>The LocalNode ipn URI</name>
<t>Consider the ipn URI identifying Service Number 7 on the local node.<
/t> <t>Consider the ipn URI identifying Service Number 7 on the local
<t>The recommended seven character representation of this URI would be a node.</t>
s follows:</t>
<t>The recommended seven-character representation of this URI would be
as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
ipn:!.7 ipn:!.7
]]></artwork> ]]></artwork>
<t>The numeric 16 character representation of this URI would be as follo
ws:</t> <t>The numeric 16-character representation of this URI would be as follo
ws:</t>
<artwork><![CDATA[ <artwork><![CDATA[
ipn:4294967295.7 ipn:4294967295.7
]]></artwork> ]]></artwork>
</section> </section>
</section> </section>
<section anchor="cbor-examples"> <section anchor="cbor-examples">
<name>ipn URI Scheme CBOR Encoding Examples</name> <name>ipn URI Scheme CBOR Encoding Examples</name>
<t>This section provides some example CBOR encodings of ipn EIDs.</t> <t>This section provides some example CBOR encodings of ipn EIDs.</t>
<section anchor="using-the-default-allocator-1"> <section anchor="using-the-default-allocator-1">
<name>Using the Default Allocator</name> <name>Using the Default Allocator</name>
<t>Consider the ipn EID <tt>ipn:1.1</tt>. This textual representation of <t>Consider the ipn EID <tt>ipn:1.1</tt>. This textual representation
an ipn EID identifies Service Number 1 on Node Number 1 allocated by the <xref of an ipn EID identifies Service Number 1 on Node Number 1 allocated
target="default-allocator">Default Allocator</xref> (0).</t> by the <xref target="default-allocator">Default Allocator (0)</xref>.
<t>The recommended five octet encoding of this EID using the two-element </t>
scheme-specific encoding would be as follows:</t> <t>The recommended five-octet encoding of this EID using the
<artwork><![CDATA[ two-element scheme-specific encoding would be as follows:</t>
<sourcecode type="cbor"><![CDATA[
82 # 2-Element Endpoint Encoding 82 # 2-Element Endpoint Encoding
02 # uri-code: 2 (IPN URI scheme) 02 # uri-code: 2 (IPN URI scheme)
82 # 2 Element ipn EID scheme-specific encoding 82 # 2 Element ipn EID scheme-specific encoding
01 # Node Number 01 # Node Number
01 # Service Number 01 # Service Number
]]></artwork> ]]></sourcecode>
<t>The six octet encoding of this EID using the three-element scheme-spe
cific encoding would be as follows:</t> <t>The six-octet encoding of this EID using the three-element
<artwork><![CDATA[ scheme-specific encoding would be as follows:</t>
<sourcecode type="cbor"><![CDATA[
82 # 2-Element Endpoint Encoding 82 # 2-Element Endpoint Encoding
02 # uri-code: 2 (IPN URI scheme) 02 # uri-code: 2 (IPN URI scheme)
83 # 3 Element ipn EID scheme-specific encoding 83 # 3 Element ipn EID scheme-specific encoding
00 # Default Allocator 00 # Default Allocator
01 # Node Number 01 # Node Number
01 # Service Number 01 # Service Number
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="using-a-non-default-allocator-1"> <section anchor="using-a-non-default-allocator-1">
<name>Using a non-default Allocator</name> <name>Using a Non-Default Allocator</name>
<t>Consider the ipn EID <tt>ipn:977000.1.1</tt>. This textual represent <t>Consider the ipn EID <tt>ipn:977000.1.1</tt>. This textual
ation of an ipn EID identifies Service Number 1 on Node Number 1 allocated by Al representation of an ipn EID identifies Service Number 1 on Node
locator 977000.</t> Number 1 allocated by Allocator 977000.</t>
<t>The recommended 10 octet encoding of this EID using the three-element
scheme-specific encoding would be as follows:</t> <t>The recommended 10-octet encoding of this EID using the
<artwork><![CDATA[ three-element scheme-specific encoding would be as follows:</t>
<sourcecode type="cbor"><![CDATA[
82 # 2-Element Endpoint Encoding 82 # 2-Element Endpoint Encoding
02 # uri-code: 2 (IPN URI scheme) 02 # uri-code: 2 (IPN URI scheme)
83 # 3 Element ipn EID scheme-specific encoding 83 # 3 Element ipn EID scheme-specific encoding
1A 000EE868 # Allocator Identifier 1A 000EE868 # Allocator Identifier
01 # Node Number 01 # Node Number
01 # Service Number 01 # Service Number
]]></artwork> ]]></sourcecode>
<t>The 13 octet encoding of this EID using the two-element scheme-specif
ic encoding would be as follows:</t> <t>The 13-octet encoding of this EID using the two-element
<artwork><![CDATA[ scheme-specific encoding would be as follows:</t>
<sourcecode type="cbor"><![CDATA[
82 # 2-Element Endpoint Encoding 82 # 2-Element Endpoint Encoding
02 # uri-code: 2 (IPN URI scheme) 02 # uri-code: 2 (IPN URI scheme)
82 # 2 Element ipn EID scheme-specific encoding 82 # 2 Element ipn EID scheme-specific encoding
1B 000EE86800000001 # Fully-qualified Node Number 1B 000EE86800000001 # Fully-Qualified Node Number
01 # Service Number 01 # Service Number
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="the-null-endpoint-1"> <section anchor="the-null-endpoint-1">
<name>The 'null' Endpoint</name> <name>The 'null' Endpoint</name>
<t>The 'null' EID of <tt>ipn:0.0</tt> can be encoded in the following wa <t>The 'null' EID of <tt>ipn:0.0</tt> can be encoded in the following
ys:</t> ways:</t>
<t>The recommended five octet encoding of the 'null' ipn EID using the t <t>The recommended five-octet encoding of the 'null' ipn EID using the
wo-element scheme-specific encoding would be as follows:</t> two-element scheme-specific encoding would be as follows:</t>
<artwork><![CDATA[
<sourcecode type="cbor"><![CDATA[
82 # 2-Element Endpoint Encoding 82 # 2-Element Endpoint Encoding
02 # uri-code: 2 (IPN URI scheme) 02 # uri-code: 2 (IPN URI scheme)
82 # 2 Element ipn EID scheme-specific encoding 82 # 2 Element ipn EID scheme-specific encoding
00 # Node Number 00 # Node Number
00 # Service Number 00 # Service Number
]]></artwork> ]]></sourcecode>
<t>The six octet encoding of the 'null' ipn EID using the three-element
scheme-specific encoding would be as follows:</t> <t>The six-octet encoding of the 'null' ipn EID using the
<artwork><![CDATA[ three-element scheme-specific encoding would be as follows:</t>
<sourcecode type="cbor"><![CDATA[
82 # 2-Element Endpoint Encoding 82 # 2-Element Endpoint Encoding
02 # uri-code: 2 (IPN URI scheme) 02 # uri-code: 2 (IPN URI scheme)
83 # 3 Element ipn EID scheme-specific encoding 83 # 3 Element ipn EID scheme-specific encoding
00 # Default Allocator 00 # Default Allocator
00 # Node Number 00 # Node Number
00 # Service Number 00 # Service Number
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>The following DTNWG participants contributed technical material, use ca <t>The following DTN Working Group participants contributed technical mate
ses, and critical technical review for this URI scheme update: Scott Burleigh of rial, use
the IPNGROUP, Keith Scott, Brian Sipos of the Johns Hopkins University Applied cases, and critical technical reviews for this URI scheme update:
Physics Laboratory, Jorge Amodio of LJCV Electronics, and Ran Atkinson.</t> <contact fullname="Scott Burleigh"/> of the IPNGROUP, <contact
<t>Additionally, the authors wish to thank members of the CCSDS SIS-DTN wo fullname="Keith Scott"/>, <contact fullname="Brian Sipos"/> of the Johns
rking group at large who provided useful review and commentary on this document Hopkins University Applied Physics Laboratory, <contact fullname="Jorge
and its implications for the future of networked space exploration.</t> Amodio"/> of LJCV Electronics, and <contact fullname="Ran
Atkinson"/>.</t>
<t>Additionally, the authors wish to thank members of the CCSDS SIS-DTN
Working Group at large who provided useful reviews and commentary on this
document and its implications for the future of networked space
exploration.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+V9a3MbybXYd/yKNpREpAuACJKrB22tTYrULh2tpCtS3nJU <!-- [rfced] Please review the following comments related to XML formatting:
G3MADMixBjPwzIAUVivX/SFJVX5Lfsr9JTnPfsyDBNdrJ7l3q2wRwEz36dOn
z/ucHg6HvSqp0vjA9N8vZ1EVmyo31VVskmVm3r87NeX0Kl7E/V40mRTxNTwG a.) In the html and pdf outputs, the text enclosed in <tt> is output in
PwxX9Gi/N4X/v8yL9YEpq1mvN8unWbSAsWZFNK+GSVzNh7MqG7pXhuP9Xrma fixed-width font. In the txt output, there are no changes to the font, and the
LJKyTPKsWi/h4dOT85e9bLWYxMVBDx866E3zrIyzclUemKpYxT2Yd68XFXEE quotation marks are removed. Please review carefully and let us know if the
858XUVYu86Lq927y4uNlka+W8PVxnEbrR8dJWayWFYxtzvM0hkcr8zqu8MEk output is acceptable or if any updates are needed.
u+z3PsZr+Ht20DNDc3z+Gv8B4PCfo7fXT/DfF0ffntDnVTZLY/O2yKt8mqe9
3nWcrQA0Y+43ozG8yv73/I35Bl/H7xdRksL3gKDfI6ZGeUGPR8X0Cr6+qqpl b.) Please review each <artwork> element and let us know if any should be marked
efDoET6FXyXX8Ugfe4RfPJoU+U0ZP4L3H+F7l0l1tZrAm0Uy/VhF6zQvHsHa as <sourcecode> (or another element) instead.
dvG3FLBaVt6o7pkRvzdKcnr6EW8d/1bbvNFVtUj7vR5/KgmJz8ZPxvjvk/H4
Mf77ePfxTi9aVVd5gb/D3MbMV2nKdPEOpjXnNDb9AmuJsuTHCNF3YA6jdF0k We have already updated several <artwork> elements to
kTmPp1dZnuaXSVzSYzGjqmCofh/xc6NpvmhOcTIzR0kB2xC3zPCHb98/Onz7 <sourcecode>. Please confirm these updates are correct and
yh/0ZHYTFbORvPP7v1ytomU6imerXi/LiwW8eA27nmRz96E3HA5NNCmrIppW whether the "type" attribute of any <sourcecode> element should be set and/or
vd75VVIaIP3VIoa9F+TQGSqX8TSZJ1Oa3eTzloNllnCqknxVpmszi+dJFs9M has been set correctly.
kpl3L18QKgf0yunh60NTxJcJTAk4MbCX0SRNyiv3MOJ/YKJsRi8UqxQeA5Dp
U5xN8xmSHv48i+UDg1PGCExpbq7izKxKGDAq4Tlzks2WeQLrOZ3BqmARcWG2 The current list of preferred values for "type" is available at
Tk6Pt3HC2tkwf4wLPM7midnCY7SNY9QWg3QyMuc0oaJoCoSdzNeMKjjn02pV <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>.
xATkJL6KACtFO84GMrjJ4hu7uBKfxecEr7gqRojFFqPGoTGLp3FZRsUaed4i If the current list does not contain an applicable type, feel free to
yqJL4H64mTzEiDd6kcxgsb3eA3OaVUU+AzBhrbjtjb28gXXnRXKZZFEa7ufn suggest additions for consideration. Note that it is also acceptable
z78CLOCOfvlCQPEXuGv4BaAcXiY4Esb3GqAjJmKyfBaX9A7+Zcq4uE4Abtgs to leave the "type" attribute not set.
3EXglNOkjNP1kBBBswFPhg2BpUSVmcJeTpDKclwr/DyPygr2Ese7gZNv5vEN
fCziMl8VU6JbeCMHTBXmOi4mOexX4kiAF1rSTvqrBhCTS1wr0hyQEY9NxPdp c.) Please review whether the note in Section 6.3 should be in the
GRcJHo0obRDOtRDOYyIcIODPn38HaPlq5yvA0zYBefr2tczAyGTyjKZFnq0X <aside> element. It is defined as "a container for content that is
lsRhSQvThw2Ki7cpnOMKd1XYcB83oIjncQEoIvmWVCWhKUN8IbQ4zCyOl8Ny semantically less important or tangential to the content that
GU1jRT3gd2TOEnoJjgefxXgOBzqBkdaA1wyAqojwGOkeqkqgqI+AzxpJ4nTA surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside).
rGjGKLO7DHQDaAI+AVtKqEuTRVIBdMsctmdgJoCKm2RWXRFJP4KXgfktVyCu -->
J6vZZVzRhsAa8yIeOIQg7oCcs/zGHW34lA0FfcB2DHJNoPQzmA+Oo0r/cNdo
a/iUwuzALpMfYbSuzRQuMBAax5OPm4nHdI7HrlwtUXzbvcMNaOeN+kSDj054 <!-- [rfced] Errata exist for both RFCs 7116 and 9171. Please review the
6hYmVRKXKreZQpcrOPjuNQTLXAEWgNxXacVHUxCfw5kFGlim+RqXXdrn+fwh errata for these RFCs and confirm that none are relevant to the content
KJMcaTou4G1gIPA4H8ps6H+Hq5lGJZ+RBOlsmq5wBB6sud054E23zI5ClAwP of this document:
0xRdbwLwcPLnQ+ABVUSHI86uE9hZXgAw0QTejkx5BaoT/DFbJBnyPhJjILFA
AGaMJ1BpbmBtMCACwroYTV1Oo5R2pw0ziMlJHONpRGoEOQuzTNYwYzjeqkTO RFC 7116: <https://www.rfc-editor.org/errata_search.php?rfc=7116>
2r7FN1fJ9IpGukour1L4H24LqnolndQFcK7rOBQRA7OAPeFNYxbPzJvkL03j RFC 9171: <https://www.rfc-editor.org/errata_search.php?rfc=9171>
8/CjNQscxNjnzx7TJS5sCXTAr/1cOT7AxUZwTqcfUZ8oh4SRKpmkyCDXA1wM
LgUYBGxlTIya1yablTt8CWqAS8HuEpzIsBiLMAxDszZI58wscDeAUymUIHvq -->
q0lEdKEkAUwD8lClhEc9waunLSqRlysyGyKVpXYiqLGSmsBEqgWFprKIarzN
bLy0bLTaQIDLVjzSd2tiHODNp0lUifQJd/8wBVV0dXkVyuXrOIVjRMSKgyHr <!-- [rfced] Please review the following questions and changes regarding the
N8z6YdsWqyyp1qEkq/G6QRsp47QrXRZMcwniAfRs3LJJzAw4UdEaHNQbZN2w terminology used in this document:
LyLLDcz/1xUuEVBZIgtWbEZWTpscqW0ZFVUyXSHfJt0gQc7211UCpx2Wflrh
F0BlwGzRKgE4CoCTzjbqBgMQMh9jOEtlJVC5xZStK9QNiBRETzMIwON9m+Wo a.) In the RFC series, "Fully Qualified Domain Name (FQDN)" typically appears
ZOWV8kASeFW+JNUeac9q1bAaYJHTIpngKb0CeYXA5ijfFqiiXcYlSybQaHSO as uppercase without a hyphen. Would you like to remove the hyphen from
EapkL/LsGkEAe5GmPEYIE/rMGhoYfAYtvtL0v3t/dt4f8L/m9Rv6+93Jv7w/ the expansion of "Fully-Qualified Node Number" for consistency with the series?
fXdyjH+ffXv46pX9oydPnH375v2rY/eXe/PFm+++O3l9zC/Dtyb4qtf/7vBP
fUZE/83b89M3rw9f9fmI+ycTWJ1QiD09JKl7ghCmmqMXb//3/xrvi0jdHY+f Additionally, after the first expansion of "FQNN", may we replace instances
AQfjD0/HT/bhww1pKDhbngHx3ajCsu5Fy2UMFIL8KU1BNi0TEOp4tIBeAdWZ of "Fully-Qualified Node Number" with the acronym (per guidance in
QfIDbP76A2LmhwPz28l0Od7/Wr7ABQdfKs6CLwlnzW8aLzMSW75qmcZiM/i+ "Web Portion of the Style Guide" at
hukQ3sM/BZ8V796Xv/1diqbDcPz0d1/3er2XwvQKNAdBHyysANEd8vSpvpyH <https://www.rfc-editor.org/styleguide/part2/#exp_abbrev>)?
Ph4sOtB0puYx6U0RHRWiUfittAfI8iIkV9htoNlpvKyAQE9A9K/1kA3gqIAg
q1A7h92jA5nQEQZlrGDl3WrVVfypWsEJqvOIAmUQsDkYVvnqwNAuTpC3ZSWc b.) We note some variances with the terms below in the example schemes. Should
2EI1wWq1TK1cnudpmt/g8auuipgY4TLPkD+Bwftr0hIO4QmQgTCJ07fkp9fI any of the occurrences in the example schemes be updated for consistency
fl6T3iDfnLGdol/2ugYAupyhZBWE4dfAfGFRS4QWxSepyiSTEDpvJtYQ4HWQ (hyphen or no hyphen)?
qowMYY6ksg3QwUKKEb7GDAuYF7LbJAWWF13nyYzXyyKZJzJoVqVWwLAcwIPD
IMBjPgQgdQFXH9oWVv6w9SDS74eeYbA9Ymx44+AuWz3NY6p2TiQvgEFIhdVR 2 Element vs. 2-Element vs.
Z7NN8yHNE89YLsgSEA0CoA8zwIW/DFnNs+CEG0YQZT4sAMIMMAJDr9CWnoA+ 3 Element
irqfg4KmvgTVMvNnDofFycWCrc8PBIeU66lYZdygRXO5itDFFsdi38Z0hKY5
qM5TFLpI46TRICJFevHew492NaW/zyJOjDmczRI2BFiBaoOpnYbV7+JvqWh7 One example (Appendix B.1):
ONUinoJVnZQLRGIdGlZBSH7DLKwPB6LdkjWzgpjWBgPFn2A7BMsvVwDz8K9w
ChCggEYB4/O/Zhmi+cEDPqwrR0rm84MMPg5XRfKFVAar1M/zFa0KkFyRggLT 82 # 2-Element Endpoint Encoding
X0cpSv2MNQFyKakq8BCHeWiHlZOJRGn6YIDiCH3AMdtE8hD8iXw1ZuT1fbhE 02 # uri-code: 2 (IPN URI scheme)
ciI0SPgNntS6DwN/3TxASH4DMJgqtXF5MT/GRW62dsBghJc9XOugpCQGGCO8 83 # 3 Element ipn EID scheme-specific encoding
i2qKGg3scaVEEr5Wrmgv/Q2s1EzH32dWWwEsgskDVAIMjzeqlaWAPpt5v9AZ 1A 000EE868 # Allocator Identifier
XQc+Tt6wG/QNEntkDhJyzYaPpm7KKOZJLkTTJAUYxQd1ieZqFokjRZxmkRja 01 # Node Number
jmmiNtjOL5EA2T9sIbZQ8pkXvoCrkzOE9FGQFt+0T6Ks/UgCetFtCtv6Lr4E 01 # Service Number
iyxF1g/Ps6YLYhZ0qxVKndoYA9k1cpVEiA12McBjZGdPQSFAxyTLZznCbI1b
ZXbghitJwQvJonVrD+xRGsC/gjpxKw3UMgTWB+jeQZTt/ve93eF4dItgVbFP b.) We note different capitalization and quotation marks for 'null' and
JmWexh4bUt0lYEFuEKIhOnpW/tTlVUbSgelmZAKqXERreBmM9sUqrRJUMeww Null in the instances below. Please let us know if/how may we update for
rSsfGNgIKzq6l0J67ST27T2iYMvK7ato95FzmBzn/YcA50NzZs3KdjD6jnoT consistency.
526cW/3wUlwnLAo6VlIiM95sPjsdMOgEztGwQ1kAuaQ2LDlTnCLTBYZvB5Kg
QMqc1l9VXQKAzhdx4LlEkgVJAyc6QZmKGmZxLcjwPIOqcs5X5D8AogLEnwAX Null ipn URI (term in IANA registry)
88DirS9DBoT+ooJ1L3bGohUCZiGazgAP7irYfqZIyo907oA1Vhy/EDDJeFS1 5.2. The Null Endpoint
GegUQFokVeUseg6AyKm5VfuBLZs6+e7p/YD4N3TIySOO0ciCtcWoIq4brAgU B.3. The 'null' Endpoint
ddm+mNEnUjFa5NllST82X2DUDEIWZo1mUkkBP9OccIWCFFEl05DFS+TPnMgx
HLT80RYv12UVL9x4QhFsZpITEZVr59drdb+g35tx+LZIrhGG92XACRCfS/5p 'null' ipn URI
CASwzSxq4GhGNuQDWOYR8AMHKLw44+8c5W87D85yVSzzEoWRNZCRa5FwbJeO 'null' ipn EID
5h1ODTLyDOnZF4qCKVo5unmtAywuiVvdUHAI9Ns4BVlRMct0iEbM1M0OUEOQ 'null' endpoint
9BcoyVkzTAqQHJNhMC9Kn8gRkbNihDzajy8eWTxF9eFYw54nRVmhezGWPxXR 'null' EID
UZnwjqEzCcHyHNsSqqAj4aDonJ5FYBZqFuTgtO7CGQWsylwPBDAGwW4+IYgK
ij3N4grOlzzEofNuvkVQe1OSt86x+1FN/fG2ngUjW1GxCms42StydXfMVpMj c.) Would you like either double (") or single (') quotes to appear around
JCdB4ntyxBA380zMDgvWSi+GQzwakzg04MR+AnQ0d7ZmXIBItbvkc2Z1HyHu ipn scheme? We note different usage across RFCs.
kUBvyibexZnMahWv8K4llDVJGsBGxk0ugSt0nyZziqVVNLJyuCbts2qyxCA5
auCsEhI8bDj4O8R4g0dU+bsFHgqqlEuSbsJdXqQwNGl4FDgZcmzDvAMpQnMF As used in this document:
GqONrYC9R36V0gS+No5B7j/e2/3yZQRPC/G6MZyaHAK2ZTXHzE2iBshbVmWB ipn URI scheme
xSWeXhXZMO8SzILkE588nhB9DhZC9A1Y8UNUKi/gmfEcO8wpm6QNb/mwNgV1
22EK1VayBpDjdJ4Cp6KqQSyhpNp5bFC0vEb++i6ASiE8My/yhXlxevzOQw+O As used in the IANA registry names:
cpN7zm44IEiB49EtrKahBYcyg+y7Ak1z9gEuyji9Rv3ETjvqHh/FCmwE0STx 'ipn' scheme
/r1dMxEGnMbZZXWFchoJaKa+Ff9UqXflNnRwAoALpMDwNxg+sHwfQQUiksfV
HCBHfZn8CGyK6YK4JsWZ8bddNv/YF+YzNfiNATevaSWsp8Egz8EWec3+kjSO Usage from RFC 6260:
UCAh48JAFKZC8arVydhNPgoeQrzDnD7+FC08D6XEiW9DCUI9B1u7tpNbhwNz the "ipn" scheme
NDAveGnHcgTF5Yn+zZ/MG/8g/8SqhNmaxdNt9+kq/rRt7MdXjIytI1gfPNT7
6WCI/xn5Tz4OD1o+0ceDn3hac2hfMc+e7D/df2pGI/zr2ZOv4KudTycnOzs7 Usage from RFC 7116:
+B39+eQlfPmEsSqvyThHwTjPnjzWcZ6NdZynbpynOM5+2zgvwnGe7dpx9nSc 'ipn' URI scheme
Z24cGnyM45jaOMe1cfbt27v4lz81vPP5wDyooskwSoqhbnyUAiU976fxvOob
SlN83u/W/ERkEos+4RH6X3q970W2l77ngLTudkvc3Fxh0guGxQJK3v2KIQYT d.) We note different formatting of "0" as seen below. For consistency with
HxinbsskTnO2YwJRcIiJI5RRga7Ee0/1tDHV086pjpwn6j5z7I15DuRwuqcd the rest of this document, should any of these instances be updated to
M7xAU8j/4pidAw27O3DFkROJMm4ix0FgyqFwkR1R5VFJaBgH5nPTOIC9PLSc "zero (0)" and should the <tt> tags be removed? (We note that "Default
pJbZ4QX2mRORsyBYhbMRO9xiN+LxcvqB9WDJE4fst6rWZgs9C9vqrW3zdJnr Allocator" has a value of "0" in the "'ipn' Scheme URI Allocator
JHLJe31MKw1+d+4GSRRZxFFWOtFvXf1k/WImUIFhdvFdRuKqvl2XBsBWC14w Identifiers" registry.)
OWR8D45vR3KmWA4nZu1U4bvhVgUvhlmW1vmI7it2tqEpQhJJ8ifi2aDmByis
mcUqBs1J8j2ySReBW4ZcbCmlH6kqvLolbZmdrLg7rHTS+LLNDZpjkp2sPQOp ... the least-significant N bits of the first Allocator Identifier MUST
0+GvXmPrYvhFfT66mAaIcBBPMzrqmGKkiQOZsbl/snpr9HteHBeE7zywqD+l be all 0.
sfPtkExmIrKBgICIXAaQv4vtoN/hk2uygHaq851z5B3BzJb0LoudfP1lN3AS
mED43EQZoDfhRCrKcWGVkNz/oVVRMs1udGqYysQ9UrLvTdItGcYwd5aIizJ7 ... a range of bit-length 0
orTudyn562G7PwuZ+Q3HEgJUfA78X8hUQ8+uHyOjqBR7g0F+lEEsI5MIWYax
6LoXHdTiRnwza/i18SmRIQFrUn5KuWQNIUNU6UXd/WgnGRAtg4nMn5DV7DnL All leading <tt>0</tt> characters MUST be omitted. A single '<tt>0</tt>'
XHD8Fg87J9J4OQeMEn8Wyw/w0Pl2P87oHziEGAPPiLj5ivIlLcf94IeZ0E8p is valid.
gbltkZS3BPlwWzHKB9v5JrMaczS7BlFP2TOew1fCUCaaYGBnze6mMgEWUQKz
4EPOVFBxIMcPRkrw1hE8kchqaUOX5EWRhzhSBofrJTmORanTlB7Yw2mckF8Z Consider the ipn URI identifying Service Number 2 on Node Number 1
B0OPmjeRsjI0pNR1GWlegHoEMfNBXStiPtnJ88x5dBwd8xuoIEg+mEIDUH4L allocated by the Default Allocator (0) (Section 3.2.2).
0MLXlEDnYUHTm3hlGfmtaUDL/aZoSACI9CJRZqFqBkc26XE+cX10G/IXbvg+
ylKlDHGnWwIZcHI+jytO8yZ0zWwwl7ZyC+H0zdbLf3n9etueg0ZaS0cc3Kd+ Consider the ipn EID ipn:1.1. This textual representation of an ipn
G5cl3tYqMN0jzClsnJjSZVoD9LX1sOxjVkkZXSSxEHgl6I6ktCZekA44Cbl0 EID identifies Service Number 1 on Node Number 1 allocated by the
+fShs0MPC1vpnBJN9Ot8cC5BCIFgbeamQBUTfaxgdN4Vod4emHh0ORqYi61n Default Allocator (0) (Section 3.2.2).
T56ANTEY7+xsX+hyaGlshxPcbWqmGaMNUuMxxFBad4GnYaHQJlTEd66ChZSM
hsam0qlLmHZFwW6X8A3VqJ6jorbCf0NW6+cb9dotCI08ea6DVo6NodGU03z8 e.) Because CBOR expands to Concise Binary Object Representation (CBOR), would
cO5dDLmhs2eWaNR5aafozBnxngkyFzggiqnl9HstNcedJXKFgt6QzOB0nKHr "CBOR representation" be redundant in the instances below?
0DJ5Td3jxK8FxlJmrHtILQjqM4CTsvmWuhPJ6aU8zEeF7MYrWFRKcNv3QQzh
UlPaPM4pad8dqwD5e8ISF9Dx6aX+t+1nPAe5RuRvwrnodAxAcrtAS85KsjUh 6. CBOR representation of ipn URIs with BPv7 . . . . . . . . 15
PPe3qAm/0Pb50KPzjBdAvLMU7SQURwyx1C8wWyNQ0LDxhLSXGhOZfgPRfdmB 7.2. CBOR Representation Interoperability . . . . . . . . . . 19
rqAcbIMXlOvcBC9FyVroYaCLUFPEYQi4703bH9QUVk1K3QVTnNx4fzdeu+fm CBOR representation (2 instances in the running text)
4pbKJYWp/1skwSRe51wBwSpiRwUEpi+0/kRrI4GIhtbANz3kVEiwiWtEWLBc
kVVrA8CBTcKCwupO4WLYBW6kSI4flfKthoN/vsqmNkJWutodO6LENoDLR1MY f.) FYI - We have added expansions for abbreviations upon first use
+/Tt9b7zWzf3DCMe42fjp7RnR/E0skU5sOY0mlIc3uUPsEurZi2ysNVqIPZO per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
W8agqdtEbnIWJuz8Vl936xYISyL3RblKKgpa20QWEsbLNOJsJCylRK7oYMi4 expansion in the document carefully to ensure correctness.
cAIhIT4XIrwe050WeVlacJxG2Q6YSNEwvREOXi29kQys1tzKujUk3vgOFcjy
EVc4lIlmgBRsf1fthGR3IgamJtwr2eh2kFpd2hSMZvZbI+0T7APW1onZ6nhl Concise Binary Object Representation (CBOR)
CFagd1Pi87nkK79r1DQohbDlVq+W851STKV7z56Sk0+jMy6hzuZCS/KdVGXU TCP Convergence Layer version 4 (TCPCLv4)
XJKR/DC0wgGRzMeu+Q5g8MBcAFQXrri27f1SuKSDgB2kMR6YqUY2qRzES2Yt
Y3g3DEA/vBhdPDRA3hg2RQsZtpadXn62oJ8aR3a+6FzKaUXrQqybszVg+xNo
L2inD0v6tM2rEe4imWuppM/aFPGDXu9vf/tbDwY9+PDbNk/V16MffuupaV+P
fhsS/9f0Plo2H7HCRhPX61nrUvfCjluXh845PNESCOBAI3kYYSID7GLnwmHJ
C26xi9dzLDyEJx9K7moy45Dg6S2pvPCkCigv/eWiff0XhEbes+8O/+RDcL+J
2hKI4QHWJ0DwjOIRo0d0g8h8aCgFsMWB7uXDb1EFwP4KgHUZClKXVFaAWLXt
ZmAaA3le7O8+23/2+Mnus6+Q/DULjbILkGKY6AmvrooLI8tqKclwXcUKnktC
KJFzjoGFfThcLtHU/mQOlXLV/pJE5m5SBx7skbooP0R3/E3NAhWVN3R+Oyo8
PHr9UpSar3b3sNKGR1E/XlIh45PqhSnyIXpDpkIaJr3l+PSb0/PQdEJlwS8s
5ONmokk271HThSIxz6nm5KCP0A4xbWmI3KbXCz7CU+j7Mf1R34QHsNejH2CU
X/XNI+NomEcJP8NjH9qoHMf9wXjn3H/Re+y50Z+9Z71vQ9D8x/WL/g5CqWbP
0A0XfAEPbv3nT3vj4d4z82vC63avx/h9buCHHfiBGM/nA8PyDJ3jwyCY6H2P
7Tme9xHrGC18AKqBVKta4rQ1lr3eS1Xd4qhIQUZXZhatidDreZGWlOpl0pyg
5TznNtEvSMYVQcwdG1x+OelYbD2IyDp9d/6SKrTDmu2wZNXLsldVQOsIi67x
JZGlr0XW/ZqHxP/N42t9bhMxYpioRjXi4lKqbSLBSI4Vtns8ocbnqc4iuMo1
QhZRFAlbAVhh67ncLQZqi2bfFbaX4Xrl4OcRfxd5NR9Ouc+ClhsYbUlTrVKo
76fPhICU/FAFe0Q9ja6iWKxXZsnm6gLLnkPnm6CBli873Sw3RZcp6bXuazVt
NQoQTH7fcl1mUipbmSeissK9QthLkpQ+UA3YqXiRypMPHct1zQhoDwAcJRbf
7s243g6+ZXPXvHf5yy+ozAfru7gmQh5kWO1BUsOvyjFExqTKFQhC4uIKsR5d
zYfxUubVtOdqI6V3P7c+9OW6jNcNanJUQmrsQpWWDvBQxQgz62XdzWTGBBb6
LezWNem9olnTk76Vij4SnpGcjWFkxWrx7dCMuHhSxPKAtOQDcTCO8X8Xze92
RY2uf793IbFGTFfS+a1nls8TKaVqObbjx9sEQgItKnSujmAbbIAEziKhZJqv
UlSkazNRbQ3ZOZ0Y8CuqlBn2ep8/n8nx2xvt4ly2y4Dxa9inXAiqRCAVVEpj
A2UfJUd4hfJsbQZWi8bilcVmLvpwjUurM1eHhwWPOClGIl714h8PFDmQNcPq
ds+oaWQziNoK+uSsyg5AmMcXZsuhaH+0O/pqNB6NA0RtC/HsjHZ8moGP8EVI
JyRkkY/UEMjbQ7/Q0Ts99neGp63tjtcmobZBkenLIH23BfaEsHTT1kmAtUhL
59pDG530pO4yHAN1YvJ8Mat082tNyt2nAAMZoMhvVB4I+0bMb2B9oQiErQ4u
FvjdweHoaPRCsxuVj+MTZ6xPCJCsY68VRM1hEerZCHAbArnYOhwcwcml7Qyt
Hjy9QMxXpEdtYBHZuu1W4TOQeusux6tIInWPRU1gOO0ISQPp3/OGNNy+jGUS
3lZuhY6+h6j2Yg8EdHk9bEkScuhlWdwGT+RRm9P45Atf8fPDBZHIeThbYG5L
9xXnaocjfoKkRJltcBA1AZ1inxLR5RlKM4d957oZB5vIq/sANkGbtAQNcMZ7
p0GPXq9JD8FSVBVJfG5Oxo6v6Vqxj60FJUksn8+V+P2lByKvDeP+7B6p1ZRG
4EIrSiRjpxawn120LPVbwQgH/xRIDzir+7bQ1UTIU4pPZSgE7YbEHCkQJDyY
QqkwY5bfoEIVR4sgNnE3fldeHzrqZ+UfZFHEZwkWZ+eY++JqK49fnwVFdVRV
GbjPdJtm6yxaoJ8thr1DMsAS1PVAGQ+uTOQhuyJ0YXNbpknu+TAN4e7Ni2Yw
TZV4LI4AUAY3Y7IuY+pkCUbcZY6p21IoY7d1nzzqtVCNY11Hck6Y4iXG4dQ0
YjNOb5YAykaapdL0jZP0LeEGJfFNy7MkHx7FGlaa0KHXqlXxYYk3lmp5kBvy
pnhgwAYu7cRA8N0+9hZlooXrtWD27+Z7HArocPwb8kSG0Q+bRCmaJNfV6fHH
orIbkpl3hzowrcVvI4R5IMnlisv1qJqzXBU2Hy+hdB6p8JQAL/vic3WLygvS
I8GNJ3UgbYT5d/DQgJKjTMqt29bLdiRxsUaASWM5pQXbVjU0eHDb/v+juPDA
AS3rbiz5rsARs4PvY1CYP2YYdamFkDTfbEqtjaiyY85KyhNnEokKeu3V3ofO
D+7viFkjs3yp7pBJXcfCeF08jC4LdEHJcW+2TMhVlaW0XhD3RRRSEdkoy2VK
Gb7E4i2g4tjFbr7JhKv5NCV5EjejRjddaGlteKWlrs3kL9uAJ5NFaCdB/3f/
RX2O0HyTYKOkHBCVrejMMZwxJ2ZQRC1cv+jDftE1dn9k+8rlHtRieOh1uist
tptOLFXcr3DdwzCttTZqV/LOBnA0MngajV6EnVtw4WBTay7KRvSyaQHMtkk8
0JW+JKaXlnlLwXrplwVR1KLupOV0GGYfXL6OtcXhqVWzHmO74YEeqqVZSpDB
xmBrh6xOynOXA+HST/3mXxw1aofD9xk1A/ldjgdY2uv2dKKyySwbnSG6IYl8
fdFrC8FuhgfmxdGbd7cFfjzfesMlENrmNlpt9QDP79h0nBJFOlkmHYOptVxH
DFcRG/pYNbWeAKXVSIbLs/1nWB96jpp0LKJYYNS2YZ4fVitMeWtpnPa2zMBH
ixxLMykhTeQxOy2bcWCBuA3JOLcru2iLDtNbpUaHp5O8GCpIXowNpSk9eSK/
9XrfSGNDHEvB5W4zdknOL0m9ELDRYLoWpu9VLIqpAmtYg3QkzdJPPoM34a+U
8vFcn8rW/pteo17pF9HZcRuDCQtQ1q99l4RtAKZNGGs2DAUnomUy87wW0hA4
cw217bK19VgpbsYldVzALjroNoVlRRynQRvaa0Ia4u3WdAKvXkSKlIMg58CT
fjxaZ7LBLOZmw8Vv8PziXgvtUnoOPA9sLeForo4nUr3mGMQOB0URrYNmxKQv
Neki7K5J7YJvO5f1eO2kBTtEpQQAxeMSTge8AT67u83yH3tIbe1tm5gV91Lq
++WjzZqnIXQaPf9+wRvN1ChmEBkQNDL3MpU0GH6TD3VCtpgAKvuNa4bKmbZa
li5JHlx/EkbXnQ4TvmwTRIJw+pE96kE4/YE5B7hOBApmEENtKGuPPkbWEXxC
yRebGe0vqb6B/ulwokFSPagauBX76vQOetVvZvjaNB3gqIiujuGVMSB/CwWi
bCT5Hi0EtjzZPN4fYrFrI3sr6DyX1bIIwPjjHBYcmaqkTVCMKcXhEoBRGVbP
CGnrWOGErYxO/Vw3HLw9A/PWWfxSDh+HgN9mBIjrRCVLH58IE905ZnGjNrN3
1C6wJPXp46d/3qH/Hu9fSBCUO3dT6NE/SLSrFx/qbw3Mzqed8Q8XzTmE06mu
5XZqDGoH7GFlma1kQT3dNR3/PTC79uRY1chKS3hgp/3VBwbMzCGCc2B2zRY2
a3dSahtf7JgTJjQ6oaK/69z1+JXxkQGEEHIUN+bWgiJ5b2fcNn2ttycneW3K
CGzSMWnljX7ZXJPkrg+ovVZTczV4VFN2zff2OguvY0pTXtsYAxwLzCINqgXI
ZRaUynBvvcjTrOR6C77d4nt1DdQr3+rFkRt6226BV5mczN14KITbtaCbksXJ
pRQodzbh+Cyg6jw/EFu/HNfv4kqDTXl6owMkQ5sUt7/WEAGBk+luRscMhrmT
sv8QR1YzufjgmOCAmFM7G+xkUc825VD35UwbcKS92gt79+ZEh5YTmfY+XvIg
cChvnttZ0y0saTM6lV5K7MCjpl7OSmm3XkmLldRyzJ31e7CFPQEp1abmLMYT
GRSUUn8l5lQWKI3IW8ebdXCAup5csuOMzETX0o3ZZ1KWK3SOfEC7T809n8Gi
Fuh/Ri3w+0BTd8fWpvpsHiYQ9t22mM1YQKM366mf1u4AQnsbnsVhPmyiwWIy
qdVgt9nR5w6tbL2agC1mdT3KkbSXBte3m/c2qjxDiDNuW+zs41jtbKRfnpxN
Ps/N2UHHpd9zX1IZpEetbutiklyuYMdHQd4UzUwPSd82dM2JPttOCo4dUUbh
yO4QGy1LxhZbpcXCXACIf46T2YVXHBV6QqR9AckJy7fpVfi67VUGd+bpppSt
Pjcy1QjIYmvbPH9u9nqfgWnIMCNLp3/2klcPnutrH3Z++I33NPq1/iyJp95D
4+Ahcfy1PLcLz33pxSl6FFog270nZObrr0Gf3wA+ePS/gOFL+ePbm4E6JlDv
mzi7LOPVLMcv+uZLW2a252YCbSJwM1FtDDnqbHpTI8fUtvl0jgSRjXJKj7jd
/ZvJXzBMVCsw2cLZt9nFwh67wV0J3zrucVRF3n0S5lWUXa4wNXjrxfHxq211
Az4e45VebYnc09ks7QFizXPzn/CfkcRA4e+h9RL0esFHzMGGzXJieIWZYPDN
2dnbAzzJvR96vd+Y0Wikye4uyq0vaSOJ8AY2UhPhvV6PgHlUn2jXzoK55WW5
3DWP9M89mNV+yy+irS3QGfMbswQ9HqaimeHX0PPPz7kx9mSMtixyftaMgCHb
6oPHCJqXU975TMe09yVp3DjMBX+dV4AY5MIX3uwXXv0tyQ9NA5X6nqa6oKlk
YAJs2EveNyBswHG34SVSj6ZNJrcdUl0gFFtIkTQJ22DrDRN1/436ye5WmSSV
amCnWshU1lcCCgm6rF3apnJsyiv07n7hm45G5rjFlaWNFzDNLojuItolrQyW
7ykChDCZG8GBNxz4tmLt/ip+i9MTJ05a8ehbQBc7n57ujo/qBvgOjClBunYn
oL67Nz7Ud8dP6T20NZPUXo7DPiiKWVP8nyBiljucRGgFwyZOP3JXQkKauKWV
UyjetVkZokxeRC2xSMpc0xNaXrf7MzSRly2qmoJitYlSihBpH4IX4viPvNt7
ap57r16Z4JqyCzW4z8o1Oa9X9NuYNKXreJcrir9a2sd6nrNoka9YQV1Voli3
5cy6mI0LnNkqA5uEbXVCVGHKK7L2KgwSw+blNuyhTfx9icSNXUWVzPVOtY5A
yMALklPXJwy3Yr0E3chQsxM4VbwtkQXzAriv1pWLJE01ZwQLX1usCpTv/ucv
bhc1TifNujSDlriWO0+N25GWNpRrPUWmxVPkV+/LTJc5og7fUn2RqKfUi/7q
MTQPyEQbfnj1NLhOuYRHski+BfUdjpnzlHx2N3yGuRgw3u7OeNyewhk0QkHf
EudLBd3eas3u/LZnfG8REi6/5zo0eP0HyXTbxDlXM4/Id1XmHbfaNVx0flw3
dNd5njnMcLYttOR7GjZN8MjVaspJwC6tIePu4HB2lNGXp7Fnd9YplujQu78V
geXEGErtzIazRneEoJseVQ5vKBmtDSY5IN6NJ+ExkFImH60jc6LIqZ9LSoEg
V5HeoFmjBTa+KAHFdvOhX2xbYEkhkxDmhuvebNUYhWw3hknBb1jEy8simgXQ
sEzBXBjOGuaQsl6yalNe8UpK5V+uCLrjVg1rSdrNsfe3YkjTf79bDjPDIzum
Zl6c1hhqr/cCPTuLVUnlXMjeJc2N8wHbtpVwpLtAfiAVnB1aQZK5y0DZ2yCd
/VpHphxMJZi6luKHnu1qzZELy7ujWh9cXCdkdGm2t81ZvQV6DL5HKeuFA5vd
JydBuEgJTI2d1TZ/VKegaedRkko8iHz86g7LM3d/ALnAEO1gWlqpmUVBBkFd
HNr8LXsvpF6OMOJLyTE9kaPfgnO6G+2wlg0mCXdy/xGF/6hCodFfkejE4qtN
e9TLx6zHkZVbVzgxqScQU9MZ7tusRvWB5F1ZD7NtpMFwzXhj8OhhwCKEkcZT
dYnqXNsJAi8QNGewgCnlCElWECwkWpagi1TayKyIJ+uQYPDEcFYXNZ6ltmyV
dJhrPyycKRIQdQexYaLsKstiKt+MOKsX089Ik5I8Klmb3xLjljFDZJJe+KPt
mOWl62IFh6b9kpb5kHgdmyU8PgEWokhzgXykUSpn+9b9JZdbuDK3L3Y9uHGg
AGBsWr5DOejI2MelnKBYFSWYYRHQ+LfxqsAJpnSjAxpWNfOWz7HFvDi0pXMd
Nu3Tr23G2GRN1ldiO63CfPnCETVgmiUKAriEnUtEfCkEcacV6xupzUPtsr8J
PO6OZY+ATexVwEvbXJbKW5ZB3ptf0lACla7IAAKydIUYfo2mbQqJwzUbMt3G
CwbBamun1Lazu82axKTZis7pOdaSyNd6FkmQcOkTtaAnoj0IRISXgucVcSUL
9L9NYA0fKZNxseCaJUlXQU6UeDET0a7D94QM9fgVMTbSo0VLASY+pZdpK70s
o3WaRzMZAm1bKwl1MvJ0aFvKyls1pyuCHpJFIHiat/8pjfK8kt9LlSe8f0HG
uBYaaOK4vOUqDpx9zj/h3ZQfZRkLhzEpKMUsrpqiEZhZrqPFHV015Oy0qJna
USe4/lqDGtN76zBkquRpohdUWDpGGIvbgaRrxr0r4e9WSr1DXest6icGPHYp
AfvOJFO+xzFfrt05RUsQu0qLVBanSn80GvEltnLBOr30/vzl8Kn1Q2eu3JG1
TGqaGnYaPTs5O/vz6evTc9tqtE/xLGIcdFW8egg9/4eIRmx+o9zHM/n37Omu
ZZKitRa81NZvh6X+nYjmLkP0npTS1son/gibgeM9bpJn0nGTuqwhSAPk7L8r
9pO0uVfQKg6u73YZ7jaF8NrCIiiqA7uFVZ42Bd0CZ201saGowoVHsG2f8aaL
Ih6yv5KIPUzrw5FZHdWkR6euIWx3U3QjA1vTIh+7WFjrFsklMLX2R9JCHW/b
bj+AIxKt4oSaUElXPLPW2mOtp/Pqn8PyTVFKkjT12AZ7BrWklUo8tXxVancR
wUdJxtFNX7CAuu9oxJu1n9JlKPxKX7JJKEKomiRFjqXXnSZEdvQzIbZR5qnt
OEzXsThcXuXL4WQ9hH+oxLRieUF3JLANq1qU0BDocvSwgFdLyiVVx95Pw4nM
tvJ/HumdWDbZdwkqIxA3Xjkp6JXtoaToqCjWtuceJgEYvoqP//Z96YS9wupU
Wl/nuhBiQ0W6aZRtHsnQcWE37jWbzdRf6qo2Fvm1VtXEmm6P8LoGtYRSOxWe
kctYL4Lq3lblM9TkUV2A9fRuiezrfZ1BNrCcHHZ0slueMMbWssMNYJjtMaxs
FigHATq8uz1l8+DxR4XcIyW4bdxOg4or67+2v4pV2PmyCdtBv3nNZesNiUAt
rjM20M3HYRqtHVByGau6dLFuxNQTz7o6LnM1LpVioYHQGBs7ZOg95Dimc6gH
TYapgkqLjMILtvyV8B304qY0f0GlItNf9J5H14NHa3c5MKDqVDMy4BVW+NLF
KmA1WUpYvCtpkHZqOiWPv66L9Mkyue2ejfaIwI3NP7QJ7swD38VpokePWvAh
pGUFEnxNFTpWxAdh8bbu1JZzNLqf2puEjfiYq2Th6nOD3u5i7qk3gX6gXP+w
MA+7Fnmw4EUJKKu9mYUV16WuRvZAVXD+cA3p0bUcKz9VXUchhf7UKs38uUJb
1kaVmKk/LENDIiiIgtE2qvgcBGZi/QZK3rfvImS1+ap0ed6wlF6v/XuWO+gK
QN4jyXHSuo+LLWaqoC3sACU7T24htkHtaDUvuC79Nh5u7JaL0anDiDIpLZ9i
3uAV9ebN3jO2WdUsWoAyazcN23Nd4zWE0itJhqB7VVLqEIGOIQpHoAk/TblP
7jzC3Ji2hgc202qCDbjIkrZ81qPZqAouqpAWFL6NSrlJVP/H2vYWN7+axdK2
IE2dMavDSvJty7iurpzl8zWSNvdZwXutKctWTzf5LsnsYxUpOFaJLamm3GT1
I3hq8tFboNcaqeKw5y/evnh1vc+85fzVmTXkbLeBo2j6EcsTfZuXxbCSHygP
JN6u7YXAZI01o2HxfM4+PSAiqhTKLL9lp4zVI9DvgC4lrpmNiyJn/jhpAcbr
5kJL6miPgJvm+ro0+7ngq/7VtPXbaL14FFc9RHyrsLa3qjw1yJbs+8oeVvuf
umqi9dJvDWgvMJKuAVjlFV3y/X3UeZrUUS52T7wLMtaucabXo9NyoPZ7mlEh
x+u5SFNNZ6UydGwejuqkpCdEEzrMVHfqeAvTsWuR7PvsNCXCSx9XHyKpCDcw
HXLBM6whbPYDCTYFM3ziZFY2d8Z/3tsi7405qabqrLN37mAttXonAbmYOCmr
lpbptGLtxowKO10x6dQ+17HH+Rz09keKjgR1o34qj0hKKX6z3eeZNejt1NiR
JM1LiSuUbRDokSBlDZVgJwXL2Lpq0BMKOzaiy+s8A8Y1Sa2za+sBLyKMagHO
o3QN6sRv5Gao+vdy1WMKyCAn0Az182JgXYDOIKTmA2umI9Kq5CuQwKACi8Ko
fbZDVzIwFl9dMGQuKnNTztVgWGcS8gF2XgG7kPyPUs2dtX/qhDFJTiGhLfmx
nSUtkrLZ5TCiUeiEXK0WESlqBamcVIQfqpvmMxWzSyqDS8oQ/RO1jSpKUqLc
GO9Ign3ha8xEhwyqUW9y/46pJC6dWka2lKuZsP5877o1Gld0FZiLicCmVMSc
H0vZwsLfuIw/TGvov88SOjrvtNu350/YAsxsS26H38mSxvP8Jl3AgCovDKS5
SLC+qAwmjCu6p9hIvjeMttu7hyggqHteyCbb3H4h25eO1XJbMwkb2JGIZ2C8
qdnNoRWGvi1t8zo1LHOg+7VTRt31YRIfjrH/clD6b69dQH2WLjXlazHhX3/k
tzyyvbD0wF5OSjd37oxGfP0GvHeCGTDoi75O4psBVlh3XfdYMielAT6NMb8N
h9mTSzzqQ8lz+5wJR48+qT2qeTcoOfjpp97TL93T78RxMDAv+d4keB3dNrBS
fO/r59RE23vQu2sUZU/rhg8B3a23jzZ2lNVu3JFb6cvbVKB0TC7lyuOML5oL
99hVYJbBPfP3vbl7ZLw2j46A8FPjQm1nXrr8g/7raBH36ez232rDhxfoC58C
RuBh0EI06wOTpabWiUjX13tjhhdxSs8wvZtAGAGyPVso512YVZqhcHbi5Hju
bK9LfNeV2/bfKf8T6FSd8TgD5vS6CMC//ev/uJOo/+1f/6dJNfcbc6lbDlPj
mGrwX8INA7//lf404/YkvCHhPSFhqX/7VfZ1X2PXXenAH69AIlJXfNPKxrJc
8/xCWrmdE9mkKgqeaC5ore0MabrEi5CWbr1YueNeZWM3Ff6uU6HyMPiP/zq4
9R8AY9MKJrygGLnOjvwVRg1+IkT2ftJ7hi2n9S9wfvpsf695gTNzrbHUZHcM
fDeDAnSXm3GoLreVv219UW/6wXr6wVX1Gm5JsuAqNAXdpS+UPMRUO+Q+MN+s
khnl51EnfLmPFfPASSiArne8sipLmKIThreoRVhYdi/9PHHgW9gjh5hu5Z+g
1knVmVTGoI2gYb6wIpBuBwQVTZMr1PMi+Z3Rx7j0huu4Hz7n/g6J9HXzxrul
jPDuGK27u/a2e9JrbeTcBUnYxItSn/VmJfLvzTSTxJQ3EYmPublKLq/StbcE
22ukEgVvGWfsxhB/uo5NmBJ9EqyEQQtFcMOSqgBzl7uK5gugsRmzqzmoyWkS
FZh3g/HzMk6v49Llo25AM1Zf4iY+7QrjhvfVqeZYu1W1ldNKvISE1S13xHa2
dLI9kfiqaz0zP/82XWHiv6jqGSadbqiIihbKup6vralA6ew4Ta+MVd1EIeE5
HZyi6amNJx36aItWSdM3GwuXTU9UqGyecoPamq7pk8jmKuZmdNjUMA/LdnFP
mrpHid7NxNTNNzTMwnRP18Dw7+oQp2emeVfWL2Nn3atr3v9F8yuketNK9x3N
14ACu7rR2SMx3n3Sch7Gu09Ho92vvoKfzioMvGNRxSHzGD4IO2NnlLUeqKfe
gcJhgnKHd+rDq1mD3vGqj9hipeH65Sbc2LPo/ONUo57NT9Q9SLV5rO6j9P6R
NICfUMJpTXSo0fpUMOR/lAOe/+zND/O6agpmjzXSE6uQnrDNHeqx9ZduQ/vm
qugmeP9/SzEN+1WShVRZRYTbV0rOSVvv1HrbyoGfcp7GriItuo6SlCO2GVmt
K5d0imyukHgw6kF4qSHwoSsiILoIgXU6LjgpPgpG/CPmrlCM2Otv83G5sgiT
ASwEYe2StCDDZ7F3IrojaA1z6pZjdS7NFcEogd+ilvQ4LRUhK9Vr4erS6w01
3hvavqiNW7+dGxIYC9UChQdjsipAyeX+rLVcUgpgtrlZAFg8dBidQt9vrWy9
LQvTXmz2ObyS7EstJ8HWKZKDQxNFXFomWdlJ0ZHCKZfdWDdMQ/73euqiDlIP
/FrHWsfRXYw3BtdG/+ymRNSPQ7VGp5eXlOfrrplrq4KWq4JsakxUij/dv2lw
PNp13VsyTPLeZFB2sLiMqK6EucEds++M7Px2DzoyJe+/C3t37IID2N7TjUgY
7/8SeNXC29GeXR4O7mvVPF23ol27CiYKEbdjxz1s3gx9f2Q9ad7x/I8ku1+N
nnhkJ/G/8eNfYmh3i6LO0eQ2QYdVn88EvRo34zOB/WtDyNRG9mdwFlu5PcaC
bVYMulPPvVYx3oU3ta0d/8O50RxlAjfJCjujAfBhG5uNWtZ176/tubVhq61N
e/79jBZ/O+OuNlnd3bHK5NOGaNqs8vWfiqi9n9mBbGcH3mqS/s/D4s+QEo1e
CHSw/iknq0PC+EdnvPPPpoh/H+3qwnZ0P7dd3Xjvn8u2Gv/9f9nMlE7nL9nM
VJQjvQbPXuznf+n1iaE76ST/yutQVV3VWgAj+jcWVXamZu+1f0dCa6f9sOz8
DKF1G8L+w4ive+ITNNHDKfom0nh2SfUVvc8H7NiJZ8/7lJzbb+Q+HZ+//v4b
seSTZcTX9ICNnYD5ja4RqjGmZjwgeIokSgfk0KDsW7l5Hss78Qn3bMGueOty
bbTLOABlOa8qc7Qq0ji5vNJdB+R+8+7N+7cD818xTZOfGpgjmDgzZ8kyt1mt
f8ivstJ8my8/YsuU93yHFWaKHfLlNebt1bpMpqV5FYHaHfGVZX/IMfB1uIA9
yKkS6g8v/oh7NsXwFDzMC3qHxREVjksGfFhMSgH+VXWVU7ixvGLXTpR9tDd4
arjzxdnxmTk7PRsCig2mYCK6L4t8tcS4Gsfgbq5ylzEPeJ2vLPK4omBBbq9i
zRaU78ijxGfM4Ke0Oq+vCLGqlUZeJf0T7atlNCUHbJrrhVH/BwIcdC4zwAAA
--> -->
<!-- [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. -->
</rfc> </rfc>
 End of changes. 197 change blocks. 
1428 lines changed or deleted 1604 lines changed or added

This html diff was produced by rfcdiff 1.48.