<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="utf-8"?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.17 (Ruby 3.2.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-dtn-ipn-update-14" number="9758" category="std" consensus="true" submissionType="IETF" updates="[9171, updates="6260, 7116, 6260]" 9171" obsoletes="" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.21.0 --> version="3" xml:lang="en">

  <front>
    <title abbrev="ipn-update">Update abbrev="ipn Update">Updates to the ipn 'ipn' URI scheme</title> Scheme</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-dtn-ipn-update-14"/> name="RFC" value="9758"/>
    <author fullname="Rick Taylor">
      <organization>Aalyria Technologies</organization>
      <address>
        <email>rtaylor@aalyria.com</email>
      </address>
    </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">
      <organization>JHU/APL</organization>
      <address>
        <email>Edward.Birrane@jhuapl.edu</email>
      </address>
    </author>
    <date year="2024" month="September" day="27"/>
    <area>Transport</area>
    <workgroup>Delay/Disruption Tolerant Networking</workgroup> year="2025" month="March"/>
    <area>INT</area>
    <workgroup>dtn</workgroup>
    <keyword>DTN</keyword>
    <keyword>ipn</keyword>
    <keyword>BPv7</keyword>
    <keyword>CBHE</keyword>
    <keyword>Bundle Protocol</keyword>
    <abstract>
      <?line 46?>
      <t>This document updates the specification of the ipn 'ipn' URI scheme
      previously defined in RFC 6260, 6260 and the IANA registries established in RFC 7116, and
      7116. It also updates the rules for the encoding and decoding of these URIs when
      used as an Endpoint Identifier (EID) in the Bundle Protocol Version version 7 (BPv7)
      as defined in RFC 9171. These updates clarify the structure and behavior
      of the ipn 'ipn' URI scheme, define new encodings of ipn 'ipn' scheme URIs, and
      establish the registries necessary to manage this scheme.</t>
    </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 target="mailto:dtn@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/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>
  <middle>
    <?line 50?>

<section anchor="introduction">
      <name>Introduction</name>

      <t>The ipn 'ipn' URI scheme was originally defined in <xref target="RFC6260"/>
      and <xref target="RFC7116"/> as a way to identify network nodes and node
      services using concisely-encoded concisely encoded integers that can be processed faster
      and with fewer resources than other verbose identifier schemes. The
      scheme was designed for use with the experimental Bundle Protocol
      version 6 (BPv6, (BPv6) <xref target="RFC5050"/>) target="RFC5050"/>, and IPN "IPN" was defined as an
      acronym for the term "InterPlanetary Network" in reference to its
      intended use for deep-space networking. Since then, the efficiency benefit
      benefits of integer identifiers makes ipn make 'ipn' scheme URIs useful for any networks
      network operating with limited power, bandwidth, and/or compute
      budget. Therefore, the term IPN "IPN" is now used as a non-acronymous
      name.</t>

      <t>Similar to the experimental BPv6, the standardized Bundle Protocol
      version 7 (BPv7, (BPv7) <xref target="RFC9171"/>) target="RFC9171"/> codifies support for the use
      of the ipn 'ipn' URI scheme for the specification of bundle Endpoint
      Identifiers (EIDs). The publication of BPv7 has resulted in operational
      deployments of BPv7 nodes for both terrestrial and non-terrestrial use
      cases. This includes BPv7 networks operating over the terrestrial
      Internet and BPv7 networks operating in self-contained environments
      behind a shared administrative domain. The growth in the number and
      scale of deployments of BPv7 has been accompanied by a growth in the
      usage of the ipn 'ipn' URI scheme scheme, which has highlighted areas to improve the
      structure, moderation, and management of this scheme.</t>

      <t>By updating <xref target="RFC7116"/> and <xref target="RFC9171"/>,
      this document updates the specification of the ipn 'ipn' URI scheme, 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 introduces document:</t>
      <ul>
	<li>introduces a hierarchical structure for the assignment of ipn 'ipn' scheme URIs, clarifies URIs,</li>
	<li>clarifies the behavior and interpretation of ipn 'ipn' scheme URIs, defines URIs,</li>
	<li>defines efficient encodings of ipn 'ipn' scheme URIs, and updates/defines and</li>
	<li>updates/defines the registries associated for with this scheme.</t> scheme.</li>
      </ul>

      <t>Although originally developed by the deep space deep-space community for use
      with the Bundle Protocol, the ipn '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
      '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 anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The
        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.</t>
      <?line -18?> here.
        </t>

      <t>For the remainder of this document, the term "ipn URI" is used to refer to a URI that uses the ipn 'ipn' URI scheme.</t>
    </section>
    <section anchor="core-concepts">
      <name>Core Concepts</name>
      <t>Every ipn URI, no matter whether it is expressed with the a textual
      representation or a binary encoding, <bcp14>MUST</bcp14> be considered
      as a tuple of the following three components:</t>
      <ul spacing="normal">
        <li>
          <t>The Allocator Identifier</t>
        </li>
        <li>
          <t>The Node Number</t>
        </li>
        <li>
          <t>The Service Number</t>
        </li>
      </ul>

      <t>The Allocator Identifier indicates the entity responsible for
      assigning Node Numbers to individual resource nodes, maintaining
      uniqueness whilst avoiding the need for a single registry for all
      assigned Node Numbers. See <xref target="allocator-identifiers">Allocator Identifiers</xref>.</t>
      target="allocator-identifiers"/>.</t>

      <t>The Node Number is a shared identifier assigned to all ipn URIs for
      resources co-located on a single node. See <xref target="node-numbers">Node Numbers</xref>.</t>
      target="node-numbers"/>.</t>

      <t>The Service Number is an identifier to distinguish between resources
      on a given node. See <xref target="service-numbers">Service Numbers</xref>.</t> target="service-numbers"/>.</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 Number</xref>.</t>
      target="fqnn"/>.</t>

      <section anchor="null-uri">
        <name>The Null ipn URI</name>
        <t>It has been found that there is value in defining a unique 'null' Null
        ipn URI to indicate "nowhere".  This ipn URI is termed the "Null ipn URI",
        URI" and has all three components: components (the Allocator Identifier, Node Number,
        and Service Number, Number) set to the value zero (0).  No resource identified
        by the Null ipn URI exists, and any destination identified by such a
        resource is therefore by definition unreachable.</t>
      </section>

      <section anchor="allocator-identifiers">
        <name>Allocator Identifiers</name>
        <t>An Allocator is any organization that wishes to assign Node Numbers
        for use with the ipn 'ipn' URI scheme, scheme and has the facilities and governance
        to manage a public registry of assigned Node Numbers. The
        authorization to assign these numbers is provided through the
        assignment of an Allocator Identifier by IANA.  Regardless of other
        attributes of an Allocator, such Allocator (such as a name, point of contact, or other
        identifying information, information), Allocators are identified by Allocator
        Identifiers: a unique, unsigned integer, integers in the range 0 to 2^32-1.</t>
        2<sup>32-1</sup>.</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
        ipn URI. An Allocator may have multiple assigned Allocator
        Identifiers, but a given Allocator Identifier <bcp14>MUST</bcp14> only
        be associated with a single Allocator.</t>

        <t>A new IANA registry, "'ipn' Scheme URI Allocator Identifiers" registry Identifiers", is
        defined for the registration of Allocator Identifiers, Identifiers; see <xref target="iana-allocator-identifiers">'ipn' Scheme URI Allocator Identifiers registry</xref>.
        target="iana-allocator-identifiers"/>.  Although the uniqueness of Allocator
        Identifiers is required to enforce the uniqueness of ipn URIs, some
        identifiers are explicitly reserved for experimentation or future
        use.</t>

        <t>Each Allocator assigns Node Numbers according to its own policies,
        without risk of creating an identical ipn URI, as permitted by the
        rules in the <xref target="node-numbers">Node Numbers</xref> section of this document. target="node-numbers"/>.
	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>

        <t>If a system does not require interoperable deployment of ipn 'ipn' scheme
        URIs, then the <xref target="private-use">Private Private Use Node Numbers</xref> range,
        Numbers range (<xref target="private-use"/>), reserved by the <xref target="default-allocator">Default Allocator</xref> Default
	Allocator (<xref target="default-allocator"/>) for this purpose, are
        is to be used.</t>

        <section anchor="allocator-identifier-ranges">
          <name>Allocator Identifier Ranges</name>

          <t>Some organizations with internal hierarchies may wish to delegate
          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-come, first-served
          basis, there are operational benefits in assigning Allocator
          Identifiers to such an organization in a structured way so that way.  This allows
          an external observer can to detect that a group of Allocator Identifiers are
          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 both to both associate
          individual Allocator Identifiers with a single organization and to
          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 Inter-Domain
          Routing (CIDR) assignment of Internet Addresses addresses described in <xref
          target="RFC4632"/>. In that assignment scheme, an organization (such
          as an Internet Service Provider) Provider (ISP)) is assigned a network prefix such
          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 important ways.</t> ways:</t>
          <ol spacing="normal" type="1"><li> type="1">
	    <li>
              <t>Allocator Identifiers are used to identify organizations and are not, themselves, addresses.</t>
            </li>
            <li>
              <t>Allocator Identifiers may be less than 32 bits in length.</t>
            </li>
          </ol>

          <t>In order to differentiate between Allocator Identifier ranges
          using efficient bitwise operations, all ranges <bcp14>MUST</bcp14>
          be of a size S that is a power of 2, and for a given range of length
          N bits, with S = 2^N, 2<sup>N</sup>, the least-significant N bits of the
          first Allocator Identifier <bcp14>MUST</bcp14> be all 0.</t>

          <t>An example of the use of Allocator Identifier ranges for four
          organizations (A, B, C, and D) is as follows:</t>

          <table align="left" align="center" anchor="tab-air-example">
            <name>Allocator Identifier Range Assignment Example</name>
            <thead>
              <tr>
                <th align="left">Organization</th>
                <th align="center">Range align="left">Range (dec)</th>
                <th align="center">Range align="left">Range (hex)</th>
                <th align="center">Range align="left">Range Length (Bits)</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">Org A</td>
                <td align="center">974848 align="left">974848 .. 974975</td>
                <td align="center">0xEE000 align="left">0xEE000 .. 0xEE07F</td>
                <td align="center">7 align="left">7 bits</td>
              </tr>
              <tr>
                <td align="left">Org B</td>
                <td align="center">974976 align="left">974976 .. 974991</td>
                <td align="center">0xEE080 align="left">0xEE080 .. 0xEE08F</td>
                <td align="center">4 align="left">4 bits</td>
              </tr>
              <tr>
                <td align="left">Org C</td>
                <td align="center">974992 align="left">974992 .. 974993</td>
                <td align="center">0xEE090 align="left">0xEE090 .. 0xEE091</td>
                <td align="center">1 align="left">1 bit</td>
              </tr>
              <tr>
                <td align="left">Org D</td>
                <td align="center">974994</td> align="left">974994</td>
                <td align="center">0xEE092</td> align="left">0xEE092</td>
                <td align="center">0 align="left">0 bits</td>
              </tr>
            </tbody>
          </table>
          <t>With these assignments, any Allocator Identifier whose
          most-significant 25 bits match 0xEE000 belong to organization
          A. Similarly, any Allocator Identifier whose most-significant 28
          bits match 0xEE080 belong to organization B, and any Allocator
          Identifier whose most-significant 31 bits are 0xEE090 belong to
          organization C.  Organization D has a single Allocator Identifier,
          and hence a range of bit-length 0.</t>
        </section>

        <section anchor="default-allocator">
          <name>The Default Allocator</name>

          <t>As of the publication of <xref target="RFC7116"/>, the only
          organization permitted to assign Node Numbers was the Internet
          Assigned Numbers Authority (IANA) (IANA), which assigned Node Numbers via
          the IANA "CBHE Node Numbers" registry. This means that all ipn URIs
          created prior to the addition of Allocator Identifiers are assumed
          to have Node Number allocations that comply with the IANA "CBHE Node
          Numbers" registry.</t>

          <t>The presumption that, unless otherwise specified, that Node Numbers
          are allocated by IANA from a specific registry registry, unless otherwise specified,
          is formalized in this
          update to the ipn 'ipn' URI scheme by designating IANA as the Default Allocator,
          Allocator and by assigning the Allocator Identifier zero (0) in the <xref target="iana-allocator-identifiers">'ipn'
          "'ipn' Scheme URI Allocator Identifiers registry</xref> Identifiers" registry
	  (<xref target="iana-allocator-identifiers"/>) to the Default Allocator.
	  In any case
          where an encoded ipn URI does not explicitly include an Allocator
          Identifier, an implementation <bcp14>MUST</bcp14> assume that the
          Node Number has been allocated by the Default Allocator.</t>

          <t>A new IANA registry, "'ipn' Scheme URI Default Allocator Node Numbers" registry
          Numbers", is defined to control the allocation of Node Numbers Number
          values by the Default Allocator.  This new registry inherits
          behaviors and existing assignments from the IANA "CBHE Node Numbers"
          registry, and it reserves some other values as defined in the <xref target="special-node-numbers">Special Node Numbers</xref> section
          target="special-node-numbers"/>
          below.</t>
        </section>
      </section>

      <section anchor="node-numbers">
        <name>Node Numbers</name>
        <t>A Node Number identifies a node that hosts a resource in the
        context of an Allocator. A Node Number is an unsigned integer. A
        single Node Number assigned by a single Allocator <bcp14>MUST</bcp14>
        refer to a single node.</t>

        <t>All Node Number assignments, by all Allocators, <bcp14>MUST</bcp14>
        be in the range 0 to 2^32-1.</t> 2<sup>32-1</sup>.</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 Null ipn URI</xref>.</t> URI (<xref
        target="null-uri"/>).</t>

        <section anchor="fqnn">
          <name>Fully-qualified
          <name>Fully Qualified Node Numbers</name>
          <t>One of the advantages of ipn URIs is the ability to easily split
          the identity of a particular service from the node upon which the
          service exists.  For example example, a message received from one particular
          ipn URI may require a response to be sent to a different service on
          the same node that sent the original message.  Historically  Historically, the
          identifier of the sending node has been colloquially referred to as
          the "node number" or "node identifier".</t>

          <t>To avoid future confusion, when referring to the identifier of a
          particular node node, the term "Fully-qualified "Fully Qualified Node Number" (FQNN)
          <bcp14>MUST</bcp14> be used to refer to the combination of the Node
          Number component and Allocator Identifier component of an ipn URI
          that uniquely identifies a particular node.  In other words, an FQNN
          is the unique identifier of a particular node that supports services
          identified by ipn URIs.</t>

          <t>In the examples in this document, FQNNs are written as (Allocator
          Identifier, Node Number), e.g., Number). For example, <tt>(977000,100)</tt> is the FQNN
          for a node assigned Node Number 100 by an Allocator with Allocator
          Identifier 977000.</t>
        </section>
      </section>

      <section anchor="special-node-numbers">
        <name>Special Node Numbers</name>
        <t>Some special-case Node Numbers are defined by the Default Allocator,
        Allocator; see <xref target="iana-node-numbers">'ipn' Scheme URI Default Allocator Node Numbers registry</xref>.</t> target="iana-node-numbers"/>.</t>

        <section anchor="the-zero-node-number">
          <name>The Zero Node Number</name>
          <t>The Default Allocator assigns the use of Node Number zero (0)
          solely for identifying the <xref target="null-uri">Null Null ipn URI</xref>.</t>
          URI (<xref target="null-uri"/>).</t>
          <t>This means that any ipn URI with a zero (0) Allocator Identifier
          and a zero (0) Node Number, but a non-zero Service Number component component,
          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 anchor="localnode-uri">
          <name>LocalNode ipn URIs</name>
          <t>The Default Allocator reserves Node Number 2^32-1 2<sup>32-1</sup>
          (0xFFFFFFFFF) to specify resources on the local node, rather than on
          any specific individual node.</t>
          <t>This means that any ipn URI with a zero (0) Allocator Identifier
          and a Node Number of 2^32-1 2<sup>32-1</sup> refers to a service on the
          local bundle node. This form of ipn URI is termed a "LocalNode ipn
          URI".</t>
        </section>

        <section anchor="private-use">
          <name>Private Use Node Numbers</name>
          <t>The Default Allocator provides a range of Node Numbers that are
          reserved for "Private Use", Private Use, as defined in <xref
          target="RFC8126"/>.</t>
          <t>Any ipn URI with a zero (0) Allocator Identifier and a Node
          Number reserved for "Private Use" Private Use is not guaranteed to be unique
          beyond a single administrative domain.  An administrative domain, as
          used here, is defined as the set of nodes that share a unique
          allocation of FQNNs from the "Private Use" Private Use range.  These FQNNs can
          be considered to be functionally similar to "Private Address Space" private address space
          IPv4 addresses, as defined in <xref target="RFC1918"/>.</t>
          <t>Because of this lack of uniqueness, any implementation of a
          protocol using ipn URIs that resides on the border between
          administrative domains <bcp14>MUST</bcp14> have suitable mechanisms
          in place to prevent protocol units using such "Private Use" Private Use Node
          Numbers to cross between different administrative domains.</t>
        </section>
      </section>

      <section anchor="service-numbers">
        <name>Service Numbers</name>
        <t>A Service Number is an unsigned integer that identifies a
        particular service operating on a node.  A service in this case is
        some logical function that requires its own resource identifier to
        distinguish it from other functions operating on the same node.</t>
      </section>
    </section>

    <section anchor="textual-representation-of-ipn-uris">
      <name>Textual Representation of ipn URIs</name>

      <t>All ipn 'ipn' scheme URIs comply with <xref target="RFC3986"/>, target="RFC3986"/> and are
      therefore represented by a scheme identifier, identifier and a scheme-specific part.
      The scheme identifier is: is <tt>ipn</tt>, and the scheme-specific parts
      are represented as a sequence of numeric components separated with the
      '<tt>.</tt>' character.  A formal definition is provided below, see below (see
      <xref target="text-syntax">ipn URI Scheme Text Syntax</xref>, target="text-syntax"/>) and can be
      informally considered as:</t>

      <artwork><![CDATA[
ipn:[<allocator-identifier>.]<node-number>.<service-number>
]]></artwork>

      <t>To keep the text representation concise, the following rules apply:</t>
      <ol spacing="normal" type="1"><li> type="1">
	<li>
          <t>All leading <tt>0</tt> '<tt>0</tt>' characters <bcp14>MUST</bcp14> be
          omitted. A single '<tt>0</tt>' is valid.</t>
        </li>
        <li>
          <t>If the Allocator Identifier is zero (0), then the
          <tt>&lt;allocator-identifier&gt;</tt> and '<tt>.</tt>'
          <bcp14>MAY</bcp14> be omitted.</t>
        </li>
        <li>
          <t>If the Allocator Identifier is zero (0), and the Node Number is 2^32-1, i.e.,
          2<sup>32-1</sup> (i.e., the URI is a <xref target="localnode-uri">LocalNode LocalNode ipn URI</xref>, URI (<xref
          target="localnode-uri"/>)), then the character
          '<tt>!</tt>' <bcp14>SHOULD</bcp14> be used instead of the digits
          <tt>4294967295</tt>, although both forms are valid encodings.</t>
        </li>
      </ol>

      <t>Examples of the textual representation of ipn URIs can be found in
      <xref target="text-examples">Appendix A</xref>.</t> target="text-examples"/>.</t>

      <section anchor="text-syntax">
        <name>ipn
        <name>'ipn' URI Scheme Text Syntax</name>

        <t>The text syntax of an ipn URI <bcp14>MUST</bcp14> comply with the
        following ABNF syntax from <xref target="RFC5234"/> syntax, and reiterates repeats the
        core ABNF syntax rule for DIGIT defined by that specification:</t>
        <artwork type="abnf" align="left"><![CDATA[

        <sourcecode type="abnf"><![CDATA[
ipn-uri = "ipn:" ipn-hier-part

ipn-hier-part = fqnn "." service-number

fqnn = "!" / allocator-part

allocator-part = [allocator-identifier "."] node-number

allocator-identifier = number

node-number = number

service-number = number

number = "0" / non-zero-number

non-zero-number = (%x31-39 *DIGIT)

DIGIT = %x30-39
]]></artwork>
]]></sourcecode>

      </section>
    </section>

    <section anchor="usage-of-ipn-uris-with-bpv7">
      <name>Usage of ipn URIs with BPv7</name>

     <t>From the earliest days of experimentation with the Bundle Protocol Protocol,
      there has been a need to identify the source and destination of a
      bundle.  The IRTF BPv6 experimental specification <xref target="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 <xref target="RFC5050"/> to the IETF BPv7 specification. BPv7 specification <xref target="RFC9171"/>. <xref target="RFC9171"/> additionally
      defined an IANA registry called the "Bundle Protocol URI Scheme Types" registry
      registry, which identifies those URI schemes than that might be used to
      represent EIDs.  The ipn 'ipn' URI scheme is one such URI scheme.</t>
      <t>This section identifies the behavior and interpretation of ipn '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">
        <name>Uniqueness Constraints</name>
        <t>An ipn EID <bcp14>MUST</bcp14> identify a singleton endpoint. The
        bundle processing node that is the sole member of that endpoint
        <bcp14>MUST</bcp14> be the node identified by the <xref target="fqnn">Fully-qualified Node Number</xref> FQNN (<xref
        target="fqnn"/>) of the node.</t>
        <t>A single bundle processing node <bcp14>MAY</bcp14> have multiple
        ipn EIDs associated with it. However, all ipn EIDs that share any
        single FQNN <bcp14>MUST</bcp14> refer to the same bundle processing
        node.</t>

        <t>For example, <tt>ipn:977000.100.1</tt>, <tt>ipn:977000.100.2</tt>,
        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 anchor="the-null-endpoint">
        <name>The Null Endpoint</name>
        <t><xref section="3.2" sectionFormat="of" target="RFC9171"/> defines
        the concept of the 'null' Null endpoint, which is an endpoint that has no
        members and which is identified by a special 'null' Null EID.</t>
        <t>Within the ipn 'ipn' URI scheme, the 'null' Null EID is represented by the <xref target="null-uri">Null
       Null ipn URI</xref>. URI (<xref target="null-uri"/>).  This means that the URIs
        <tt>dtn:none</tt> (<xref section="4.2.5.1.1" sectionFormat="of"
        target="RFC9171"/>), <tt>ipn:0.0</tt>, and <tt>ipn:0.0.0</tt> all
        refer to the BPv7 'null' Null endpoint.</t>
      </section>

      <section anchor="bpv7-node-id">
        <name>BPv7 Node ID</name>
        <t><xref section="4.2.5.2" sectionFormat="of" target="RFC9171"/>
        introduces the concept of a "Node ID" that has the same format as an
        EID and that uniquely identifies a bundle processing node.</t>
        <t>Any ipn EID can serve as a "Node ID" for the bundle processing node
        identified by its <xref target="fqnn">Fully-qualified Node Number</xref>. FQNN (<xref target="fqnn"/>). That is, any ipn EID of the form ipn:A.B.C <tt>ipn:A.B.C</tt> may be used
        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 anchor="localnode-ipn-eids">
        <name>LocalNode ipn EIDs</name>

        <t>When a <xref target="localnode-uri">LocalNode LocalNode ipn URI</xref> URI (<xref target="localnode-uri"/>) is
        used as a BPv7 or BPv6 or BPv7 EID, it is termed a "LocalNode ipn EID".</t>

        <t>Because a LocalNode ipn EID only has meaning on the local bundle
        node, any such EID <bcp14>MUST</bcp14> be considered 'non-routable'.
        non-routable. This means that any bundle using a LocalNode ipn EID as
        a bundle source or bundle destination <bcp14>MUST NOT</bcp14> be
        allowed to leave the local node.  Equally, all externally received
        bundles featuring LocalNode EIDs as a bundle source or bundle
        destination <bcp14>MUST</bcp14> be discarded as invalid.</t>

        <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 directory (such as a DNS registration, 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 anchor="private-use-ipn-eids">
        <name>Private Use ipn EIDs</name>

        <t>Bundles destined for EIDs that use an ipn URI with a <xref target="fqnn">Fully-qualified Node Number</xref> an FQNN (<xref
        target="fqnn"/>) that is within the "Private Use"
        Private Use range of the <xref target="default-allocator">Default Allocator</xref> Default Allocator (<xref target="default-allocator"/>) are not universally unique, and therefore unique; therefore, they are only
        valid within the scope of the current administrative domain.  This
        means that any bundle using a Private Use ipn EID as a bundle source
        or bundle destination <bcp14>MUST NOT</bcp14> be allowed to cross
        administrative domains.  All implementations that could be deployed as
        a gateway between administrative domains <bcp14>MUST</bcp14> be
        sufficiently configurable to ensure that this is enforced, and
        operators <bcp14>MUST</bcp14> ensure correct configuration.</t>

        <t>Private Use ipn EIDs <bcp14>MUST NOT</bcp14> be present in any
        other part of a bundle that is destined for another administrative
        domain when the lack of uniqueness prevents correct operation. For
        example, a Private Use ipn EID <bcp14>MUST NOT</bcp14> be used as a Bundle Protocol Security
        BPSec <xref target="RFC9172"/> security source for
        a bundle, bundle when the bundle is destined for a different administrative
        domain.</t>
      </section>

      <section anchor="well-known-service-numbers">
        <name>Well-known
        <name>Well-Known Service Numbers</name>

        <t>It is convenient for BPv7 services that have a public specification
        and wide adoption to be identified by a pre-agreed default Service
        Number, so that unless extra configuration is applied, overridden by explicit configuration, such services
        can be sensibly assumed to be operating on the well-known Service
        Number on a particular node.</t>

        <t>If a different service uses the number, or the service uses a
        different number, BPv7 will continue to operate, but some
        configuration may be required to make the individual service
        operational.</t>

        <t>A new IANA registry, "'ipn' Scheme URI Well-known Well-Known Service Numbers
        for BPv7" registry BPv7", is defined for the registration of well-known BPv7 Service Numbers,
        Numbers; see <xref target="iana-service-numbers">'ipn' Scheme URI Well-known Service Numbers for BPv7 registry</xref>. target="iana-service-numbers"/>.  This registry
        records the assignments of Service Numbers for well-known services, services
        and also explicitly reserves ranges for both experimentation and private use.</t>
        Private Use.</t>
      </section>

      <section anchor="administrative-endpoints">
        <name>Administrative Endpoints</name>

        <t>The service identified by a Service Number of zero (0)
        <bcp14>MUST</bcp14> be interpreted as the Administrative Endpoint of
        the node, as defined in <xref section="3.2" sectionFormat="of"
        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 anchor="cbor-representation-of-ipn-uris-with-bpv7">
      <name>CBOR representation Representation of ipn URIs with BPv7</name>
      <t><xref section="4.2.5.1" sectionFormat="of" target="RFC9171"/>
      requires that any URI scheme used to represent BPv7 EIDs
      <bcp14>MUST</bcp14> define how the scheme-specific part of the URI
      scheme is encoded with CBOR Concise Binary Object Representation (CBOR) <xref target="RFC8949"/>. To meet this
      requirement, this section describes the CBOR encoding and decoding
      approach for ipn EIDs. The formal definition of the CBOR representation
      is specified, specified; see <xref target="cbor-encoding">ipn URI Scheme CBOR syntax</xref>.</t> target="cbor-encoding"/>.</t>

      <section anchor="ipn-eid-cbor-encoding">
        <name>ipn EID CBOR Encoding</name>
        <t>Generic URI approaches to encoding ipn EIDs are unlikely to be
        efficient because they do not consider the underlying structure of the ipn
        'ipn' URI scheme. Since the creation of the ipn 'ipn' URI scheme was motivated
        by the need for concise identification and rapid processing, the
        encoding of ipn EIDs maintains these properties.</t>
        <t>Fundamentally, <xref target="RFC9171"/> ipn EIDs from <xref target="RFC9171"/> are represented as
        a sequence of identifiers. In the text syntax, the numbers are
        separated with the '<tt>.</tt>' delimiter; in CBOR, this ordered
        series of numbers can be represented by an array. Therefore, when
        encoding ipn EIDs for use with BPv7, the scheme-specific part of an
        ipn URI <bcp14>MUST</bcp14> be represented as a CBOR array of either
        two (2) or three (3) elements. Each element of the array
        <bcp14>MUST</bcp14> be encoded as a single CBOR unsigned integer.</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">Appendix B</xref>.</t> target="cbor-examples"/>.</t>

        <section anchor="two-encode">
          <name>Two-Element Scheme-Specific Encoding</name>

          <t>In the two-element scheme-specific encoding of an ipn EID, the
          first element of the array is an encoding of the <xref target="fqnn">Fully-qualified Node Number</xref> FQNN (<xref
          target="fqnn"/>), and the second
          element of the array is the ipn EID Service Number.</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>
              <t>The least significant 32 bits <bcp14>MUST</bcp14> represent
              the Node Number associated with the ipn EID.</t>
            </li>
            <li>
              <t>The most significant 32 bits <bcp14>MUST</bcp14> represent
              the Allocator Identifier associated with the ipn EID.</t>
            </li>
          </ol>

          <t>For example example, the ipn EID of <tt>ipn:977000.100.1</tt> has an FQNN
          of <tt>(977000,100)</tt> <tt>(977000,100)</tt>, which would be encoded as
          <tt>0xEE868_00000064</tt>.  The resulting two-element array
          <tt>[0xEE868_00000064, 0x01]</tt> would be encoded in CBOR as the
          following 11 octet 11-octet sequence:</t>
          <artwork><![CDATA[

<!--[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 Fully-Qualified Node Number
         01                  # Service Number
]]></artwork>

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

[RT]: @Ed, are you happy to compress "2 Element ipn EID scheme-specific encoding"
to "2 Element ipn EID encoding" to fit?
-->

          <sourcecode type="cbor"><![CDATA[
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
]]></sourcecode>

          <t>The two-element scheme-specific encoding provides for backwards-compatibility backwards
          compatibility with the encoding provided in <xref
          section="4.2.5.1.2" sectionFormat="of" target="RFC9171"/>. When used
          in this way, the encoding of the FQNN replaces the use of the "Node Number" Node
          Number that was specified in RFC9171. <xref target="RFC9171"/>. When the
          Node Number is allocated by the <xref target="default-allocator">Default Allocator</xref>, Default Allocator (<xref
          target="default-allocator"/>), the encoding of
          the FQNN and the RFC9171 encoding of the "Node Number" Node Number from <xref
          target="RFC9171"/> are identical.</t>
        </section>

        <section anchor="three-encode">
          <name>Three-Element Scheme-Specific Encoding</name>
          <t>In the three-element scheme-specific encoding of an ipn EID, the EID:</t>

	  <ol>
	    <li>the first element of the array is the Allocator Identifier, the Identifier,</li>
	    <li>the second element of the array is the Node Number, and the and</li>
	    <li>the third element of the array is the Service Number.</t> 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> <tt>[977000,100,1]</tt>, which
          would be encoded in CBOR as the following 9 octet 9-octet sequence:</t>
          <artwork><![CDATA[

          <sourcecode type="cbor"><![CDATA[
82                # 2-Element Endpoint Encoding
   02             # uri-code: 2 (IPN ('ipn' URI scheme)
   83             # 3 Element ipn EID scheme-specific encoding
      1A 000EE868 # Allocator Identifier
      64          # Node Number
      01          # Service Number
]]></artwork>
]]></sourcecode>

          <t>The three-element scheme-specific encoding allows for a more
          efficient representation of ipn EIDs using smaller Allocator
          Identifiers, and implementations are <bcp14>RECOMMENDED</bcp14> to
          use this encoding scheme, scheme unless explicitly mitigating for
          interoperability issues, issues; see <xref target="compatibility">see Scheme Compatibility</xref>.</t> target="compatibility"/>.</t>

          <t>When encoding an ipn EID using the <xref target="default-allocator">Default Allocator</xref> Default Allocator (<xref
          target="default-allocator"/>) with this
          encoding scheme, the first element of the array is the value zero
          (0).  In this case case, using the equivalent <xref target="two-encode">Two-Element Scheme-Specific Encoding</xref> two-element scheme-specific
	  encoding (<xref target="two-encode"/>) will
          result in a more concise CBOR representation, and therefore representation; therefore, it is
          <bcp14>RECOMMENDED</bcp14> that implementations use that encoding
          instead.</t>
        </section>
      </section>

      <section anchor="ipn-eid-cbor-decoding">
        <name>ipn EID CBOR Decoding</name>

        <t>The presence of different scheme-specific encodings does not
        introduce any decoding ambiguity.</t>
        <t>An ipn EID CBOR decoder can reconstruct an ipn EID using the
        following logic. In this description, the term <tt>enc_eid</tt> refers
        to the CBOR encoded CBOR-encoded ipn EID, and the term <tt>ipn_eid</tt> refers to
        the decoded ipn EID.</t>
        <artwork align="left"

        <sourcecode type="pseudocode"><![CDATA[
if enc_eid.len() == 3
{
  ipn_eid.allocator_identifier := enc_eid[0];
  ipn_eid.node_number := enc_eid[1];
  ipn_eid.service_number := enc_eid[2];
}
else if enc_eid.len() == 2
{
  ipn_eid.allocator_identifier := enc_eid[0] >> 32;
  ipn_eid.node_number := enc_eid[0] & (2^32-1); (2^(32-1));
  ipn_eid.service_number := enc_eid[1];
}
]]></artwork>
]]></sourcecode>
      </section>

      <section anchor="cbor-encoding">
        <name>ipn
        <name>'ipn' URI Scheme CBOR syntax</name>
        <t>A Syntax</name>

        <t>When encoded in CBOR <xref
        target="RFC8949"/>, a BPv7 endpoint identified by an ipn URI, when encoded in Concise Binary Object Representation (CBOR) <xref target="RFC8949"/>, URI
        <bcp14>MUST</bcp14> comply with the following Concise Data Definition
        Language (CDDL) <xref target="RFC8610"/> specification:</t>
        <artwork type="cddl" align="left"><![CDATA[

        <sourcecode type="cddl"><![CDATA[
eid = $eid .within eid-structure

eid-structure = [
  uri-code: uint,
  SSP: any
]

; ... Syntax for other uri-code values defined in RFC9171 RFC 9171 ...

$eid /= [
  uri-code: 2,
  SSP: ipn-ssp2 / ipn-ssp3
]
ipn-ssp2 = [
  fqnn: uint,  ; packed value
  service-number: uint
]
ipn-ssp3 = [
  allocator-identifier: uint .lt 4294967296,
  node-number: uint .lt 4294967296,
  service-number: uint
]
]]></artwork>
]]></sourcecode>

        <t>Note: The <tt>node-number</tt> component will be the numeric
        representation of the concatenation of the Allocator Identifier and
        Node Number when the 2-element two-element encoding scheme has been used.</t>
      </section>

      <section anchor="ipn-eid-matching">
        <name>ipn EID Matching</name>
        <t>Regardless of whether the two-element or three-element
        scheme-specific encoding is used, ipn EID matching <bcp14>MUST</bcp14>
        be performed on the decoded EID information itself. Different
        encodings of the same ipn EID <bcp14>MUST</bcp14> be treated as
        equivalent when performing EID-specific functions.</t>

        <t>For example, the ipn EID of <tt>ipn:977000.100.1</tt> can be
        represented as either the two-element encoding of
        <tt>0x821B000EE8680000006401</tt> or the three-element encoding of
        <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 - same: as
        representing the ipn EID <tt>ipn:977000.100.1</tt>.</t>
      </section>
    </section>

    <section anchor="special-considerations">
      <name>Special Considerations</name>

      <t>The ipn 'ipn' URI scheme provides a compact and hierarchical mechanism for
      identifying services on network nodes. There is a significant amount of
      utility in the ipn 'ipn' URI scheme approach to identification. However,
      implementers should take into consideration the following observations
      on the use of the ipn 'ipn' URI scheme, particularly in regard to
      interoperability with implementations that pre-date this
      specification.</t>

      <section anchor="compatibility">
        <name>Scheme Compatibility</name>

        <t>The ipn 'ipn' URI scheme update that has been presented in this document
        preserves backwards compatibility with any ipn 'ipn' URI scheme going back
        to the provisional definition of the ipn 'ipn' scheme in the experimental Compressed
        specification "Compressed Bundle Header Encoding (CBHE)" <xref
        target="RFC6260"/> specification in 2011. This means that any ipn URI that was valid
        prior to the publication of this update remains a valid ipn URI.</t>

        <t>Similarly, the <xref target="two-encode">two-element two-element
        scheme-specific encoding</xref> encoding (<xref target="two-encode"/>) is also backwards-compatible
	backwards compatible with the
        encoding of ipn URIs provided in <xref target="RFC9171"/>. Any
        existing RFC9171-compliant implementation compliant with <xref target="RFC9171"/> will
        produce an ipn URI encoding in compliance with this specification.</t>
        <t>The introduction of optional non-default Allocator Identifiers and
        a three-element scheme-specific encoding does not make this ipn URI
        scheme update forwards-compatible. forwards compatible. Existing implementations for which
        support of this update is desired <bcp14>MUST</bcp14> be updated to be
        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 anchor="cbor-representation-interoperability">
        <name>CBOR Representation Interoperability</name>
        <t>Care must be taken when deploying implementations that default to
        using the three-element encoding in networks that include
        implementations that only support the two-element encoding <xref target="RFC9171"/> encoding.
        target="RFC9171"/>. Because the existing implementations will reject
        bundles that use the three-element encoding as malformed, correct
        forwarding of semantically valid bundles will fail.  The used
        mitigation for this issue depends on the nature of the
        interoperability required by the deployment. Techniques can
        include:</t>
        <ul spacing="normal">
          <li>
            <t>A configuration option indicating when an implementation must
            use the two-element encoding for all ipn EIDs when processing
            bundles destined to a given endpoint: endpoint. This would be suitable when
            adding a newer implementation to a network of existing
            implementations.</t>
          </li>
          <li>
            <t>Selective bundle encapsulation, whereby bundles that are known
            to originate from implementations that do not support the
            three-element encoding are tunnelled tunneled across regions of the network
            that require the three-element encoding: encoding. This would utilize
            specially configured 'gateway nodes' "gateway nodes" to perform the tunnel
            encapsulation and decapsulation, decapsulation and would be suitable when
            joining an existing network to a larger network.</t>
          </li>
        </ul>
        <t>Techniques that do not mitigate the problem include:</t>
        <ul spacing="normal">
          <li>
            <t>Heuristic determination of the correct encoding to use when
            responding to a bundle by examining the incoming bundle: bundle. It is not
            possible to determine whether the two-element encoding is required
            by the destination when composing a new bundle in response to the
            receipt of a bundle, such as a status report, because ipn EIDs
            assigned by the Default Allocator use the two-element encoding,
            whether or not the implementation supports the three-element encoding or not.</t> encoding.</t>
          </li>
          <li>

            <t>Transcoding bundles at intermediate nodes: nodes. <xref
            target="RFC9171"/> requires the bundle primary block to be immutable,
            and even if ipn EIDs in the primary block do not require
            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 <xref target="RFC9172"/> bundle
            security blocks or bundle integrity blocks, blocks <xref target="RFC9172"/>, making them
            immutable.</t>
          </li>
        </ul>
      </section>

      <section anchor="text-representation-compatibility">
        <name>Text Representation Compatibility</name>
        <t>The textual representation of ipn URIs is not forwards-compatible forwards compatible
        with <xref target="RFC9171"/>, therefore target="RFC9171"/>. Therefore, care must be taken when
        deploying implementations or tooling that use the textural
        representation of ipn URIs and support for non-default Allocator
        Identifiers is required.  For example example, <xref section="4.6"
        sectionFormat="of" target="RFC9174"/> specifies that the Session Initialization session
        initialization message "...<bcp14>SHALL</bcp14> contain the UTF-8
        encoded node ID of the entity that sent the SESS_INIT message."  In
        such cases cases, the considerations that apply to the use of the 3-element three-element
        CBOR encoding also apply to the text representation when a non-default
        Allocator Identifier is present.</t>
      </section>

      <section anchor="bundle-protocol-version-6-compatibility">
        <name>Bundle Protocol Version 6 Compatibility</name>
        <t>This document updates the use of ipn EIDs for BPv7, however BPv7; however, the ipn 'ipn'
        URI scheme was originally defined for use with version 6 of the Bundle Protocol (BPv6). BPv6.  This document does not update any of the behaviors, wire-formats
        wire-formats, or mechanisms of BPv6.  Therefore, ipn EIDs with
        non-default Allocator Identifiers <bcp14>MUST NOT</bcp14> be used with
        BPv6, and the Allocator Identifier prefix <bcp14>MUST</bcp14> be
        omitted from any textural representation.  It should be noted that
        BPv6 has no concept of LocalNode EIDs, EIDs and will therefore treat such
        EIDs as routable.</t>
      </section>

      <section anchor="late-binding">
        <name>Late Binding</name>

        <t><xref target="RFC9171"/> mandates the concept of the "late binding" of
        an EID, whereby the address of the destination of a bundle is resolved
        from its identifier hop-by-hop as it transits a BPv7 network.  This
        per-hop binding of identifiers to addresses underlines the fact that
        EIDs are purely names, names and should not carry any implicit or explicit
        information concerning the current location or reachability of an
        identified node and service.  This removes the need to rename a node
        as its location changes.</t>

        <t>The concept of "late binding" late binding is preserved in this ipn 'ipn' URI
        scheme. Elements of an ipn URI <bcp14>MUST NOT</bcp14> be regarded as
        carrying information relating to location, reachability, or other
        addressing/routing concern.</t> 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 anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This section updates the security considerations from <xref
      section="4.2.5.1.2" sectionFormat="of" target="RFC9171"/> to account for
      the inclusion of Allocator Identifiers in the ipn 'ipn' URI scheme when used
      with BPv7.</t>

      <section anchor="reliability-and-consistency">
        <name>Reliability and consistency</name> Consistency</name>
        <t>None of the BPv7 endpoints identified by ipn EIDs are guaranteed to
        be reachable at any time, and the identity of the processing entities
        operating on those endpoints is never guaranteed by the Bundle
        Protocol itself. Verification of the signature provided by the Block
        Integrity Block (BIB) targeting the bundle's primary block, as defined by Bundle
       "Bundle Protocol Security (BPSec)" <xref target="RFC9172"/>, is required for
        this purpose.</t>
      </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].

[RT]: I don't mind either way, the original is my personal preference,
but the meaning is kept intact. @Ed?
-->
      <section anchor="malicious-construction">
        <name>Malicious construction</name> Construction</name>
        <t>Malicious construction of a conformant ipn URI is limited to the
        malicious selection of Allocator Identifiers, Node Numbers, and
        Service Numbers. That is, a maliciously constructed ipn EID could be
        used to direct a bundle to an endpoint that might be damaged by the
        arrival of that bundle or, alternatively, to declare a false source
        for a bundle and thereby cause incorrect processing at a node that
        receives the bundle. 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 <xref target="RFC9172"/>, target="RFC9172"/> and TCPCLv4 TCP Convergence Layer version 4 (TCPCLv4) with TLS <xref
        target="RFC9174"/>.</t>
      </section>

      <section anchor="back-end-transcoding">
        <name>Back-end transcoding</name>
        <name>Back-End Transcoding</name>
        <t>The limited expressiveness of URIs of the ipn 'ipn' scheme effectively
        eliminates the possibility of threat threats due to errors in back-end
        transcoding.</t>
      </section>

      <section anchor="local-and-private-use-ipn-eids">
        <name>Local and Private Use ipn EIDs</name>
        <t>Both <xref target="localnode-uri">LocalNode</xref> LocalNode (<xref target="localnode-uri"/>) and <xref target="private-use">Private Use</xref> Private Use (<xref
        target="private-use"/>) ipn URIs present a risk to the
        stability of deployed BPv7 networks.  If either type of ipn URI are is
        allowed to propagate beyond the domain in which they are valid, then
        the required uniqueness of ipn URIs no longer holds, and this fact can
        be abused by a malicious node to prevent the correct functioning of
        the network as a whole.</t>
        <t>See Sections <xref target="localnode-ipn-eids">LocalNode ipn EIDs</xref> target="localnode-ipn-eids" format="counter"/> and
        <xref target="private-use-ipn-eids">Private Use ipn EIDs</xref> target="private-use-ipn-eids" format="counter"/> for
        required behaviors to mitigate against this form of abuse.</t>
      </section>

      <section anchor="sensitive-information">
        <name>Sensitive information</name> Information</name>
        <t>Because ipn URIs are used only to represent the numeric identities
        of resources, the risk of disclosure of sensitive information due to
        interception of these URIs is minimal. Examination of ipn URIs could
        be used to support traffic analysis; where traffic analysis is a
        plausible danger, bundles should be conveyed by secure
        convergence-layer protocols that do not expose endpoint IDs, such as
        TCPCLv4 <xref target="RFC9174"/>.</t>
      </section>

      <section anchor="semantic-attacks">
        <name>Semantic attacks</name> Attacks</name>
        <t>The simplicity of ipn the 'ipn' URI scheme syntax minimizes the possibility
        of misinterpretation of a URI by a human user.</t>
      </section>
    </section>

    <section anchor="iana">
      <name>IANA Considerations</name>

<!-- [rfced] We have included some specific questions about the IANA
text below. In addition to responding to those questions, please
review all of the IANA-related updates carefully and let us know
if any further updates are needed. Note that the registries can be
viewed at <https://www.iana.org/assignments/uri-schemes/>.

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.

 [RT]:I think Table 4 and 5 are an improvement, but I would drop the duplicate
 "Invalid" final row from Table 5.

 *[rfced]: removed the "invalid" entry from Table 5.

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.

**IANA update needed

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.

 [RT]: I'm not sure I like the duplication of the "Reserved for..."
 entries in Table 7.  If the entries are reserved in table 6, why are
 they 'initial' in Table 7?

 *[rfced]: removed the entry in Table 7.

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?

 [RT]: We hope this is clear to readers.  Happy with the change

 **[rfced]: is action needed or is the current ok?

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"

[RT]: Happy with >= instead of "greater than or equal to".

 ** IANA update needed

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.

 *[rfced]: removed this entry per the author to avoid redundancy.

-->

      <t>The following sections detail requests to IANA for the creation of
      two new registries, IANA registries and the renaming of an existing registry.</t>
      <t>IANA is requested to update the reference to the 'ipn' scheme in IANA registry under the "Uniform Resource Identifier (URI) Schemes" registry to this document.</t> group.</t>

      <t>IANA is requested to add has also updated the new registries, and relocate reference for the existing registries under 'ipn' scheme to this document in the
      "Uniform Resource Identifier (URI) Schemes" protocol registry.</t>

      <section anchor="iana-allocator-identifiers">
        <name>'ipn' Scheme URI Allocator Identifiers registry</name> Registry</name>
        <t>IANA is requested to create has created a new registry entitled titled "'ipn' Scheme
        URI Allocator Identifiers".  The registration policy for this registry, using  Using terms defined in <xref
        target="RFC8126"/>, is:</t> the registration procedures for this registry are:</t>

   <table align="left" align="center" anchor="tab-ipn-allocator-identifiers-reg">
          <name>'ipn'
          <name>Registration Procedures for the 'ipn' Scheme URI Numbering Allocator Identifiers registration policies</name> Registry</name>
          <thead>
            <tr>
              <th align="center">Range</th> align="left">Range</th>
              <th align="left">Registration Policy</th> Procedures</th>
	      <th align="left">Note</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">0..0xFFFF</td> align="left">0..0xFFFF</td>
              <td align="left">Expert Review, Single Review</td>
	      <td>Single Allocator Identifiers only</td>
            </tr>
            <tr>
              <td align="center">0x10000..0x3FFFFFFF</td> align="left">0x10000..0x3FFFFFFF</td>
              <td align="left">Expert Review</td>
	      <td></td>
            </tr>
            <tr>
              <td align="center">0x40000000..0x7FFFFFFF</td> align="left">0x40000000..0x7FFFFFFF</td>
              <td align="left">Experimental Use</td>
	       <td></td>
            </tr>
            <tr>
              <td align="center">0x80000000..0xFFFFFFFF</td> align="left">0x80000000..0xFFFFFFFF</td>
              <td align="left">Reserved, align="left">Reserved</td>
	      <td> Future Expansion</td>
            </tr>
            <tr>
              <td align="center">&gt;= 2^32</td> align="left">&gt;= 2<sup>32</sup></td>
              <td align="left">Reserved</td>
	      <td></td>
            </tr>
          </tbody>
        </table>

        <t>Each entry in this registry associates one or more Allocator
        Identifiers with a single organization. Within the registry, the
        organization is identified using the "Name" and "Point of Contact" "Change Controller"
        fields. It is expected that each identified organization publishes will publish
        some listing of allocated node numbers - Node Numbers, the pointer to which is
        listed in the "Reference" field of the registry.</t>

        <t>Note that the “Single "Single Allocator Identifiers only” only" language in Registration Policy
        the registration procedure for this registry indicates that, within the
        indicated range, the allocation of a sequence of consecutive Allocator identifiers
        Identifiers to a single organization is prohibited.  IANA is requested to note this in the registration policy for this registry.</t> prohibited.</t>

        <t>The initial values for in the registry are:</t>

        <table align="left" align="center" anchor="tab-ipn-allocator-identifiers-vals">
          <name>'ipn'
          <name>Initial Values in the 'ipn' Scheme URI Allocator Identifiers initial values</name> Registry</name>
          <thead>
            <tr>
              <th align="left">Name</th>
              <th align="center">Range align="left">Range (dec)</th>
              <th align="center">Range align="left">Range (hex)</th>
              <th align="center">Range align="left">Range Length (Bits)</th>
              <th align="center">Reference</th> align="left">Reference</th>
              <th align="center">Point of Contact</th> align="left">Change Controller</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">
                <xref target="default-allocator">Default Allocator</xref></td> align="left">Default Allocator</td>
              <td align="center">0</td> align="left">0</td>
              <td align="center">0x0</td> align="left">0x0</td>
              <td align="center">0</td> align="left">0</td>
              <td align="center">This document</td> align="left">RFC 9758, <xref target="default-allocator"/></td>
              <td align="center">IANA</td> align="left">IETF</td>
            </tr>
            <tr>
              <td align="left">Example Range</td>
              <td align="center">974848 .. 978943</td> align="left">974848-978943</td>
              <td align="center">0xEE000 .. 0xEEFFF</td> align="left">0xEE000-0xEEFFF</td>
              <td align="center">12 align="left">12 bits</td>
              <td align="center">This document</td> align="left">RFC 9758</td>
              <td align="center">IANA</td> align="left">IETF</td>
            </tr>
          </tbody>
        </table>
        <t>The "Example Range" is assigned for use in examples in
        documentation and sample code.</t>

        <section anchor="guidance-for-designated-experts">
          <name>Guidance for Designated Experts</name>
          <t>Due to the nature of the CBOR encoding of unsigned integers used
          for Allocator Identifiers with BPv7, Allocator Identifiers with a
          low value number are encoded more efficiently than larger numbers.
          This makes low value Allocator Identifiers more desirable than
          larger Allocator Identifiers, and therefore Identifiers; therefore, care must be taken when
          assigning Allocator Identifier ranges to ensure that a single
          applicant is not granted a large swathe of highly desirable numbers
          at the expense of other applicants.  To this end, Designated Experts designated experts
          are strongly recommended to familiarize themselves with the CBOR
          encoding of unsigned integers in <xref target="RFC8949"/>.</t>
        </section>
      </section>

      <section anchor="iana-node-numbers">
        <name>'ipn' Scheme URI Default Allocator Node Numbers registry</name> Registry</name>

        <t>IANA is requested to rename has renamed the "CBHE Node Numbers" registry defined
        (defined in <xref section="3.2.1" sectionFormat="of" target="RFC7116"/> target="RFC7116"/>)
        to the "'ipn' Scheme URI Default Allocator Node Numbers" registry.</t>
        <t>The registration policy for this registry, using registry and moved it to the "Uniform Resource Identifier (URI) Schemes" registry group. IANA has added the following note to the "CBHE Node Numbers" registry:</t>

<blockquote>
Note: Renamed "CBHE Node Numbers" as "'ipn' Scheme URI Default Allocator Node Numbers" and moved it to &lt;<eref target="https://www.iana.org/assignments/uri-schemes"/>&gt; per RFC 9758.
</blockquote>

        <t>Using terms defined in <xref target="RFC8126"/>, is updated to be:</t> the registration procedures for this registry are:</t>

        <table align="left" align="center" anchor="tab-ipn-node-numbers-reg">
          <name>'ipn'
          <name>Registration Procedures for the 'ipn' Scheme URI Default Allocator Node Numbers registration policies</name> Registry</name>
          <thead>
            <tr>
              <th align="center">Range</th> align="left">Range</th>
              <th align="left">Registration Policy</th> Procedures</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">0</td>
              <td align="left">Reserved for the <xref target="null-uri">Null ipn URI</xref></td>
            </tr>
            <tr>
              <td align="center">1..0x3FFF</td> align="left">1..0x3FFF</td>
              <td align="left">Private Use</td>
            </tr>
	      <tr>
              <td align="center">0x4000..0xFFFFFFFE</td> align="left">0x4000..0xFFFFFFFE</td>
              <td align="left">Expert Review</td>
             </tr>
            <tr>
              <td align="center">0xFFFFFFFF</td> align="left">&gt;= 2<sup>32</sup></td>
              <td align="left">Invalid</td>
            </tr>
          </tbody>
        </table>

	<t>IANA has registered the following values in the "'ipn' Scheme URI Default 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 Numbers Registry</name>
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="left">Description</th>
	      <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">0</td>
              <td align="left">Reserved for <xref target="localnode-uri">LocalNode the Null ipn URIs</xref></td> URI</td>
	      <td align="left"><xref target="RFC7116"/> and RFC 9758, <xref target="null-uri"/></td>
            </tr>
	      <tr>
              <td align="center">&gt;= 2^32</td> align="left">4294967295</td>
              <td align="left">Invalid</td> align="left">Reserved for LocalNode ipn URIs</td>
	      <td align="left">RFC 9758, <xref target="localnode-uri"/></td>
              </tr>
          </tbody>
        </table>

        <t>As IANA is requested to has only rename renamed the registry, all existing
        registrations will remain.</t>

      </section>

      <section anchor="iana-service-numbers">
        <name>'ipn' Scheme URI Well-known Well-Known Service Numbers for BPv7 registry</name> Registry</name>

        <t>IANA is requested to create has created a new registry entitled titled "'ipn' Scheme
        URI Well-known Well-Known Service Numbers for BPv7" registry.  The registration policy for this registry, using BPv7".  Using terms defined in
        <xref target="RFC8126"/>, is:</t> the registration procedures for this registry are:</t>

        <table align="left" align="center" anchor="tab-ipn-service-numbers-reg">
          <name>'ipn'
          <name>Registration Procedures for the 'ipn' Scheme URI Well-known Well-Known Service Numbers for BPv7 registration policies</name> Registry</name>
          <thead>
            <tr>
              <th align="center">Range</th> align="left">Range</th>
              <th align="left">Registration Policy</th> Procedures</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">0</td>
              <td align="left">Reserved for the <xref target="administrative-endpoints">Administrative Endpoint</xref></td>
            </tr>
            <tr>
              <td align="center">1..127</td> align="left">1..127</td>
              <td align="left">Private Use</td>
            </tr>
            <tr>
              <td align="center">128..255</td> align="left">128..255</td>
              <td align="left">Standards Action</td>
            </tr>
            <tr>
              <td align="center">0x0100..0x7FFF</td> align="left">0x0100..0x7FFF</td>
              <td align="left">Private Use</td>
            </tr>
            <tr>
              <td align="center">0x8000..0xFFFF</td> align="left">0x8000..0xFFFF</td>
              <td align="left">Specification Required</td>
            </tr>
            <tr>
              <td align="center">0x10000..0xFFFFFFFF</td> align="left">0x10000..0xFFFFFFFF</td>
              <td align="left">Private Use</td>
            </tr>
            <tr>
              <td align="center">&gt;= 2^32</td> align="left">&gt;= 2<sup>32</sup></td>
              <td align="left">Reserved for future expansion</td>
            </tr>
          </tbody>
        </table>

        <t>The initial values for in the registry are:</t>

        <table align="left" align="center" anchor="tab-ipn-service-numbers-vals">
          <name>'ipn'
          <name>Initial Values in the 'ipn' Scheme URI Well-known Well-Known Service Numbers for BPv7 initial values</name> Registry</name>
          <thead>
            <tr>
              <th align="center">Value</th> align="left">Value</th>
              <th align="left">Description</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">0</td> align="left">0</td>
              <td align="left">The <xref target="administrative-endpoints">Administrative Endpoint</xref></td> Administrative Endpoint</td>
              <td align="left">
                <xref target="RFC9171"/>, This document</td> target="RFC9171"/> and RFC 9758, <xref target="administrative-endpoints"/></td>
            </tr>
            <tr>
              <td align="center">0xEEE0 .. 0xEEEF</td> align="left">0xEEE0..0xEEEF</td>
              <td align="left">Example Range</td>
              <td align="left">This document</td> align="left">RFC 9758</td>
            </tr>
          </tbody>
        </table>
        <t>The "Example Range" is assigned for use in examples in
        documentation and sample code.</t>

        <section anchor="guidance-for-designated-experts-1">
          <name>Guidance for Designated Experts</name>
          <t>This registry is intended to record the default Service Numbers
          for well-known, interoperable services that are available and of use to the
          entire BPv7 community, hence community; hence, all ranges not marked for Private Use
          <bcp14>MUST</bcp14> have a corresponding publicly available
          specification describing how one interfaces with the service.</t>
          <t>Services that are specific to a particular deployment or
          co-operation may require a registry to reduce administrative burden,
          but do not require an entry in this registry.</t>
        </section>
      </section>
    </section>
  </middle>

  <back>
    <references>
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC6260">
          <front>
            <title>Compressed Bundle Header Encoding (CBHE)</title>
            <author fullname="S. Burleigh" initials="S." surname="Burleigh"/>
            <date month="May" year="2011"/>
            <abstract>
              <t>This document describes a convention by which Delay-Tolerant Networking (DTN) Bundle Protocol (BP) "convergence-layer" adapters may represent endpoint identifiers in a compressed form within the primary blocks of bundles, provided those endpoint identifiers conform to the structure prescribed by this convention.</t>
              <t>Compressed Bundle Header Encoding (CBHE) compression is a convergence-layer adaptation. It is opaque to bundle processing. Therefore, it has no impact on the interoperability of different Bundle Protocol implementations, but instead affects only the interoperability of different convergence-layer adaptation implementations.</t>
              <t>This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication 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 Header 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) mechanism for the InterPlanetary Network ('ipn' URI scheme). Moreover, RFC 5050 defines values for the Bundle Protocol administrative record type. All of these fields 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 multiple interoperable implementations, the group would like to hand off the registries to IANA for official management. This document describes the necessary IANA actions.</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, III"/>
            <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 Delay-Tolerant Networking Research Group of the Internet Research Task Force and documented 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</title>
            <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 signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. 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="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</title>
            <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 protocol 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 constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations 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 describing the conditions under which new values should be assigned, as well as when 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 Considerations 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 5226.</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="Crocker"/>
            <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 Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [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 format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t>
              <t>This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange 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 Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</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 Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8610"/>
          <seriesInfo name="DOI" value="10.17487/RFC8610"/>
        </reference>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6260.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7116.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9171.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8610.xml"/>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC5050">
          <front>
            <title>Bundle Protocol Specification</title>
            <author fullname="K. Scott" initials="K." surname="Scott"/>
            <author fullname="S. Burleigh" initials="S." surname="Burleigh"/>
            <date month="November" year="2007"/>
            <abstract>
              <t>This document describes the end-to-end protocol, block formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN).</t>
              <t>This document was produced within the IRTF's Delay Tolerant Networking Research Group (DTNRG) and represents the consensus of all of the active 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 Assignment 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 space and limiting the growth rate of global routing state. This document obsoletes the original Classless Inter-domain Routing (CIDR) spec in RFC 1519, with changes made both to clarify the concepts it introduced and, after more than twelve years, to update the Internet community on the results of deploying the technology 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 internets. 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="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 characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; 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, III"/>
            <author fullname="K. McKeever" initials="K." surname="McKeever"/>
            <date month="January" year="2022"/>
            <abstract>
              <t>This document defines a security protocol providing data integrity 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 Version 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 Delay-Tolerant Networking (DTN). This version of the TCPCL protocol resolves implementation issues in the earlier TCPCL version 3 as defined in RFC 7242 and provides updates to the Bundle Protocol (BP) contents, encodings, and convergence-layer requirements in BP version 7 (BPv7). Specifically, TCPCLv4 uses BPv7 bundles encoded by the Concise Binary Object Representation (CBOR) as its service data unit being transported and provides a reliable transport of such bundles. This TCPCL version also includes security and extensibility mechanisms.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9174"/>
          <seriesInfo name="DOI" value="10.17487/RFC9174"/>
        </reference>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5050.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4632.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1918.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9172.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9174.xml"/>
      </references>
    </references>
    <?line 574?>

<section anchor="text-examples">
      <name>ipn
      <name>'ipn' URI Scheme Text Representation Examples</name>
      <t>This section provides some example ipn URIs in their textual representation.</t>

      <section anchor="using-the-default-allocator">
        <name>Using the Default Allocator</name>

        <t>Consider the ipn URI identifying Service Number 2 on Node Number 1
        allocated by the <xref target="default-allocator">Default Allocator</xref> (0).</t> Default Allocator (0) (<xref target="default-allocator"/>).</t>

        <t>The recommended seven character seven-character representation of this URI would be
        as follows:</t>

        <artwork><![CDATA[
ipn:1.2
]]></artwork>

        <t>The nine character nine-character representation of this URI, with explicit the explicit Allocator Identifier, would be as follows:</t>

        <artwork><![CDATA[
ipn:0.1.2
]]></artwork>

      </section>

      <section anchor="using-a-non-default-allocator">
        <name>Using a non-default Non-Default Allocator</name>
        <t>Consider the ipn URI identifying Service Number 3 on Node Number 1 allocated by Allocator 977000.</t>
        <t>The 14 character 14-character representation of this URI would be as follows:</t>

        <artwork><![CDATA[
ipn:977000.1.3
]]></artwork>

      </section>

      <section anchor="the-null-ipn-uri">
        <name>The Null ipn URI</name>
        <t>The <xref target="null-uri">Null Null ipn URI</xref> URI (<xref target="null-uri"/>) is represented as:</t>

        <artwork><![CDATA[
ipn:0.0
]]></artwork>

      </section>

      <section anchor="a-localnode-ipn-uri">
        <name>A
        <name>The LocalNode ipn URI</name>

        <t>Consider the ipn URI identifying Service Number 7 on the local
        node.</t>

	<t>The recommended seven character seven-character representation of this URI would be
        as follows:</t>

        <artwork><![CDATA[
ipn:!.7
]]></artwork>

        <t>The numeric 16 character 16-character representation of this URI would be as follows:</t>

        <artwork><![CDATA[
ipn:4294967295.7
]]></artwork>

      </section>
    </section>
    <section anchor="cbor-examples">
      <name>ipn
      <name>'ipn' URI Scheme CBOR Encoding Examples</name>
      <t>This section provides some example CBOR encodings of ipn EIDs.</t>
      <section anchor="using-the-default-allocator-1">
        <name>Using the Default Allocator</name>
        <t>Consider the ipn EID <tt>ipn:1.1</tt>. This textual representation
        of an ipn EID identifies Service Number 1 on Node Number 1 allocated
        by the <xref target="default-allocator">Default Allocator</xref> (0).</t> Default Allocator (0) (<xref target="default-allocator"/>).
        </t>
        <t>The recommended five octet five-octet encoding of this EID using the
        two-element scheme-specific encoding would be as follows:</t>
        <artwork><![CDATA[

        <sourcecode type="cbor"><![CDATA[
82       # 2-Element Endpoint Encoding
   02    # uri-code: 2 (IPN ('ipn' URI scheme)
   82    # 2 Element 2-Element ipn EID scheme-specific encoding
      01 # Node Number
      01 # Service Number
]]></artwork>
]]></sourcecode>

        <t>The six octet six-octet encoding of this EID using the three-element
        scheme-specific encoding would be as follows:</t>
        <artwork><![CDATA[

        <sourcecode type="cbor"><![CDATA[
82       # 2-Element Endpoint Encoding
   02    # uri-code: 2 (IPN ('ipn' URI scheme)
   83    # 3 Element 3-Element ipn EID scheme-specific encoding
      00 # Default Allocator
      01 # Node Number
      01 # Service Number
]]></artwork>
]]></sourcecode>
      </section>

      <section anchor="using-a-non-default-allocator-1">
        <name>Using a non-default Non-Default Allocator</name>
        <t>Consider the ipn EID <tt>ipn:977000.1.1</tt>.  This textual
        representation of an ipn EID identifies Service Number 1 on Node
        Number 1 allocated by Allocator 977000.</t>

        <t>The recommended 10 octet 10-octet encoding of this EID using the
        three-element scheme-specific encoding would be as follows:</t>
        <artwork><![CDATA[

        <sourcecode type="cbor"><![CDATA[
82                # 2-Element Endpoint Encoding
   02             # uri-code: 2 (IPN ('ipn' URI scheme)
   83             # 3 Element ipn EID scheme-specific encoding
      1A 000EE868 # Allocator Identifier
      01          # Node Number
      01          # Service Number
]]></artwork>
]]></sourcecode>

        <t>The 13 octet 13-octet encoding of this EID using the two-element
        scheme-specific encoding would be as follows:</t>
        <artwork><![CDATA[

        <sourcecode type="cbor"><![CDATA[
82                        # 2-Element Endpoint Encoding
   02                     # uri-code: 2 (IPN ('ipn' URI scheme)
   82                     # 2 Element 2-Element ipn EID scheme-specific encoding
      1B 000EE86800000001 # Fully-qualified Fully Qualified Node Number
      01                  # Service Number
]]></artwork>
]]></sourcecode>
      </section>

      <section anchor="the-null-endpoint-1">
        <name>The 'null' Null Endpoint</name>
        <t>The 'null' Null EID of <tt>ipn:0.0</tt> can be encoded in the following
        ways:</t>
        <t>The recommended five octet five-octet encoding of the 'null' Null ipn EID using the
        two-element scheme-specific encoding would be as follows:</t>
        <artwork><![CDATA[

        <sourcecode type="cbor"><![CDATA[
82       # 2-Element Endpoint Encoding
   02    # uri-code: 2 (IPN ('ipn' URI scheme)
   82    # 2 Element 2-Element ipn EID scheme-specific encoding
      00 # Node Number
      00 # Service Number
]]></artwork>
]]></sourcecode>

        <t>The six octet six-octet encoding of the 'null' Null ipn EID using the
        three-element scheme-specific encoding would be as follows:</t>
        <artwork><![CDATA[

        <sourcecode type="cbor"><![CDATA[
82       # 2-Element Endpoint Encoding
   02    # uri-code: 2 (IPN ('ipn' URI scheme)
   83    # 3 Element 3-Element ipn EID scheme-specific encoding
      00 # Default Allocator
      00 # Node Number
      00 # Service Number
]]></artwork>
]]></sourcecode>

      </section>
    </section>

    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>The following DTNWG DTN Working Group participants contributed technical material, use
      cases, and critical technical review reviews for this URI scheme update: Scott Burleigh
      <contact fullname="Scott Burleigh"/> of the IPNGROUP, Keith Scott, Brian Sipos <contact
      fullname="Keith Scott"/>, <contact fullname="Brian Sipos"/> of the Johns
      Hopkins University Applied Physics Laboratory, Jorge Amodio <contact fullname="Jorge
      Amodio"/> of LJCV Electronics, and Ran Atkinson.</t> <contact fullname="Ran
      Atkinson"/>.</t>
      <t>Additionally, the authors wish to thank members of the CCSDS SIS-DTN working group
      Working Group at large who provided useful review reviews and commentary on this
      document and its implications for the future of networked space
      exploration.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+V9a3MbybXYd/yKNpREpAuACJKrB22tTYrULh2tpCtS3nJU
G3MADMixBjPwzIAUVivX/SFJVX5Lfsr9JTnPfsyDBNdrJ7l3q2wRwEz36dOn
z/ucHg6HvSqp0vjA9N8vZ1EVmyo31VVskmVm3r87NeX0Kl7E/V40mRTxNTwG
PwxX9Gi/N4X/v8yL9YEpq1mvN8unWbSAsWZFNK+GSVzNh7MqG7pXhuP9Xrma
LJKyTPKsWi/h4dOT85e9bLWYxMVBDx866E3zrIyzclUemKpYxT2Yd68XFXEE
858XUVYu86Lq927y4uNlka+W8PVxnEbrR8dJWayWFYxtzvM0hkcr8zqu8MEk
u+z3PsZr+Ht20DNDc3z+Gv8B4PCfo7fXT/DfF0ffntDnVTZLY/O2yKt8mqe9
3nWcrQA0Y+43ozG8yv73/I35Bl/H7xdRksL3gKDfI6ZGeUGPR8X0Cr6+qqpl
efDoET6FXyXX8Ugfe4RfPJoU+U0ZP4L3H+F7l0l1tZrAm0Uy/VhF6zQvHsHa
dvG3FLBaVt6o7pkRvzdKcnr6EW8d/1bbvNFVtUj7vR5/KgmJz8ZPxvjvk/H4
Mf77ePfxTi9aVVd5gb/D3MbMV2nKdPEOpjXnNDb9AmuJsuTHCNF3YA6jdF0k
kTmPp1dZnuaXSVzSYzGjqmCofh/xc6NpvmhOcTIzR0kB2xC3zPCHb98/Onz7
yh/0ZHYTFbORvPP7v1ytomU6imerXi/LiwW8eA27nmRz96E3HA5NNCmrIppW
vd75VVIaIP3VIoa9F+TQGSqX8TSZJ1Oa3eTzloNllnCqknxVpmszi+dJFs9M
kpl3L18QKgf0yunh60NTxJcJTAk4MbCX0SRNyiv3MOJ/YKJsRi8UqxQeA5Dp
U5xN8xmSHv48i+UDg1PGCExpbq7izKxKGDAq4Tlzks2WeQLrOZ3BqmARcWG2
Tk6Pt3HC2tkwf4wLPM7midnCY7SNY9QWg3QyMuc0oaJoCoSdzNeMKjjn02pV
xATkJL6KACtFO84GMrjJ4hu7uBKfxecEr7gqRojFFqPGoTGLp3FZRsUaed4i
yqJL4H64mTzEiDd6kcxgsb3eA3OaVUU+AzBhrbjtjb28gXXnRXKZZFEa7ufn
z78CLOCOfvlCQPEXuGv4BaAcXiY4Esb3GqAjJmKyfBaX9A7+Zcq4uE4Abtgs
3EXglNOkjNP1kBBBswFPhg2BpUSVmcJeTpDKclwr/DyPygr2Ese7gZNv5vEN
fCziMl8VU6JbeCMHTBXmOi4mOexX4kiAF1rSTvqrBhCTS1wr0hyQEY9NxPdp
GRcJHo0obRDOtRDOYyIcIODPn38HaPlq5yvA0zYBefr2tczAyGTyjKZFnq0X
lsRhSQvThw2Ki7cpnOMKd1XYcB83oIjncQEoIvmWVCWhKUN8IbQ4zCyOl8Ny
GU1jRT3gd2TOEnoJjgefxXgOBzqBkdaA1wyAqojwGOkeqkqgqI+AzxpJ4nTA
rGjGKLO7DHQDaAI+AVtKqEuTRVIBdMsctmdgJoCKm2RWXRFJP4KXgfktVyCu
J6vZZVzRhsAa8yIeOIQg7oCcs/zGHW34lA0FfcB2DHJNoPQzmA+Oo0r/cNdo
a/iUwuzALpMfYbSuzRQuMBAax5OPm4nHdI7HrlwtUXzbvcMNaOeN+kSDj054
6hYmVRKXKreZQpcrOPjuNQTLXAEWgNxXacVHUxCfw5kFGlim+RqXXdrn+fwh
KJMcaTou4G1gIPA4H8ps6H+Hq5lGJZ+RBOlsmq5wBB6sud054E23zI5ClAwP
0xRdbwLwcPLnQ+ABVUSHI86uE9hZXgAw0QTejkx5BaoT/DFbJBnyPhJjILFA
AGaMJ1BpbmBtMCACwroYTV1Oo5R2pw0ziMlJHONpRGoEOQuzTNYwYzjeqkTO
2r7FN1fJ9IpGukour1L4H24LqnolndQFcK7rOBQRA7OAPeFNYxbPzJvkL03j
8/CjNQscxNjnzx7TJS5sCXTAr/1cOT7AxUZwTqcfUZ8oh4SRKpmkyCDXA1wM
LgUYBGxlTIya1yablTt8CWqAS8HuEpzIsBiLMAxDszZI58wscDeAUymUIHvq
q0lEdKEkAUwD8lClhEc9waunLSqRlysyGyKVpXYiqLGSmsBEqgWFprKIarzN
bLy0bLTaQIDLVjzSd2tiHODNp0lUifQJd/8wBVV0dXkVyuXrOIVjRMSKgyHr
N8z6YdsWqyyp1qEkq/G6QRsp47QrXRZMcwniAfRs3LJJzAw4UdEaHNQbZN2w
LyLLDcz/1xUuEVBZIgtWbEZWTpscqW0ZFVUyXSHfJt0gQc7211UCpx2Wflrh
F0BlwGzRKgE4CoCTzjbqBgMQMh9jOEtlJVC5xZStK9QNiBRETzMIwON9m+Wo
ZOWV8kASeFW+JNUeac9q1bAaYJHTIpngKb0CeYXA5ijfFqiiXcYlSybQaHSO
EapkL/LsGkEAe5GmPEYIE/rMGhoYfAYtvtL0v3t/dt4f8L/m9Rv6+93Jv7w/
fXdyjH+ffXv46pX9oydPnH375v2rY/eXe/PFm+++O3l9zC/Dtyb4qtf/7vBP
fUZE/83b89M3rw9f9fmI+ycTWJ1QiD09JKl7ghCmmqMXb//3/xrvi0jdHY+f
AQfjD0/HT/bhww1pKDhbngHx3ajCsu5Fy2UMFIL8KU1BNi0TEOp4tIBeAdWZ
QfIDbP76A2LmhwPz28l0Od7/Wr7ABQdfKs6CLwlnzW8aLzMSW75qmcZiM/i+
hukQ3sM/BZ8V796Xv/1diqbDcPz0d1/3er2XwvQKNAdBHyysANEd8vSpvpyH
Ph4sOtB0puYx6U0RHRWiUfittAfI8iIkV9htoNlpvKyAQE9A9K/1kA3gqIAg
q1A7h92jA5nQEQZlrGDl3WrVVfypWsEJqvOIAmUQsDkYVvnqwNAuTpC3ZSWc
2EI1wWq1TK1cnudpmt/g8auuipgY4TLPkD+Bwftr0hIO4QmQgTCJ07fkp9fI
fl6T3iDfnLGdol/2ugYAupyhZBWE4dfAfGFRS4QWxSepyiSTEDpvJtYQ4HWQ
qowMYY6ksg3QwUKKEb7GDAuYF7LbJAWWF13nyYzXyyKZJzJoVqVWwLAcwIPD
IMBjPgQgdQFXH9oWVv6w9SDS74eeYbA9Ymx44+AuWz3NY6p2TiQvgEFIhdVR
Z7NN8yHNE89YLsgSEA0CoA8zwIW/DFnNs+CEG0YQZT4sAMIMMAJDr9CWnoA+
irqfg4KmvgTVMvNnDofFycWCrc8PBIeU66lYZdygRXO5itDFFsdi38Z0hKY5
qM5TFLpI46TRICJFevHew492NaW/zyJOjDmczRI2BFiBaoOpnYbV7+JvqWh7
ONUinoJVnZQLRGIdGlZBSH7DLKwPB6LdkjWzgpjWBgPFn2A7BMsvVwDz8K9w
ChCggEYB4/O/Zhmi+cEDPqwrR0rm84MMPg5XRfKFVAar1M/zFa0KkFyRggLT
X0cpSv2MNQFyKakq8BCHeWiHlZOJRGn6YIDiCH3AMdtE8hD8iXw1ZuT1fbhE
ciI0SPgNntS6DwN/3TxASH4DMJgqtXF5MT/GRW62dsBghJc9XOugpCQGGCO8
i2qKGg3scaVEEr5Wrmgv/Q2s1EzH32dWWwEsgskDVAIMjzeqlaWAPpt5v9AZ
XQc+Tt6wG/QNEntkDhJyzYaPpm7KKOZJLkTTJAUYxQd1ieZqFokjRZxmkRja
jmmiNtjOL5EA2T9sIbZQ8pkXvoCrkzOE9FGQFt+0T6Ks/UgCetFtCtv6Lr4E
iyxF1g/Ps6YLYhZ0qxVKndoYA9k1cpVEiA12McBjZGdPQSFAxyTLZznCbI1b
ZXbghitJwQvJonVrD+xRGsC/gjpxKw3UMgTWB+jeQZTt/ve93eF4dItgVbFP
JmWexh4bUt0lYEFuEKIhOnpW/tTlVUbSgelmZAKqXERreBmM9sUqrRJUMeww
rSsfGNgIKzq6l0J67ST27T2iYMvK7ato95FzmBzn/YcA50NzZs3KdjD6jnoT
526cW/3wUlwnLAo6VlIiM95sPjsdMOgEztGwQ1kAuaQ2LDlTnCLTBYZvB5Kg
QMqc1l9VXQKAzhdx4LlEkgVJAyc6QZmKGmZxLcjwPIOqcs5X5D8AogLEnwAX
88DirS9DBoT+ooJ1L3bGohUCZiGazgAP7irYfqZIyo907oA1Vhy/EDDJeFS1
GegUQFokVeUseg6AyKm5VfuBLZs6+e7p/YD4N3TIySOO0ciCtcWoIq4brAgU
ddm+mNEnUjFa5NllST82X2DUDEIWZo1mUkkBP9OccIWCFFEl05DFS+TPnMgx
HLT80RYv12UVL9x4QhFsZpITEZVr59drdb+g35tx+LZIrhGG92XACRCfS/5p
CASwzSxq4GhGNuQDWOYR8AMHKLw44+8c5W87D85yVSzzEoWRNZCRa5FwbJeO
5h1ODTLyDOnZF4qCKVo5unmtAywuiVvdUHAI9Ns4BVlRMct0iEbM1M0OUEOQ
9BcoyVkzTAqQHJNhMC9Kn8gRkbNihDzajy8eWTxF9eFYw54nRVmhezGWPxXR
UZnwjqEzCcHyHNsSqqAj4aDonJ5FYBZqFuTgtO7CGQWsylwPBDAGwW4+IYgK
ij3N4grOlzzEofNuvkVQe1OSt86x+1FN/fG2ngUjW1GxCms42StydXfMVpMj
JCdB4ntyxBA380zMDgvWSi+GQzwakzg04MR+AnQ0d7ZmXIBItbvkc2Z1HyHu
kUBvyibexZnMahWv8K4llDVJGsBGxk0ugSt0nyZziqVVNLJyuCbts2qyxCA5
auCsEhI8bDj4O8R4g0dU+bsFHgqqlEuSbsJdXqQwNGl4FDgZcmzDvAMpQnMF
GqONrYC9R36V0gS+No5B7j/e2/3yZQRPC/G6MZyaHAK2ZTXHzE2iBshbVmWB
xSWeXhXZMO8SzILkE588nhB9DhZC9A1Y8UNUKi/gmfEcO8wpm6QNb/mwNgV1
22EK1VayBpDjdJ4Cp6KqQSyhpNp5bFC0vEb++i6ASiE8My/yhXlxevzOQw+O
cpN7zm44IEiB49EtrKahBYcyg+y7Ak1z9gEuyji9Rv3ETjvqHh/FCmwE0STx
/r1dMxEGnMbZZXWFchoJaKa+Ff9UqXflNnRwAoALpMDwNxg+sHwfQQUiksfV
HCBHfZn8CGyK6YK4JsWZ8bddNv/YF+YzNfiNATevaSWsp8Egz8EWec3+kjSO
UCAh48JAFKZC8arVydhNPgoeQrzDnD7+FC08D6XEiW9DCUI9B1u7tpNbhwNz
NDAveGnHcgTF5Yn+zZ/MG/8g/8SqhNmaxdNt9+kq/rRt7MdXjIytI1gfPNT7
6WCI/xn5Tz4OD1o+0ceDn3hac2hfMc+e7D/df2pGI/zr2ZOv4KudTycnOzs7
+B39+eQlfPmEsSqvyThHwTjPnjzWcZ6NdZynbpynOM5+2zgvwnGe7dpx9nSc
Z24cGnyM45jaOMe1cfbt27v4lz81vPP5wDyooskwSoqhbnyUAiU976fxvOob
SlN83u/W/ERkEos+4RH6X3q970W2l77ngLTudkvc3Fxh0guGxQJK3v2KIQYT
HxinbsskTnO2YwJRcIiJI5RRga7Ee0/1tDHV086pjpwn6j5z7I15DuRwuqcd
M7xAU8j/4pidAw27O3DFkROJMm4ix0FgyqFwkR1R5VFJaBgH5nPTOIC9PLSc
pJbZ4QX2mRORsyBYhbMRO9xiN+LxcvqB9WDJE4fst6rWZgs9C9vqrW3zdJnr
JHLJe31MKw1+d+4GSRRZxFFWOtFvXf1k/WImUIFhdvFdRuKqvl2XBsBWC14w
OWR8D45vR3KmWA4nZu1U4bvhVgUvhlmW1vmI7it2tqEpQhJJ8ifi2aDmByis
mcUqBs1J8j2ySReBW4ZcbCmlH6kqvLolbZmdrLg7rHTS+LLNDZpjkp2sPQOp
0+GvXmPrYvhFfT66mAaIcBBPMzrqmGKkiQOZsbl/snpr9HteHBeE7zywqD+l
sfPtkExmIrKBgICIXAaQv4vtoN/hk2uygHaq851z5B3BzJb0LoudfP1lN3AS
mED43EQZoDfhRCrKcWGVkNz/oVVRMs1udGqYysQ9UrLvTdItGcYwd5aIizJ7
orTudyn562G7PwuZ+Q3HEgJUfA78X8hUQ8+uHyOjqBR7g0F+lEEsI5MIWYax
6LoXHdTiRnwza/i18SmRIQFrUn5KuWQNIUNU6UXd/WgnGRAtg4nMn5DV7DnL
XHD8Fg87J9J4OQeMEn8Wyw/w0Pl2P87oHziEGAPPiLj5ivIlLcf94IeZ0E8p
gbltkZS3BPlwWzHKB9v5JrMaczS7BlFP2TOew1fCUCaaYGBnze6mMgEWUQKz
4EPOVFBxIMcPRkrw1hE8kchqaUOX5EWRhzhSBofrJTmORanTlB7Yw2mckF8Z
B0OPmjeRsjI0pNR1GWlegHoEMfNBXStiPtnJ88x5dBwd8xuoIEg+mEIDUH4L
0MLXlEDnYUHTm3hlGfmtaUDL/aZoSACI9CJRZqFqBkc26XE+cX10G/IXbvg+
ylKlDHGnWwIZcHI+jytO8yZ0zWwwl7ZyC+H0zdbLf3n9etueg0ZaS0cc3Kd+
G5cl3tYqMN0jzClsnJjSZVoD9LX1sOxjVkkZXSSxEHgl6I6ktCZekA44Cbl0
+fShs0MPC1vpnBJN9Ot8cC5BCIFgbeamQBUTfaxgdN4Vod4emHh0ORqYi61n
T56ANTEY7+xsX+hyaGlshxPcbWqmGaMNUuMxxFBad4GnYaHQJlTEd66ChZSM
hsam0qlLmHZFwW6X8A3VqJ6jorbCf0NW6+cb9dotCI08ea6DVo6NodGU03z8
cO5dDLmhs2eWaNR5aafozBnxngkyFzggiqnl9HstNcedJXKFgt6QzOB0nKHr
0DJ5Td3jxK8FxlJmrHtILQjqM4CTsvmWuhPJ6aU8zEeF7MYrWFRKcNv3QQzh
UlPaPM4pad8dqwD5e8ISF9Dx6aX+t+1nPAe5RuRvwrnodAxAcrtAS85KsjUh
PPe3qAm/0Pb50KPzjBdAvLMU7SQURwyx1C8wWyNQ0LDxhLSXGhOZfgPRfdmB
rqAcbIMXlOvcBC9FyVroYaCLUFPEYQi4703bH9QUVk1K3QVTnNx4fzdeu+fm
4pbKJYWp/1skwSRe51wBwSpiRwUEpi+0/kRrI4GIhtbANz3kVEiwiWtEWLBc
kVVrA8CBTcKCwupO4WLYBW6kSI4flfKthoN/vsqmNkJWutodO6LENoDLR1MY
+/Tt9b7zWzf3DCMe42fjp7RnR/E0skU5sOY0mlIc3uUPsEurZi2ysNVqIPZO
W8agqdtEbnIWJuz8Vl936xYISyL3RblKKgpa20QWEsbLNOJsJCylRK7oYMi4
cAIhIT4XIrwe050WeVlacJxG2Q6YSNEwvREOXi29kQys1tzKujUk3vgOFcjy
EVc4lIlmgBRsf1fthGR3IgamJtwr2eh2kFpd2hSMZvZbI+0T7APW1onZ6nhl
CFagd1Pi87nkK79r1DQohbDlVq+W851STKV7z56Sk0+jMy6hzuZCS/KdVGXU
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

-->

</rfc>