<?xml version="1.0" encoding="utf-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.9 (Ruby 2.6.10) --> encoding="UTF-8"?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.9 (Ruby 2.6.10) -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-drip-arch-31" category="info" number="9434" submissionType="IETF" category="info" consensus="true" tocInclude="true" sortRefs="true" symRefs="true"> symRefs="true" updates="" obsoletes="" xml:lang="en" version="3">

  <!-- xml2rfc v2v3 conversion 3.16.0 -->
  <front>
    <title abbrev="DRIP Architecture">Drone Remote Identification Protocol (DRIP) Architecture</title>
    <seriesInfo name="RFC" value="9434"/>
    <author initials="S." surname="Card" fullname="Stuart W. Card">
      <organization>AX Enterprize</organization>
      <address>
        <postal>
          <street>4947 Commercial Drive</street>
          <city>Yorkville, NY</city>
          <city>Yorkville</city>
	  <region>NY</region>
          <code>13495</code>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>stu.card@axenterprize.com</email>
      </address>
    </author>
    <author initials="A." surname="Wiethuechter" fullname="Adam Wiethuechter">
      <organization>AX Enterprize</organization>
      <address>
        <postal>
          <street>4947 Commercial Drive</street>
          <city>Yorkville, NY</city>
          <city>Yorkville</city>
	  <region>NY</region>
          <code>13495</code>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>adam.wiethuechter@axenterprize.com</email>
      </address>
    </author>
    <author initials="R." surname="Moskowitz" fullname="Robert Moskowitz">
      <organization>HTT Consulting</organization>
      <address>
        <postal>
          <street></street>
          <street/>
          <city>Oak Park, MI</city> Park</city>
	  <region>MI</region>
          <code>48237</code>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>rgm@labs.htt-consult.com</email>
      </address>
    </author>
    <author initials="S." surname="Zhao (Editor)" surname="Zhao" fullname="Shuai Zhao"> Zhao" role="editor">
      <organization>Intel</organization>
      <address>
        <postal>
          <street>2200 Mission College Blvd</street> Blvd.</street>
          <city>Santa Clara</city>
          <code>95054</code>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>shuai.zhao@ieee.org</email>
      </address>
    </author>
    <author initials="A." surname="Gurtov" fullname="Andrei Gurtov">
      <organization>Linköping University</organization>
      <address>
        <postal>
          <street>IDA</street>
          <city>Linköping</city>
          <code>SE-58183 Linköping</code>
          <code>58183</code>
          <country>Sweden</country>
        </postal>
        <email>gurtov@acm.org</email>
      </address>
    </author>
    <date year="2023" month="March" day="05"/>

    <area>INT</area> month="July"/>
    <area>int</area>
    <workgroup>drip</workgroup>
    <keyword>Internet-Draft</keyword>
    <keyword>UAS</keyword>
    <keyword>RID</keyword>
    <keyword>F3411</keyword>
    <keyword>DRIP</keyword>
    <keyword>drone</keyword>
    <abstract>
      <t>This document describes an architecture for protocols and services to
  support Unmanned Aircraft System (UAS) Remote Identification (RID) and tracking, tracking
  (UAS RID), plus UAS RID-related UAS-RID-related communications. This architecture adheres to the requirements listed in the DRIP Drone Remote Identification Protocol (DRIP) Requirements document (RFC 9153).</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction"><name>Introduction</name> anchor="introduction">
      <name>Introduction</name>
      <t>This document describes an architecture for protocols and services to
  support Unmanned Aircraft System (UAS) Remote Identification (RID) and tracking, tracking
  (UAS RID), plus RID-related UAS-RID-related communications. The architecture takes into account both current (including proposed) regulations and non-IETF technical standards.</t>
      <t>The architecture adheres to the requirements listed in the DRIP Requirements document <xref target="RFC9153"/> and illustrates how all of them can be met, except for GEN-7 QoS, which is left for future work. The requirements document provides an extended introduction to the problem space and use cases. Further, this architecture document frames the DRIP Entity Tag (DET) <xref target="I-D.ietf-drip-rid"/> target="RFC9374"/> within the architecture.</t>
      <section anchor="overview-of-uas-rid-and-its-standardization"><name>Overview anchor="overview-of-uas-rid-and-its-standardization">
        <name>Overview of UAS RID and its Its Standardization</name>
        <t>UAS RID is an application that enables UAS to be identified by UAS Traffic Management (UTM) and (UTM), UAS Service Suppliers (USS) (<xref target="appendix-a"/>) target="appendix-a"/>), and third party entities third-party entities, such as law enforcement. Many considerations (e.g., safety and security) dictate that UAS be remotely identifiable.</t>
        <t>Civil Aviation Authorities (CAAs) worldwide are mandating UAS RID. CAAs currently promulgate performance-based regulations that do not specify techniques, techniques but rather cite industry consensus technical standards as acceptable means of compliance.</t>

<t>USA
	<dl newline="true" spacing="normal">
        <dt>USA Federal Aviation Administration (FAA)</t>

<ul empty="true"><li>
  <t>The (FAA)</dt>
        <dd>The FAA published a Notice of Proposed Rule Making <xref target="NPRM"/> in 2019  and thereafter published a "Final Rule" in 2021 <xref target="FAA_RID"/>, imposing requirements on UAS manufacturers and operators, both commercial and recreational. The rule  states that Automatic Dependent Surveillance Broadcast (ADS-B) Out and transponders cannot be used to satisfy the UAS RID requirements on UAS to which the rule applies (see <xref target="adsb"/>).</t>
</li></ul>

<t>European target="adsb"/>).
          </dd>
        <dt>European Union Aviation Safety Agency (EASA)</t>

<ul empty="true"><li>
  <t>In (EASA)</dt>
        <dd>In pursuit of the "U-space" concept of a single European airspace safely shared by manned and unmanned aircraft, the EASA published a <xref target="Delegated"/> regulation in 2019 2019, imposing requirements on UAS manufacturers and third-country operators, including but not limited to UAS RID requirements. The same year, the EASA also published an <xref target="Implementing"/> a regulation <xref target="Implementing"/>, laying down detailed rules and procedures for UAS operations and operating personnel, which then was updated in 2021 <xref target="Implementing_update"/>. A Notice of Proposed Amendment <xref target="NPA"/> was published in 2021 to provide more information about the development of acceptable means of compliance and guidance material to support U-space regulations.</t>
</li></ul>

<t>American regulations.</dd>
        <dt>American Society for Testing and Materials (ASTM)</t>

<ul empty="true"><li>
  <t>ASTM (ASTM)</dt>
        <dd><t>ASTM International, Technical Committee F38 (UAS), Subcommittee F38.02 (Aircraft Operations), Work Item WK65041, WK65041 developed the an ASTM standard <xref target="F3411-22a"/> Standard target="F3411-22a"/>, titled "Standard Specification for Remote ID and Tracking.</t>
</li></ul>

<ul empty="true"><li> Tracking".</t>
        <t>ASTM defines one set of UAS RID information and two means, MAC-layer Media Access Control (MAC) layer broadcast and IP-layer IP layer network, of communicating it. If an a UAS uses both communication methods, the same information must be provided via both means. <xref target="F3411-22a"/> is the technical standard basis of the <xref target="F3586-22"/> "Means Means Of Compliance" Compliance (MOC) accepted by the specified in <xref target="F3586-22"/>. The FAA as per has accepted <xref target="MOC-NOA"/> target="F3586-22"/> as a MOC to the FAA's UAS RID final rule Final Rule <xref target="FAA_RID"/> and is target="FAA_RID"/>, with some caveats, as per <xref target="MOC-NOA"/>. Other CAAs are expected to be accepted by some accept the same or other CAAs.</t>
</li></ul>

<t>The 3rd MOCs likewise based on <xref target="F3411-22a"/>.</t>
          </dd>
        <dt>3rd Generation Partnership Project (3GPP)</t>

<ul empty="true"><li>
  <t>With (3GPP)</dt>
        <dd>With Release 16, the 3GPP completed the UAS RID requirement study <xref target="TS-22.825"/> target="TR-22.825"/> and proposed a set of use cases in the mobile network and services that can be offered based on UAS RID.  The Release 17 study <xref target="TR-23.755"/> and specification <xref target="TS-23.255"/> focus on enhanced UAS service requirements and provides provide the protocol and application architecture support that will be applicable for both 4G and 5G networks. The study of Further Architecture Enhancement for Uncrewed Aerial Vehicles (UAV) and Urban Air Mobility (UAM) <xref target="FS_AEUA"/> in Release 18 <xref target="FS_AEUA"/> further enhances the communication mechanism between UAS and USS/UTM. The DRIP Entity Tag DET in <xref target="rid"/> may be used as the 3GPP CAA-level UAS ID for Remote Identification purposes.</t>
</li></ul> RID purposes.</dd>
        </dl>
      </section>
      <section anchor="overview-of-types-of-uas-remote-id"><name>Overview anchor="overview-of-types-of-uas-remote-id">
        <name>Overview of Types of UAS Remote ID</name>
        <t>This specification introduces two types of UAS Remote ID IDs as defined in ASTM <xref target="F3411-22a"/>.</t>
        <section anchor="brid"><name>Broadcast anchor="brid">
          <name>Broadcast RID</name>
          <t><xref target="F3411-22a"/> defines a set of UAS RID messages for direct, one-way, one-way broadcast transmissions from the UA Unmanned Aircraft (UA) over Bluetooth or Wi-Fi.  These are currently defined as MAC-Layer MAC layer messages. Internet (or other Wide Area Network) connectivity is only needed for UAS registry information lookup by Observers using the directly received UAS ID.  Broadcast RID should be functionally usable in situations with no Internet connectivity.</t>
          <t>The minimum Broadcast RID data flow is illustrated in <xref target="brid-fig"/>.</t>
          <figure anchor="brid-fig"><artwork><![CDATA[ anchor="brid-fig">
	    <name>Minimum Broadcast RID Data Flow</name>
            <artwork><![CDATA[
                +------------------------+
                | Unmanned Aircraft (UA) |
                +-----------o------------+
                            |
                            | app messages directly over
                            | one-way RF data link (no IP)
                            |
                            v
          +------------------o-------------------+
          | Observer's device (e.g., smartphone) |
          +--------------------------------------+
]]></artwork></figure>
]]></artwork>
          </figure>
          <t>Broadcast RID provides information only about unmanned aircraft (UA) UA within direct Radio Frequency (RF) Line-Of-Sight Line Of Sight (LOS), typically similar to Visual LOS (VLOS), with a range up to approximately 1 km.  This information may be 'harvested' from received broadcasts and made available via the Internet, enabling surveillance of areas too large for local direct visual observation or direct RF link-based ID identification (see <xref target="harvestbridforutm"/>).</t>
        </section>
        <section anchor="nrid"><name>Network anchor="nrid">
          <name>Network RID</name>
          <t><xref target="F3411-22a"/>, using the same data dictionary that is the basis of Broadcast RID messages, defines a Network Remote Identification (Net-RID) data flow as follows.</t>

<t><list style="symbols">
  <t>The
          <ul spacing="normal">
            <li>The information to be reported via UAS RID is generated by the UAS. Typically Typically, some of this data is generated by the UA and some by the GCS (Ground Ground Control Station), Station (GCS), e.g., their respective locations derived from the Global Navigation Satellite System (GNSS) derived locations.</t>
  <t>The (GNSS).</li>
            <li>The information is sent by the UAS (UA or GCS) via unspecified means to the cognizant Network Remote Identification Service Provider (Net-RID SP), typically the USS under which the UAS is operating if it is participating in UTM.</t>
  <t>The UTM.</li>
            <li>The Net-RID SP publishes publishes, via the Discovery and Synchronization Service (DSS) over the Internet Internet, that it has operations in various 4-D airspace volumes (Section 2.2 of <xref target="RFC9153"/>), (<xref target="RFC9153" section="2.2" sectionFormat="of" />), describing the volumes but not the operations.</t>
  <t>An operations.</li>
            <li>An Observer's device, which is expected, expected but not specified, specified to be web-based, based on the Web, queries a Network Remote Identification Display Provider (Net-RID DP),
typically also a USS, about any operations in a specific 4-D airspace volume.</t>
  <t>Using volume.</li>
            <li>Using fully specified web-based Web-based methods over the Internet, the Net-RID DP queries all Net-RID SPs that have operations in volumes intersecting that of the Observer's query for details on all such operations.</t>
  <t>The operations.</li>
            <li>The Net-RID DP aggregates information received from all such Net-RID SPs and responds to the Observer's query.</t>
</list></t> query.</li>
          </ul>
          <t>The minimum Net-RID data flow is illustrated in <xref target="nrid-fig"/>:</t>
          <figure anchor="nrid-fig"><artwork><![CDATA[ anchor="nrid-fig">
	    <name>Minimum Net-RID Data Flow</name>
            <artwork><![CDATA[
 +-------------+     ******************
 |     UA      |     *    Internet    *
 +--o-------o--+     *                *
    |       |        *                *     +------------+
    |       '--------*--(+)-----------*-----o            |
    |                *   |            *     |            |
    |       .--------*--(+)-----------*-----o Net-RID SP |
    |       |        *                *     |            |
    |       |        *         .------*-----o            |
    |       |        *         |      *     +------------+
    |       |        *         |      *
    |       |        *         |      *     +------------+
    |       |        *         '------*-----o            |
    |       |        *                *     | Net-RID DP |
    |       |        *         .------*-----o            |
    |       |        *         |      *     +------------+
    |       |        *         |      *
    |       |        *         |      *     +------------+
 +--o-------o--+     *         '------*-----o Observer's |
 |     GCS     |     *                *     | Device     |
 +-------------+     ******************     +------------+
]]></artwork></figure>
]]></artwork>
          </figure>
          <t>Command and Control (C2) must flow from the GCS to the UA via some path. Currently (in the year 2022) 2023), this is typically a direct RF link; however, with increasing Beyond Visual Line of Of Sight (BVLOS) operations, it is expected often to often be a wireless link at either end with the Internet between.</t>
          <t>Telemetry (at least the UA's position and heading) flows from the UA to the GCS via some path, typically the reverse of the C2 path. Thus, UAS RID information pertaining to both the GCS and the UA can be sent, sent by whichever has Internet connectivity, connectivity to the Net-RID SP, typically the USS managing the UAS operation.</t>
          <t>The Net-RID SP forwards UAS RID information via the Internet to subscribed Net-RID DPs, typically the USS. Subscribed Net-RID DPs then forward RID information via the Internet to subscribed Observer devices. Regulations require and <xref target="F3411-22a"/> describes UAS RID data elements that must be transported end-to-end end to end from the UAS to the subscribed Observer devices.</t>
          <t><xref target="F3411-22a"/> prescribes the protocols between the Net-RID SP, Net-RID DP, and the DSS.  It also prescribes data elements (in JSON) between the Observer and the Net-RID DP. DRIP could address standardization of secure protocols between the UA and the GCS (over direct wireless and Internet connection), between the UAS and the Net-RID SP, and/or between the Net-RID DP and Observer devices.</t>

<ul empty="true"><li>
  <ul empty="true"><li>
    <t>Informative note: Neither link layer
                  <t><em>Neither link-layer protocols nor the use of links (e.g., the link often existing between the GCS and the UA) for any purpose other than carriage of UAS RID information is are in the scope of <xref target="F3411-22a"/> Network RID.</t>
  </li></ul>
</li></ul> RID <xref target="F3411-22a"/>.</em></t>
        </section>
      </section>
      <section anchor="overview-of-uss-interoperability"><name>Overview anchor="overview-of-uss-interoperability">
        <name>Overview of USS Interoperability</name>
        <t>With Net-RID, there is direct communication between each UAS and its USS. Multiple USS exchange information with the assistance of a DSS so all USS collectively have knowledge about all activities in a 4D 4-D airspace.  The interactions among an Observer, multiple UAS, and their USS are shown in <xref target="inter-uss"/>.</t>
        <figure anchor="inter-uss"><artwork><![CDATA[ anchor="inter-uss">
	  <name>Interactions Between Observers, UAS, and USS</name>
          <artwork><![CDATA[
                +------+    +----------+    +------+
                | UAS1 |    | Observer |    | UAS2 |
                +---o--+    +-----o----+    +--o---+
                    |             |            |
              ******|*************|************|******
              *     |             |            |     *
              *     |         +---o--+         |     *
              *     |  .------o USS3 o------.  |     *
              *     |  |      +--o---+      |  |     *
              *     |  |         |          |  |     *
              *   +-o--o-+    +--o--+     +-o--o-+   *
              *   |      o----o DSS o-----o      |   *
              *   | USS1 |    +-----+     | USS2 |   *
              *   |      o----------------o      |   *
              *   +------+                +------+   *
              *                                      *
              *               Internet               *
              ****************************************
]]></artwork></figure>
]]></artwork>
        </figure>
      </section>
      <section anchor="overview-of-drip-architecture"><name>Overview anchor="overview-of-drip-architecture">
        <name>Overview of DRIP Architecture</name>
        <t><xref target="arch-intro"/> illustrates a global UAS RID usage scenario. Broadcast RID links are not shown shown, as they reach from any UA to any listening receiver in range and thus would obscure the intent of the figure. <xref target="arch-intro"/> shows, as context, some entities and interfaces beyond the scope of DRIP (as currently (2022) (2023) chartered). Multiple UAS are shown, each with its own UA controlled by its own GCS, potentially using the same or different USS, with the UA potentially communicating directly with each other (V2V) (V2V), especially for low latency safety related low-latency, safety-related purposes (DAA).</t>
        <figure anchor="arch-intro"><artwork><![CDATA[ anchor="arch-intro">
	  <name>Global UAS RID Usage Scenario</name>
          <artwork><![CDATA[
***************                                        ***************
*    UAS1     *                                        *     UAS2    *
*             *                                        *             *
* +--------+  *                 DAA/V2V                *  +--------+ *
* |   UA   o--*----------------------------------------*--o   UA   | *
* +--o--o--+  *                                        *  +--o--o--+ *
*    |  |     *   +------+      Lookups     +------+   *     |  |    *
*    |  |     *   | GPOD o------.    .------o PSOD |   *     |  |    *
*    |  |     *   +------+      |    |      +------+   *     |  |    *
*    |  |     *                 |    |                 *     |  |    *
* C2 |  |     *     V2I      ************     V2I      *     |  | C2 *
*    |  '-----*--------------*          *--------------*-----'  |    *
*    |        *              *          *              *        |    *
*    |        o====Net-RID===*          *====Net-RID===o        |    *
* +--o--+     *              * Internet *              *     +--o--+ *
* | GCS o-----*--------------*          *--------------*-----o GCS | *
* +-----+     * Registration *          * Registration *     +-----+ *
*             * (and UTM)    *          * (and UTM)    *             *
***************              ************              ***************
                               |  |  |
                +----------+   |  |  |   +----------+
                | Public   o---'  |  '---o Private  |
                | Registry |      |      | Registry |
                +----------+      |      +----------+
                               +--o--+
                               | DNS |
                               +-----+

DAA:  Detect And Avoid
GPOD: General Public Observer Device
PSOD: Public Safety Observer Device
V2I:  Vehicle-to-Infrastructure
V2V:  Vehicle-to-Vehicle
]]></artwork></figure>

<ul empty="true"><li>
]]></artwork>
        </figure>
	<aside>
            <t>Informative note: see See <xref target="RFC9153"/> for detailed definitions.</t>
</li></ul>
          </aside>
        <t>DRIP is meant to leverage existing Internet resources (standard protocols, services, infrastructures, and business models) to meet UAS RID and closely related needs.  DRIP will specify how to apply IETF standards, complementing <xref target="F3411-22a"/> and other external standards, to satisfy UAS RID requirements.</t>
        <t>This document outlines the DRIP architecture in the context of the UAS RID architecture.  This includes closing the gaps between the CAAs' Concepts concepts of Operations operations and <xref target="F3411-22a"/> as it relates to the use of Internet technologies and UA direct UA-direct RF communications. Issues include, but are not limited to:</t>
            <ul empty="true"><li>
  <t><list style="symbols">
    <t>Design spacing="normal">
              <li>the design of trustworthy remote identifiers required by GEN-1 (<xref target="rid"/>), especially but not exclusively for use as single-use session IDs.</t>
  </list></t>
</li></ul>

<ul empty="true"><li>
  <t><list style="symbols">
    <t>Mechanisms IDs,</li>
              <li>mechanisms to leverage the Domain Name System (DNS (DNS) <xref target="RFC1034"/>), target="RFC1034"/> for registering and publishing public and private information (see Sections <xref target="publicinforeg"/> target="publicinforeg" format="counter"/> and <xref target="privateinforeg"/>) target="privateinforeg" format="counter"/>), as required by REG-1 and REG-2.</t>
  </list></t>
</li></ul>

<ul empty="true"><li>
  <t><list style="symbols">
    <t>Specific REG-2,</li>
              <li>specific authentication methods and message payload formats to enable verification that Broadcast RID messages were sent by the claimed sender (<xref target="driptrust"/>) and that the sender is in the claimed DIME (<xref target="ei"/> DRIP Identity Management Entity (DIME) (see Sections <xref target="ei" format="counter"/> and <xref target="driptrust"/>) target="driptrust" format="counter"/>), as required by GEN-2.</t>
  </list></t>
</li></ul>

<ul empty="true"><li>
  <t><list style="symbols">
    <t>Harvesting GEN-2,</li>
              <li>harvesting Broadcast RID messages for UTM inclusion, with the optional DRIP extension of Crowd Sourced Crowdsourced Remote ID (CS-RID, <xref (CS-RID) (<xref target="harvestbridforutm"/>), using the DRIP support for gateways required by GEN-5 <xref target="RFC9153"/>.</t>
  </list></t>
</li></ul>

<ul empty="true"><li>
  <t><list style="symbols">
    <t>Methods target="RFC9153"/>,</li>
              <li>methods for instantly establishing secure communications between an Observer and the pilot of an observed UAS (<xref target="dripcontact"/>), using the DRIP support for dynamic contact required by GEN-4 <xref target="RFC9153"/>.</t>
  </list></t>
</li></ul>

<ul empty="true"><li>
  <t><list style="symbols">
    <t>Privacy target="RFC9153"/>, and</li>
              <li>privacy in UAS RID messages (personal data protection) (<xref target="privacyforbrid"/>).</t>
  </list></t> target="privacyforbrid"/>).</li>
            </ul>
            <t>This document should serve as a main point of entry into the set of IETF documents addressing the basic DRIP requirements.</t>
</li></ul>
      </section>
    </section>
    <section anchor="terms-and-definitions"><name>Terms anchor="terms-and-definitions">
      <name>Terms and Definitions</name>

<t>The
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      <t>To encourage comprehension necessary for adoption of DRIP by the intended user community, the UAS community's norms are respected herein.</t>
      <t>This document uses terms defined in <xref target="RFC9153"/>.</t>
      <t>Some of the acronyms have plural forms that remain the same as their singular forms, e.g., UAS "UAS" can expand to Unmanned "Unmanned Aircraft System System" (singular) or Unmanned "Unmanned Aircraft Systems Systems" (plural), as appropriate for the context.  This usage is consistent with Section 2.2 of <xref target="RFC9153"/>.</t> target="RFC9153" section="2.2" sectionFormat="of" />.</t>
      <section anchor="definitionsandabbr"><name>Additional anchor="definitionsandabbr">
        <name>Additional Abbreviations</name>

<t>DET:        DRIP
	<dl newline="false" spacing="normal" indent="10">
        <dt>DET:</dt>        <dd>DRIP Entity Tag</t>

<t>EdDSA:      Edwards-Curve Tag</dd>
        <dt>EdDSA:</dt>      <dd>Edwards-curve Digital Signature Algorithm</t>

<t>HHIT:       Hierarchical HIT</t>

<t>HI:         Host Identity</t>

<t>HIP:        Host Algorithm</dd>
        <dt>HHIT:</dt>       <dd>Hierarchical HIT</dd>
        <dt>HI:</dt>         <dd>Host Identity</dd>
        <dt>HIP:</dt>        <dd>Host Identity Protocol</t>

<t>HIT:        Host Protocol</dd>
        <dt>HIT:</dt>        <dd>Host Identity Tag</t> Tag</dd>
      </dl>
      </section>
      <section anchor="additional-definitions"><name>Additional anchor="additional-definitions">
        <name>Additional Definitions</name>
        <t>This section introduces the terms "Claim", "Evidence", "Endorsement", and "Certificate" "Certificate", as used in DRIP. A DRIP certificate has a different context compared with security certificates and Public Key Infrastructure used in X.509.</t>

<t>Claim:</t>

<ul empty="true"><li>
  <t>A
	<dl newline="true" spacing="normal">
        <dt>Claim:</dt>
        <dd>A claim shares the same definition as a claim in RATS Remote ATtestation procedureS (RATS) <xref target="RFC9334"/>; it is a piece of asserted information, sometimes in the form of a name/value pair. It could also been seen as a predicate (e.g., "X is Y", "X has property Y", and most importantly "X owns Y" or "X is owned by Y").</t>
</li></ul>

<t>Evidence:</t>

<ul empty="true"><li>
  <t>Evidence Y").</dd>
        <dt>Evidence:</dt>
        <dd>Evidence in DRIP borrows the same definition as in RATS <xref target="RFC9334"/>; target="RFC9334"/>, that is, a set of claims.</t>
</li></ul>

<t>Endorsement:</t>

<ul empty="true"><li>
  <t>An claims.</dd>
        <dt>Endorsement:</dt>
        <dd>An Endorsement is inspired from RATS <xref target="RFC9334"/>; it is a secure (i.e. (i.e., signed) statement vouching the integrity and veracity of evidence.</t>
</li></ul>

<t>Certificate:</t>

<ul empty="true"><li>
  <t>A evidence.</dd>
        <dt>Certificate:</dt>
        <dd>A certificate in DRIP is an endorsement, strictly over identity information, signed by a third party. This third party should be one with no stake in the endorsement over which it is signing.</t>
</li></ul>

<t>DRIP signing.</dd>
        <dt>DRIP Identity Management Entity (DIME):</t>

<ul empty="true"><li>
  <t>An (DIME):</dt>
        <dd>A DIME is an entity that performs functions similar to a domain registrar/registry. A DIME vets Claims and/or Evidence from a registrant and delivers back Endorsements and/or Certificates in response. It is a high-level entity in the DRIP registration/provisioning process that can hold the role of HDA, RAA, HHIT Domain Authority (HDA), Registered Assigning Authority (RAA), or root of trust (typically the HHIT prefix owner or DNS apex owner) for DETs.</t>
</li></ul> DETs.</dd>
        </dl>
      </section>
    </section>
    <section anchor="rid"><name>HHIT anchor="rid">
      <name>HHIT as the DRIP Entity Identifier</name>
      <t>This section describes the DRIP architectural approach to meeting the basic requirements of a DRIP entity identifier within the external technical standard ASTM <xref target="F3411-22a"/> and regulatory constraints. It justifies and explains the use of Hierarchical Host Identity Tags (HHITs) <xref target="I-D.ietf-drip-rid"/> target="RFC9374"/> as self-asserting IPv6 addresses suitable as a UAS ID type and, more generally, as trustworthy multipurpose remote identifiers.</t>
      <t>Self-asserting in this usage means that that, given the Host Identity (HI), the HHIT ORCHID Overlay Routable Cryptographic Hash IDentifier (ORCHID) construction (see section 3.5 of <xref target="I-D.ietf-drip-rid"/>) target="RFC9374" section="3.5" sectionFormat="of" />), and a signature of the DIME on the HHIT and HI; HI, the HHIT can be verified by the receiver as a trusted UAS ID. The explicit registration hierarchy within the HHIT provides registration discovery (managed by a DRIP Identity Management Entity (DIME)) DIME) to either yield the HI for a 3rd-party  third-party (seeking UAS ID endorsement) validation or prove that the HHIT and HI have been registered uniquely.</t>
      <section anchor="uas-remote-identifiers-problem-space"><name>UAS anchor="uas-remote-identifiers-problem-space">
        <name>UAS Remote Identifiers Problem Space</name>
        <t>A DRIP entity identifier needs to be "Trustworthy" (see DRIP Requirement requirements GEN-1, ID-4 ID-4, and ID-5 in <xref target="RFC9153"/>). This means that given a sufficient collection of UAS RID messages, an Observer can establish that the identifier claimed therein uniquely belongs to the claimant. To satisfy DRIP requirements and maintain important security properties, the DRIP identifier should be self-generated by the entity it names (e.g., a UAS) and registered (e.g., with a USS, USS; see Requirements DRIP requirements GEN-3 and ID-2).</t>

<t>However
        <t>However, Broadcast RID, especially its support for Bluetooth 4, imposes severe constraints. A previous revision of the ASTM UAS RID, F3411-19, <xref target="F3411-19"/>, allowed a UAS ID of types (1, 2, and 3), each of 20 bytes. <xref target="F3411-22a"/> adds type 4, Specific Session ID, for other Standards Development Organizations (SDOs) to extend ASTM UAS RID. Type 4 uses one byte to index the Specific Session ID subtype, leaving 19 bytes (see ID-1 of DRIP Requirements <xref target="RFC9153"/>). As described in Section 3 of <xref target="RFC9153"/>, target="RFC9153" section="3" sectionFormat="of" />, ASTM has allocated Specific Session ID subtype 1 to IETF DRIP.</t>
        <t>The maximum ASTM UAS RID Authentication Message payload is 201 bytes each for Authentication Types 1, 2, 3, and 4. <xref target="F3411-22a"/> adds Authentication Type 5 for other SDOs (including the IETF) to extend ASTM UAS RID with Specific Authentication Methods (SAM). (SAMs). With type Type 5, one of the 201 bytes is consumed to index the SAM Type, leaving only 200 bytes for DRIP authentication payloads, including one or more DRIP entity identifiers and associated authentication data.</t>
      </section>
      <section anchor="hhit-as-a-cryptographic-identifier"><name>HHIT anchor="hhit-as-a-cryptographic-identifier">
        <name>HHIT as a Cryptographic Identifier</name>
        <t>The only (known to the authors at the time of this writing) existing types of IP address compatible IP-address-compatible identifiers cryptographically derived from the public keys of the identified entities are Cryptographically Generated Addresses (CGAs) <xref target="RFC3972"/> and Host Identity Tags (HITs) <xref target="RFC7401"/>.  CGAs and HITs lack registration/retrieval capability. To provide this, each HHIT embeds plaintext information designating the hierarchy within which it is registered and registered, a cryptographic hash of that information concatenated with the entity's public key, etc. Although hash collisions may occur, the DIME can detect them and reject registration requests rather than issue credentials, e.g., by enforcing a First Come First Served policy. Pre-image policy <xref target="RFC8126"/>. Preimage hash attacks are also mitigated through this registration process, locking the HHIT to a specific HI.</t>
      </section>
      <section anchor="hhittrustworthy"><name>HHIT anchor="hhittrustworthy">
        <name>HHIT as A a Trustworthy DRIP Entity Identifier</name>
        <t>A Remote UAS ID that can be trustworthy for use in Broadcast RID can be built from an asymmetric keypair. key pair. In this method, the UAS ID is cryptographically derived directly from the public key. The proof of UAS ID ownership (verifiable endorsement, endorsement versus mere claim) is guaranteed by signing this cryptographic UAS ID with the associated private key. The association between the UAS ID and the private key is ensured by cryptographically binding the public key with the UAS ID; more specifically, the UAS ID results from the hash of the public key. The public key is designated as the HI HI, while the UAS ID is designated as the HIT.</t>
        <t>By construction, the HIT is statistically unique through the mandatory use of cryptographic hash functions with second-preimage resistance. The cryptographically-bound cryptographically bound addition of the Hierarchy hierarchy and an a HHIT registration process provide complete, global HHIT uniqueness. This registration forces the attacker to generate the same public key rather than a public key that generates the same HHIT. This is in contrast to general IDs (e.g., a UUID Universally Unique Identifier (UUID) or device serial number) as the subject in an X.509 certificate.</t>
        <t>A UA equipped for Broadcast RID MUST <bcp14>MUST</bcp14> be provisioned not only with its HHIT but also with the HI public key from which the HHIT was derived and the corresponding private key, key to enable message signature.</t>
        <t>A UAS equipped for DRIP enhanced DRIP-enhanced Network RID MUST <bcp14>MUST</bcp14> be provisioned likewise; the private key resides only in the ultimate source of Network RID messages. If the GCS is the source of the Network RID messages; messages, the GCS MUST <bcp14>MUST</bcp14> hold the private key. If the UA is the source of the Network RID messages and they are being relayed by the GCS; GCS, the UA MUST <bcp14>MUST</bcp14> hold the private key, just as a UA that directly connects to the network rather than through its GCS.</t>
        <t>Each Observer device functioning with Internet connectivity MAY <bcp14>MAY</bcp14> be provisioned either with public keys of the DRIP identifier root registries or certificates for subordinate registries; each Observer device that needs to operate without Internet connectivity at any time MUST <bcp14>MUST</bcp14> be so provisioned.</t>
        <t>HHITs can also be used throughout the USS/UTM system. Operators and Private Information Registries, as well as other UTM entities, can use HHITs for their IDs. Such HHITs can facilitate DRIP security functions functions, such as those used with HIP HIP, to strongly mutually authenticate and encrypt communications.</t>
        <t>A self-endorsement of a HHIT used as a UAS ID can be done in as little as 88-bytes 88 bytes when Ed25519 <xref target="RFC8032"/> is used by only including the 16-byte HHIT, two 4-byte timestamps, and the 64-byte Ed25519 signature.</t>
        <t>Ed25519 <xref target="RFC8032"/> is used as the HHIT Mandatory to Implement mandatory-to-implement signing algorithm algorithm, as <xref target="RFC9153"/> GEN-1 and ID-5 <xref target="RFC9153"/> can best be met by restricting the HI to 32 bytes.  A larger public key would rule out the offline endorsement feature that fits within the 200-byte Authentication Message maximum length.  Other algorithms that meet this 32 byte 32-byte constraint can be added as deemed needed.</t>
        <t>A DRIP identifier can be assigned to a UAS as a static HHIT by its manufacturer, such as a single HI and derived HHIT encoded as a hardware serial number number, per <xref target="CTA2063A"/>.  Such a static HHIT SHOULD <bcp14>SHOULD</bcp14> only be used to bind one-time use one-time-use DRIP identifiers to the unique UA.  Depending upon implementation, this may leave a HI private key in the possession of the manufacturer (see also <xref target="sc"/>).</t>
        <t>In general, Internet access may be needed to validate Endorsements or Certificates. This may be obviated in the most common cases (e.g., endorsement of the UAS ID), even in disconnected environments, by pre-populating prepopulating small caches on Observer devices with DIME public keys and a chain of Endorsements or Certificates (tracing a path through the DIME tree). This is assuming all parties on the trust path also use HHITs for their identities.</t>
      </section>
      <section anchor="hhitregandlookup"><name>HHIT anchor="hhitregandlookup">
        <name>HHIT for DRIP Identifier Registration and Lookup</name>
        <t>UAS RID needs a deterministic lookup mechanism that rapidly provides actionable information about the identified UA.  Given the size constraints imposed by the Bluetooth 4 broadcast media, the UAS ID itself needs to be a non-spoofable inquiry input into the lookup.</t>
        <t>A DRIP registration process based on the explicit hierarchy within a HHIT provides manageable uniqueness of the HI for the HHIT.  The hierarchy is defined in <xref target="I-D.ietf-drip-rid"/> target="RFC9374"/> and consists of 2-levels, a Registered Assigning Authority (RAA) 2 levels: an RAA and then a Hierarchical HIT Domain Authority (HDA). an HDA. The registration within this hierarchy is the defense against a cryptographic hash second pre-image second-preimage attack on the HHIT (e.g., multiple HIs yielding the same HHIT, HHIT; see Requirement ID-3 in <xref target="RFC9153"/>). The First Come First Served registration policy is adequate.</t>
        <t>A lookup of the HHIT into the DIME provides the registered HI for HHIT proof of ownership and deterministic access to any other needed actionable information based on inquiry access authority (more details in <xref target="privateinforeg"/>).</t>
      </section>
    </section>
    <section anchor="ei"><name>DRIP anchor="ei">
      <name>DRIP Identifier Registration and Registries</name>
      <t>DRIP registries hold both public and private UAS information (see PRIV-1 in <xref target="RFC9153"/>) resulting from the DRIP identifier registration process.  Given these different uses, and to improve scalability, security, and simplicity of administration, the public and private information can be stored in different registries.  This section introduces the public and private information registries for DRIP identifiers. In this section, for ease of comprehension, the registry functions are described (using familiar terminology) without detailing their assignment to specific implementing entities (or using unfamiliar jargon). Elsewhere in this document, and in forthcoming documents detailing the DRIP registration processes and entities, the more specific term "DRIP Identity Management Entity" (DIME) will be used. This DRIP Identifier identifier registration process satisfies the following DRIP requirements defined in <xref target="RFC9153"/>: GEN-3, GEN-4, ID-2, ID-4, ID-6, PRIV-3, PRIV-4, REG-1, REG-2, REG-3 REG-3, and REG-4.</t>
      <section anchor="publicinforeg"><name>Public anchor="publicinforeg">
        <name>Public Information Registry</name>
        <section anchor="background"><name>Background</name> anchor="background">
          <name>Background</name>
          <t>The public information registry provides trustable information information, such as endorsements of UAS RID ownership and registration with the HDA (Hierarchical HIT Domain Authority). HDA.  Optionally, pointers to the registries for the HDA and RAA (Registered Assigning Authority) implicit in the UAS RID can be included (e.g., for HDA and RAA HHIT|HI used in endorsement signing operations).  This public information will be principally used by Observers of Broadcast RID messages.  Data on UAS that only use Network RID, RID is available via an Observer's Net-RID DP that would directly provide all public registry information. The Net-RID DP is the only source of information for a query on an airspace volume.</t>
	  <aside><t>Note: In the above paragraph, | signifies concatenation of information, e.g., X | Y is the concatenation of X
and Y.</t></aside>
        </section>
        <section anchor="public-drip-identifier-registry"><name>Public anchor="public-drip-identifier-registry">
          <name>Public DRIP Identifier Registry</name>
          <t>A DRIP identifier MUST <bcp14>MUST</bcp14> be registered as an Internet domain name (at an arbitrary level in the hierarchy, e.g., in .ip6.arpa). Thus Thus, the DNS can provide all the needed public DRIP information.  A standardized HHIT FQDN (Fully Fully Qualified Domain Name) Name (FQDN) can deliver the HI via a HIP RR (Resource Record) Resource Record (RR) <xref target="RFC8005"/> and other public information (e.g., RAA and HDA PTRs, PTRs and HIP RVS (Rendezvous Servers) Rendezvous Servers (RVSs) <xref target="RFC8004"/>). These public information registries can use DNSSEC to deliver public information that is not inherently trustable (e.g., everything other than endorsements).</t>
          <t>This DNS entry for the HHIT can also provide a revocation service.  For example, instead of returning the HI RR RR, it may return some record showing that the HI (and thus HHIT) has been revoked.</t>
        </section>
      </section>
      <section anchor="privateinforeg"><name>Private anchor="privateinforeg">
        <name>Private Information Registry</name>
        <section anchor="background-1"><name>Background</name> anchor="background-1">
          <name>Background</name>
          <t>The private information required for DRIP identifiers is similar to that required for Internet domain name registration.  A DRIP identifier solution can leverage existing Internet resources: resources, i.e., registration protocols, infrastructure, and business models, by fitting into a UAS ID structure compatible with DNS names.  The HHIT hierarchy can provide the needed scalability and management structure. It is expected that the private information registry function will be provided by the same organizations that run a USS, USS and likely integrated with a USS.  The lookup function may be implemented by the Net-RID DPs.</t>
        </section>
        <section anchor="information-elements"><name>Information anchor="information-elements">
          <name>Information Elements</name>
          <t>When a DET is used as a UA's Session ID, the corresponding manufacturer assigned manufacturer-assigned serial number MUST <bcp14>MUST</bcp14> be stored in a Private Information Registry private information registry that can be identified uniquely from the DET. When a DET is used as either as a UA's Session ID or as a UA's manufacturer assigned manufacturer-assigned serial number, and the operation is being flown under UTM, the corresponding UTM system assigned UTM-system-assigned Operational Intent Identifier SHOULD <bcp14>SHOULD</bcp14> be so stored. Other information MAY <bcp14>MAY</bcp14> be so stored, stored as such, and often must must, to satisfy CAA regulations or USS operator policies.</t>
        </section>
        <section anchor="private-drip-identifier-registry-methods"><name>Private anchor="private-drip-identifier-registry-methods">
          <name>Private DRIP Identifier Registry Methods</name>
          <t>A DRIP private information registry supports essential registry operations (e.g., add, delete, update, and query) using interoperable open standard protocols. It can accomplish this by leveraging aspects of the Extensible Provisioning Protocol (EPP (EPP) <xref target="RFC5730"/>) target="RFC5730"/> and the Registry Data Access Protocol (RDAP (RDAP) <xref target="RFC7480"/> <xref target="RFC9082"/> <xref target="RFC9083"/>). target="RFC9083"/>.  The DRIP private information registry in which a given UAS is registered needs to be findable, starting from the UAS ID, using the methods specified in <xref target="RFC9224"/>.</t>
        </section>
        <section anchor="alternative-private-drip-registry-methods"><name>Alternative anchor="alternative-private-drip-registry-methods">
          <name>Alternative Private DRIP Registry Methods</name>
          <t>A DRIP private information registry might be an access-controlled DNS (e.g., via DNS over TLS).  Additionally, WebFinger <xref target="RFC7033"/> can be supported. These alternative methods may be used by a Net-RID DP with specific customers.</t>
        </section>
      </section>
    </section>
    <section anchor="driptrust"><name>DRIP anchor="driptrust">
      <name>DRIP Identifier Trust</name>
      <t>While the DRIP entity identifier is self-asserting, it alone does not provide the trustworthiness (non-repudiation, (i.e., non-repudiation, protection vs vs. spoofing, message integrity protection, scalability, etc.) essential to UAS RID, as justified in <xref target="RFC9153"/>. For that that, it MUST <bcp14>MUST</bcp14> be registered (under DRIP Registries) registries) and be actively used by the party (in most cases the UA).  A sender's identity cannot be proved merely by its possessing of a DRIP Entity Tag (DET) and broadcasting it as a claim that it belongs to that sender.  Sending data signed using that HI's private key proves little, as it is subject to trivial replay attacks using previously broadcast messages.  Only sending the DET and a signature on novel (i.e., frequently changing and unpredictable) data that can be externally validated by the Observer (such as a signed Location/Vector message, matching message that matches actually seeing the UA at the location and time reported in the signed message) proves that the observed UA possesses the private key and thus the claimed UAS ID.</t>
      <t>The severe constraints of Broadcast RID make it challenging to satisfy UAS RID requirements. From received Broadcast RID messages and information that can be looked up using the received UAS ID in online registries or local caches, it is possible to establish levels of trust in the asserted information and the Operator.</t> operator.</t>
      <t>A combination of different DRIP Authentication Messages enables an Observer, without Internet connection (offline) or with (online), to validate a UAS DRIP ID in real-time. real time.  Some messages must contain the relevant registration of the UA's DRIP ID in the claimed DIME.  Some messages must contain sender signatures over both static (e.g., registration) and dynamically changing (e.g., current UA location) data.  Combining these two sets of information, an Observer can piece together a chain of trust trust, including real-time evidence to make a determination on the UA's claims.</t>
      <t>This process (combining the DRIP entity identifier, registries, and authentication formats for Broadcast RID) can satisfy the following DRIP requirements defined in <xref target="RFC9153"/>: GEN-1, GEN-2, GEN-3, ID-2, ID-3, ID-4, and ID-5.</t>
    </section>
    <section anchor="harvestbridforutm"><name>Harvesting anchor="harvestbridforutm">
      <name>Harvesting Broadcast Remote ID messages Messages for UTM Inclusion</name>
      <t>ASTM anticipated that regulators would require both Broadcast RID and Network RID for large UAS, UAS but allow UAS RID requirements for small UAS to be satisfied with the operator's choice of either Broadcast RID or Network RID.  The EASA initially specified Broadcast RID for essentially all UAS, UAS and is now also considering Network RID.  The FAA UAS RID Final Rules <xref target="FAA_RID"/> permit only Broadcast RID for rule compliance, compliance but still encourage Network RID for complementary functionality, especially in support of UTM.</t>
      <t>One opportunity is to enhance the architecture with gateways from Broadcast RID to Network RID. This provides the best of both and gives regulators and operators flexibility.  It offers advantages over either form of UAS RID alone: alone, i.e., greater fidelity than Network RID reporting of <xref target="FAA_RID"/> planned area operations; operations, together with surveillance of areas too large for local direct visual observation and direct RF-LOS link based Radio Frequency Line Of Sight (RF-LOS) link-based Broadcast RID (e.g., a city or a national forest).</t>
      <t>These gateways could be pre-positioned (e.g., around airports, public gatherings, and other sensitive areas) and/or crowd-sourced crowdsourced (as nothing more than a smartphone with a suitable app is needed).  Crowd-sourcing  Crowdsourcing can be encouraged by quid pro quo, providing CS-RID Surveillance Supplemental Data Service Provider (SDSP) outputs only to CS-RID Finders. As Broadcast RID media have a limited range, gateways receiving messages claiming sender (typically UA) locations far from the gateway a physical layer receiver thereof ("Finder" below, typically Observer device) should arouse suspicion of possible intent to deceive; a fast and computationally inexpensive consistency check can alert authorities be performed (by the Finder or a the Surveillance SDSP to SDSP) on application layer data present in the failed sanity check possibly indicating intent gateway (claimed UA location vs physical receiver location), and authorities can be alerted to deceive. failed checks. CS-RID SDSPs can use messages with precise date/time/position stamps from the gateways to multilaterate UA location, locations, independent of the locations claimed in the messages, which are entirely operator self-reported by the operator in UAS RID and UTM, and thus are subject not only to natural time lag and error but also operator misconfiguration or intentional deception.</t>
      <t>Multilateration technologies use physical layer information, such as precise Time Of Arrival (TOA) of transmissions from mobile transmitters at receivers with a priori precisely known locations, to estimate the locations of the mobile transmitters.</t>
      <t>Further, gateways with additional sensors (e.g., smartphones with cameras) can provide independent information on the UA type and size, confirming or refuting those claims made in the UAS RID messages.</t>

<t><xref target="csridfinder"/>
      <t>Sections <xref target="csridfinder" format="counter"/> and <xref target="csridsdsp"/> target="csridsdsp" format="counter"/> define two additional entities that are required to provide this Crowd Sourced Crowdsourced Remote ID (CS-RID).</t>
      <t>This approach satisfies the following DRIP requirements defined in <xref target="RFC9153"/>: GEN-5, GEN-11, and REG-1. As Broadcast messages are inherently multicast, GEN-10 is met for local-link multicast to multiple Finders (how (this is how multilateration is possible).</t>
      <section anchor="csridfinder"><name>The anchor="csridfinder">
        <name>The CS-RID Finder</name>
        <t>A CS-RID Finder is the gateway for Broadcast Remote ID Messages into UTM.  It performs this gateway function via a CS-RID SDSP.  A CS-RID Finder could implement, integrate, or accept outputs from a Broadcast RID receiver.  However, it should not depend upon a direct interface with a GCS, Net-RID SP, Net-RID DP DP, or Net-RID client.  It would present a new interface to a CS-RID SDSP, similar to but readily distinguishable from that which a UAS (UA or GCS) presents to a Net-RID SP.</t>
      </section>
      <section anchor="csridsdsp"><name>The anchor="csridsdsp">
        <name>The CS-RID SDSP</name>
        <t>A CS-RID SDSP aggregates and processes (e.g., estimates UA location locations using multilateration when possible) information collected by CS-RID Finders. A CS-RID SDSP should present the same interface to a Net-RID SP as it does to a Net-RID DP and to a Net-RID DP as it does to a Net-RID SP, but its data source must be readily distinguishable as via Finders rather than direct from the UAS itself.</t>
      </section>
    </section>
    <section anchor="dripcontact"><name>DRIP anchor="dripcontact">
      <name>DRIP Contact</name>
      <t>One of the ways in which DRIP can enhance <xref target="F3411-22a"/> with immediately actionable information is by enabling an Observer to instantly initiate secure communications with the UAS remote pilot, Pilot In Command, operator, USS under which the operation is being flown, or other entity potentially able to furnish further information regarding the operation and its intent and/or to immediately influence further conduct or termination of the operation (e.g., land or otherwise exit an airspace volume). Such potentially distracting communications demand strong "AAA" (Authentication, Attestation, Authorization, Access Control, Accounting, Attribution, Audit) Audit), per applicable policies (e.g., of the cognizant CAA).</t>
      <t>A DRIP entity identifier based on a HHIT HHIT, as outlined in <xref target="rid"/> target="rid"/>, embeds an identifier of the DIME in which it can be found (expected typically to be the USS under which the UAS is flying) flying), and the procedures outlined in <xref target="driptrust"/> enable Observer verification of that relationship. A DRIP entity identifier with suitable records in public and private registries registries, as outlined in Section 5 <xref target="driptrust"/>, can enable lookup not only of information regarding the UAS, UAS but also identities of and pointers to information regarding the various associated entities (e.g., the USS under which the UAS is flying an operation), including means of contacting those associated entities (i.e., locators, typically IP addresses).</t>
      <t>A suitably equipped Observer could initiate a secure communication channel, using the DET HI, to a similarly equipped and identified entity: entity, i.e., the UA itself, if operating autonomously; the GCS, if the UA is remotely piloted and the necessary records have been populated in the DNS; the USS, USS; etc. Assuming secure communication setup (e.g. (e.g., via IPsec or HIP), arbitrary standard higher layer higher-layer protocols can then be used for Observer to Pilot (O2P) communications (e.g., SIP <xref target="RFC3261"/> et seq), V2X Vehicle to Everything (V2X) (or more specifically Aircraft to Anything (A2X)) communications (e.g., <xref target="MAVLink"/>), etc.
Certain preconditions are necessary: 1) each party needs a currently usable
means (typically a DNS) of resolving the other party's DRIP entity
identifier to a currently usable locator (IP address); address), and 2) there must
be currently usable bidirectional IP connectivity (not necessarily
via the Internet) connectivity between the parties. One method directly supported by the use of HHITs as DRIP entity identifiers is initiation of a HIP Base Exchange (BEX) and Bound End-to-End Tunnel (BEET).</t>
      <t>This approach satisfies DRIP requirement GEN-6 Contact, supports satisfaction of DRIP requirements <xref target="RFC9153"/> GEN-8, GEN-9, PRIV-2, PRIV-5 PRIV-5, and REG-3, REG-3 <xref target="RFC9153"/>, and is compatible with all other DRIP requirements.</t>
    </section>
    <section anchor="sc"><name>Security anchor="iana">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
    <section anchor="sc">
      <name>Security Considerations</name>
      <t>The size of the public key hash in the HHIT is vulnerable to a second preimage second-preimage attack. It is well within current server array technology to compute another key pair that hashes to the same HHIT (given the current ORCHID construction hash length to fit UAS RID and IPv6 address constraints). Thus, if a receiver were to check HHIT/HI pair validity only by verifying that the received HI and associated information, when hashed in the ORCHID construction, reproduce the received HHIT, an adversary could impersonate a validly registered UA. To defend against this, online receivers should verify the received HHIT and received HI with the HDA (typically USS) with which the HHIT/HI pair purports to be registered. Online and offline receivers can use a chain of received DRIP link endorsements from a root of trust through the RAA and the HDA to the UA, e.g., as described in <xref target="I-D.ietf-drip-auth"/> and <xref target="I-D.ietf-drip-registries"/>.</t>
      <t>Compromise of a DIME private key could do widespread harm <xref target="I-D.ietf-drip-registries"/>. In particular, it would allow bad actors to impersonate trusted members of said DIME. These risks are in addition to those involving key management practices and will be addressed as part of the DIME process. All DRIP public keys can be found in DNS the DNS, thus they can be revoked in DNS the DNS, and users SHOULD <bcp14>SHOULD</bcp14> check the DNS when available. Specific key revocation procedures are as yet to be determined.</t>
      <section anchor="private-key-physical-security"><name>Private anchor="private-key-physical-security">
        <name>Private Key Physical Security</name>
        <t>The security provided by asymmetric cryptographic techniques depends upon protection of the private keys. It may be necessary for the GCS to have the key pair to register the HHIT to the USS. Thus Thus, it may be the GCS that generates the key pair and delivers it to the UA, making the GCS a part of the key security boundary. Leakage of the private key either key, from either the UA or GCS the GCS, to the component manufacturer is a valid concern concern, and steps need to be in place to ensure safe keeping of the private key. Since it is possible for the UAS RID sender of a small harmless UA (or the entire UA) to be carried by a larger dangerous UA as a "false flag", it is out of scope to deal with secure storage of the private key.</t>
      </section>
      <section anchor="quantum-resistant-cryptography"><name>Quantum anchor="quantum-resistant-cryptography">
        <name>Quantum Resistant Cryptography</name>
        <t>There has been no effort as of yet in DRIP to address post quantum computing cryptography.  Small UAS and Broadcast Remote ID communications are so constrained that current post quantum computing cryptography is not applicable.  Fortunately, since a UA may use a unique HHIT for each operation, the attack window can be limited to the duration of the operation.
One potential future DRIP use for post quantum cryptography is for keypairs key pairs that have long usage lives, lives but rarely that rarely, if ever ever, need to be transmitted over bandwidth constrained links; links, such as for Serial Numbers serial numbers or Operators. operators. As the HHIT contains the ID for the cryptographic suite used in its creation, a future post quantum computing safe algorithm that fits Remote ID constraints may readily be readily added. This is left for future work.</t>
      </section>
      <section anchor="denial-of-service-dos-protection"><name>Denial Of anchor="denial-of-service-dos-protection">
        <name>Denial of Service (DoS) Protection</name>
        <t>Remote ID services from the UA use a wireless link in a public space. As such, they are open to many forms of RF jamming. It is trivial for an attacker to stop any UA messages from reaching a wireless receiver. Thus Thus, it is pointless to attempt to provide relief from DOS attacks DoS attacks, as there is always the ultimate RF jamming attack. Also DOS Also, DoS may be attempted with spoofing/replay attacks, attacks; for which which, see <xref target="spoofreplay"/>.</t>
      </section>
      <section anchor="spoofreplay"><name>Spoofing anchor="spoofreplay">
        <name>Spoofing &amp; Replay Protection</name>
        <t>As noted in <xref target="driptrust"/>, spoofing is combatted by the intrinsic self-attesting properties of HHITs HHITs, plus their registration. Also Also, as noted in <xref target="driptrust"/>, to combat replay attacks, a receiver MUST NOT <bcp14>MUST NOT</bcp14> trust that any claims nominally received from an observed UA is that identified in (not even the Basic ID message (i.e. possesses purportedly identifying that UA) until the receiver verifies that the corresponding private key) until it receives key used to sign those claims is trusted, that the sender actually possesses that key, and that the sender appears indeed to be that observed UA. This requires receiving a complete chain of endorsement links from a root of trust to the UA's leaf DET, plus a signed message containing frequently changing, unpredictable but sanity-checkable suitable nonce-like data (e.g., a Location/Vector message) signed with the private key corresponding to that DET, and verifies verifying all the foregoing.</t> foregoing. The term "nonce-like" describes data that is readily available to the prover and the verifier, changes frequently, is not predictable by the prover, and can be checked quickly at low computational cost by the verifier; a Location/Vector message is an obvious choice.</t>
      </section>
      <section anchor="timestamps-time-sources"><name>Timestamps anchor="timestamps-time-sources">
        <name>Timestamps &amp; Time Sources</name>
        <t><xref target="harvestbridforutm"/> and and, more fundamentally fundamentally, <xref target="hhittrustworthy"/> both require timestamps. In Broadcast RID messages, <xref target="F3411-22a"/> specifies both 32 bit Unix style 32-bit Unix-style UTC timestamps (seconds since midnight going into the 1st day of 2019 2019, rather than 1970) and 16 bit 16-bit relative timestamps (tenths of seconds since the start of the most recent hour or other specified event). <xref target="F3411-22a"/> requires that 16 bit 16-bit timestamp accuracy, relative to the time of applicability of the data being timestamped, also be reported, with a worst allowable case of 1.5 seconds. <xref target="F3411-22a"/> does not specify the time source, but GNSS is generally assumed, as latitude, longitude longitude, and geodetic altitude must be reported and most small UAS use GNSS for positioning and navigation.</t>

<ul empty="true"><li>
          <aside>
            <t>Informative note: for For example, to satisfy <xref target="FAA_RID"/>, <xref target="F3586-22"/> specifies tamper protection of the entire RID subsystem and use of the US Government GPS operated GPS. by the US Government. The GPS has sub-microsecond accuracy and 1.5 second 1.5-second precision. In this example, UA-sourced messages can be assumed to have timestamp accuracy and precision of 1.5 seconds at worst.</t>
</li></ul>
          </aside>
        <t>GCS often have access to cellular LTE or other time sources better than the foregoing, and such better time sources would be required to support multilateration in <xref target="harvestbridforutm"/>, but such better time sources cannot be assumed generally for purposes of security analysis.</t>
      </section>
    </section>
    <section anchor="privacyforbrid"><name>Privacy anchor="privacyforbrid">
      <name>Privacy &amp; Transparency Considerations</name>
      <t>Broadcast RID messages can contain personal data (Section 3.2 of <xref target="RFC6973"/>) (<xref target="RFC6973" section="3.2" sectionFormat="of"/>), such as the operator ID and ID, and, in most jurisdictions jurisdictions, must contain the pilot/GCS location. The DRIP architectural approach for personal data protection is symmetric encryption of the personal data using a session key known to the UAS and its USS, as follows. Authorized Observers obtain plaintext in either of two ways. An ways: 1) an Observer can send the UAS ID and the cyphertext to a server that offers decryption as a service. An service, and 2) an Observer can send just the UAS ID to a server that returns the session key, key so that the Observer can directly directly, locally decrypt all cyphertext sent by that UA during that session (UAS operation). In either case, the server can be a Public Safety public safety USS, the Observer's own USS, or the UA's USS if the latter can be determined (which (which, under DRIP it DRIP, can be, be from the UAS ID itself). Personal data is protected unless the UAS is otherwise configured: configured, i.e., as part of DRIP-enhanced RID subsystem provisioning; provisioning, as part of UTM operation authorization; authorization, or via subsequent authenticated communications from a cognizant authority. Personal data protection MUST NOT <bcp14>MUST NOT</bcp14> be used if the UAS loses connectivity to its USS, as USS; if the UAS loses connectivity, Observers nearby likely also won't have connectivity enabling decryption of the personal data. The UAS always has the option to abort the operation if personal data protection is disallowed, but if this occurs during flight, the UA then MUST <bcp14>MUST</bcp14> broadcast the personal data without protection until it lands and is powered off. Note that normative language was used only minimally in this section, as privacy protection requires refinement of the DRIP architecture and specification of interoperable protocol extensions, which are left for future DRIP documents.</t>
    </section>
  </middle>
  <back>

    <references title='Normative References'>

<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname='S. Bradner' initials='S.' surname='Bradner'><organization/></author>
<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' target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></author>
<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='RFC9153' target='https://www.rfc-editor.org/info/rfc9153'>
<front>
<title>Drone Remote Identification Protocol (DRIP) Requirements and Terminology</title>
<author fullname='S. Card' initials='S.' role='editor' surname='Card'><organization/></author>
<author fullname='A. Wiethuechter' initials='A.' surname='Wiethuechter'><organization/></author>
<author fullname='R. Moskowitz' initials='R.' surname='Moskowitz'><organization/></author>
<author fullname='A. Gurtov' initials='A.' surname='Gurtov'><organization/></author>
<date month='February' year='2022'/>
<abstract><t>This document defines terminology and requirements for solutions produced by the Drone Remote Identification Protocol (DRIP) Working Group. These solutions will support Unmanned Aircraft System Remote Identification and tracking (UAS RID) for security, safety, and other purposes (e.g., initiation of identity-based network sessions supporting UAS applications). DRIP will facilitate use of existing Internet resources to support RID and to enable enhanced related services, and it will enable online and offline verification that RID information is trustworthy.</t></abstract>
</front>
<seriesInfo name='RFC' value='9153'/>
<seriesInfo name='DOI' value='10.17487/RFC9153'/>
</reference>

<reference anchor='I-D.ietf-drip-rid' target='https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid-37'>
   <front>
      <title>DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID)</title>
      <author fullname='Robert Moskowitz' initials='R.' surname='Moskowitz'>
         <organization>HTT Consulting</organization>
      </author>
      <author fullname='Stuart W. Card' initials='S. W.' surname='Card'>
         <organization>AX Enterprize, LLC</organization>
      </author>
      <author fullname='Adam Wiethuechter' initials='A.' surname='Wiethuechter'>
         <organization>AX Enterprize, LLC</organization>
      </author>
      <author fullname='Andrei Gurtov' initials='A.' surname='Gurtov'>
         <organization>Linköping University</organization>
      </author>
      <date day='2' month='December' year='2022'/>
      <abstract>
	 <t>   This document describes the use of Hierarchical Host Identity Tags
   (HHITs) as self-asserting IPv6 addresses and thereby a trustable
   identifier for use as the Unmanned Aircraft System Remote
   Identification and tracking (UAS RID).

   This document updates RFC7401 and RFC7343.

   Within the context of RID, HHITs will be called DRIP Entity Tags
   (DETs).  HHITs provide claims to the included explicit hierarchy that
   provides registry (via, e.g., DNS, RDAP) discovery for 3rd-party
   identifier endorsement.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-drip-rid-37'/>

</reference>

<displayreference target="I-D.ietf-drip-auth" to="DRIP-AUTH"/>
<displayreference target="I-D.ietf-drip-registries" to="DRIP-REGISTRIES"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <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.9153.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9374.xml"/>

        <reference anchor="F3411-22a" target="https://www.astm.org/f3411-22a.html">
          <front>
            <title>Standard Specification for Remote ID and Tracking</title>
    <author >
            <author>
              <organization>ASTM International</organization>
            </author>
            <date year="2022" month="July"/>
          </front>
	  <seriesInfo name="ASTM" value="F3411-22A"/>
	    <seriesInfo name="DOI" value="10.1520/F3411-22A"/>
        </reference>
      </references>

    <references title='Informative References'>
      <references>
        <name>Informative References</name>

<reference anchor='I-D.ietf-drip-auth' target='https://datatracker.ietf.org/doc/html/draft-ietf-drip-auth-29'> anchor="I-D.ietf-drip-auth" target="https://datatracker.ietf.org/doc/html/draft-ietf-drip-auth-30">
<front>
      <title>DRIP
<title>
DRIP Entity Tag Authentication Formats &amp; Protocols for Broadcast Remote ID</title> ID
</title>
<author fullname='Adam Wiethuechter' initials='A.' surname='Wiethuechter'> initials="A." surname="Wiethuechter" fullname="Adam Wiethuechter" role="editor">
<organization>AX Enterprize, LLC</organization>
</author>
<author fullname='Stuart initials="S." surname="Card" fullname="Stuart W. Card' initials='S. W.' surname='Card'> Card">
<organization>AX Enterprize, LLC</organization>
</author>
<author fullname='Robert Moskowitz' initials='R.' surname='Moskowitz'> initials="R." surname="Moskowitz" fullname="Robert Moskowitz">
<organization>HTT Consulting</organization>
</author>
<date day='15' month='February' year='2023'/>
      <abstract>
	 <t>   This document describes how to add trust into the Broadcast Remote ID
   (RID) specification discussed in the DRIP Architecture; first trust
   in the RID ownership and second in the source of the RID messages.
   The document defines message types and associated formats (sent
   within the Authentication Message) that can be used to authenticate
   past messages sent by an unmanned aircraft (UA) and provide proof of
   UA trustworthiness even in the absence of Internet connectivity at
   the receiving node.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-drip-auth-29'/>

</reference>

<reference anchor='I-D.ietf-drip-registries' target='https://datatracker.ietf.org/doc/html/draft-ietf-drip-registries-07'>
   <front>
      <title>DRIP Entity Tag (DET) Identity Management Architecture</title>
      <author fullname='Adam Wiethuechter' initials='A.' surname='Wiethuechter'>
         <organization>AX Enterprize, LLC</organization>
      </author>
      <author fullname='Jim Reid' initials='J.' surname='Reid'>
         <organization>RTFM llp</organization>
      </author>
      <date day='5' month='December' year='2022'/>
      <abstract>
	 <t>   This document describes the high level architecture for the
   registration and discovery of DRIP Entity Tags (DETs) using DNS.
   Discovery of DETs and their artifacts are through the existing DNS
   structure and methods by using FQDNs.  A general overview of the
   interfaces required between involved components is described in this
   document with supporting documents giving technical specifications.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-drip-registries-07'/>

</reference>

<reference anchor='RFC9334' target='https://www.rfc-editor.org/info/rfc9334'>
<front>
<title>Remote ATtestation procedureS (RATS) Architecture</title>
<author fullname='H. Birkholz' initials='H.' surname='Birkholz'><organization/></author>
<author fullname='D. Thaler' initials='D.' surname='Thaler'><organization/></author>
<author fullname='M. Richardson' initials='M.' surname='Richardson'><organization/></author>
<author fullname='N. Smith' initials='N.' surname='Smith'><organization/></author>
<author fullname='W. Pan' initials='W.' surname='Pan'><organization/></author>
<date month='January' year='2023'/>
<abstract><t>In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims.  It provides a model that is neutral toward processor architectures, the content of Claims, and protocols.</t></abstract>
</front>
<seriesInfo name='RFC' value='9334'/>
<seriesInfo name='DOI' value='10.17487/RFC9334'/>
</reference>

<reference anchor='RFC1034' target='https://www.rfc-editor.org/info/rfc1034'>
<front>
<title>Domain names - concepts and facilities</title>
<author fullname='P. Mockapetris' initials='P.' surname='Mockapetris'><organization/></author>
<date month='November' year='1987'/>
<abstract><t>This RFC is the revised basic definition of The Domain Name System.  It obsoletes RFC-882.  This memo describes the domain style names and their used for host address look up and electronic mail forwarding.  It discusses the clients and servers in the domain name system and the protocol used between them.</t></abstract>
</front>
<seriesInfo name='STD' value='13'/>
<seriesInfo name='RFC' value='1034'/>
<seriesInfo name='DOI' value='10.17487/RFC1034'/>
</reference>

<reference anchor='RFC3261' target='https://www.rfc-editor.org/info/rfc3261'>
<front>
<title>SIP: Session Initiation Protocol</title>
<author fullname='J. Rosenberg' initials='J.' surname='Rosenberg'><organization/></author>
<author fullname='H. Schulzrinne' initials='H.' surname='Schulzrinne'><organization/></author>
<author fullname='G. Camarillo' initials='G.' surname='Camarillo'><organization/></author>
<author fullname='A. Johnston' initials='A.' surname='Johnston'><organization/></author>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/></author>
<author fullname='R. Sparks' initials='R.' surname='Sparks'><organization/></author>
<author fullname='M. Handley' initials='M.' surname='Handley'><organization/></author>
<author fullname='E. Schooler' initials='E.' surname='Schooler'><organization/></author>
<date month='June' year='2002'/>
<abstract><t>This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants.  These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3261'/>
<seriesInfo name='DOI' value='10.17487/RFC3261'/>
</reference>

<reference anchor='RFC3972' target='https://www.rfc-editor.org/info/rfc3972'>
<front>
<title>Cryptographically Generated Addresses (CGA)</title>
<author fullname='T. Aura' initials='T.' surname='Aura'><organization/></author>
<date month='March' year='2005'/>
<abstract><t>This document describes a method for binding a public signature key to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol.  Cryptographically Generated Addresses (CGA) are IPv6 addresses for which the interface identifier is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters.  The binding between the public key and the address can be verified by re-computing the hash value and by comparing the hash with the interface identifier.  Messages sent from an IPv6 address can be protected by attaching the public key and auxiliary parameters and by signing the message with the corresponding private key.  The protection works without a certification authority or any security infrastructure.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3972'/>
<seriesInfo name='DOI' value='10.17487/RFC3972'/>
</reference>

<reference anchor='RFC5730' target='https://www.rfc-editor.org/info/rfc5730'>
<front>
<title>Extensible Provisioning Protocol (EPP)</title>
<author fullname='S. Hollenbeck' initials='S.' surname='Hollenbeck'><organization/></author>
<date month='August' year='2009'/>
<abstract><t>This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository.  Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects.  This document includes a protocol specification, an object mapping template, and an XML media type registration.  This document obsoletes RFC 4930.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='69'/>
<seriesInfo name='RFC' value='5730'/>
<seriesInfo name='DOI' value='10.17487/RFC5730'/>
</reference>

<reference anchor='RFC7033' target='https://www.rfc-editor.org/info/rfc7033'>
<front>
<title>WebFinger</title>
<author fullname='P. Jones' initials='P.' surname='Jones'><organization/></author>
<author fullname='G. Salgueiro' initials='G.' surname='Salgueiro'><organization/></author>
<author fullname='M. Jones' initials='M.' surname='Jones'><organization/></author>
<author fullname='J. Smarr' initials='J.' surname='Smarr'><organization/></author>
<date month='September' year='2013'/>
<abstract><t>This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods.  WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs.</t></abstract>
</front>
<seriesInfo name='RFC' value='7033'/>
<seriesInfo name='DOI' value='10.17487/RFC7033'/>
</reference>

<reference anchor='RFC7401' target='https://www.rfc-editor.org/info/rfc7401'>
<front>
<title>Host Identity Protocol Version 2 (HIPv2)</title>
<author fullname='R. Moskowitz' initials='R.' role='editor' surname='Moskowitz'><organization/></author>
<author fullname='T. Heer' initials='T.' surname='Heer'><organization/></author>
<author fullname='P. Jokela' initials='P.' surname='Jokela'><organization/></author>
<author fullname='T. Henderson' initials='T.' surname='Henderson'><organization/></author>
<date month='April' year='2015'/>
<abstract><t>This document specifies the details of the Host Identity Protocol (HIP).  HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes.  HIP is based on a Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication.  The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks.  When used together with another suitable security protocol, such as the Encapsulating Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP.</t><t>This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility.  It also incorporates lessons learned from the implementations of RFC 5201.</t></abstract>
</front>
<seriesInfo name='RFC' value='7401'/>
<seriesInfo name='DOI' value='10.17487/RFC7401'/>
</reference>

<reference anchor='RFC7480' target='https://www.rfc-editor.org/info/rfc7480'>
<front>
<title>HTTP Usage in the Registration Data Access Protocol (RDAP)</title>
<author fullname='A. Newton' initials='A.' surname='Newton'><organization/></author>
<author fullname='B. Ellacott' initials='B.' surname='Ellacott'><organization/></author>
<author fullname='N. Kong' initials='N.' surname='Kong'><organization/></author>
<date month='March' year='2015'/>
<abstract><t>This document is one of a collection that together describes the Registration Data Access Protocol (RDAP).  It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP).  RDAP is a successor protocol to the very old WHOIS protocol.  The purpose of this document is to clarify the use of standard HTTP mechanisms for this application.</t></abstract>
</front>
<seriesInfo name='STD' value='95'/>
<seriesInfo name='RFC' value='7480'/>
<seriesInfo name='DOI' value='10.17487/RFC7480'/>
</reference>

<reference anchor='RFC8004' target='https://www.rfc-editor.org/info/rfc8004'>
<front>
<title>Host Identity Protocol (HIP) Rendezvous Extension</title>
<author fullname='J. Laganier' initials='J.' surname='Laganier'><organization/></author>
<author fullname='L. Eggert' initials='L.' surname='Eggert'><organization/></author>
<date month='October' year='2016'/>
<abstract><t>This document defines a rendezvous extension for the Host Identity Protocol (HIP).  The rendezvous extension extends HIP and the HIP Registration Extension for initiating communication between HIP nodes via HIP rendezvous servers.  Rendezvous servers improve reachability and operation when HIP nodes are multihomed or mobile.  This document obsoletes RFC 5204.</t></abstract>
</front>
<seriesInfo name='RFC' value='8004'/>
<seriesInfo name='DOI' value='10.17487/RFC8004'/>
</reference>

<reference anchor='RFC8005' target='https://www.rfc-editor.org/info/rfc8005'>
<front>
<title>Host Identity Protocol (HIP) Domain Name System (DNS) Extension</title>
<author fullname='J. Laganier' initials='J.' surname='Laganier'><organization/></author>
<date month='October' year='2016'/>
<abstract><t>This document specifies a resource record (RR) for the Domain Name System (DNS) and how to use it with the Host Identity Protocol (HIP). This RR allows a HIP node to store in the DNS its Host Identity (HI), the public component of the node public-private key pair; its Host Identity Tag (HIT), a truncated hash of its public key (PK); and the domain names of its rendezvous servers (RVSs).  This document obsoletes RFC 5205.</t></abstract>
</front>
<seriesInfo name='RFC' value='8005'/>
<seriesInfo name='DOI' value='10.17487/RFC8005'/>
</reference>

<reference anchor='RFC8032' target='https://www.rfc-editor.org/info/rfc8032'>
<front>
<title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title>
<author fullname='S. Josefsson' initials='S.' surname='Josefsson'><organization/></author>
<author fullname='I. Liusvaara' initials='I.' surname='Liusvaara'><organization/></author>
<date month='January' year='2017'/>
<abstract><t>This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA).  The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves.  An example implementation and test vectors are provided.</t></abstract>
</front>
<seriesInfo name='RFC' value='8032'/>
<seriesInfo name='DOI' value='10.17487/RFC8032'/>
</reference>

<reference anchor='RFC9082' target='https://www.rfc-editor.org/info/rfc9082'>
<front>
<title>Registration Data Access Protocol (RDAP) Query Format</title>
<author fullname='S. Hollenbeck' initials='S.' surname='Hollenbeck'><organization/></author>
<author fullname='A. Newton' initials='A.' surname='Newton'><organization/></author>
<date month='June' year='2021'/>
<abstract><t>This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using &quot;RESTful&quot; web access patterns.  These uniform patterns define the query syntax for the Registration Data Access Protocol (RDAP). This document obsoletes RFC 7482.</t></abstract>
</front>
<seriesInfo name='STD' value='95'/>
<seriesInfo name='RFC' value='9082'/>
<seriesInfo name='DOI' value='10.17487/RFC9082'/>
</reference>

<reference anchor='RFC9083' target='https://www.rfc-editor.org/info/rfc9083'>
<front>
<title>JSON Responses for the Registration Data Access Protocol (RDAP)</title>
<author fullname='S. Hollenbeck' initials='S.' surname='Hollenbeck'><organization/></author>
<author fullname='A. Newton' initials='A.' surname='Newton'><organization/></author>
<date month='June' year='2021'/>
<abstract><t>This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs).  These data structures are used to form Registration Data Access Protocol (RDAP) query responses. This document obsoletes RFC 7483.</t></abstract>
</front>
<seriesInfo name='STD' value='95'/>
<seriesInfo name='RFC' value='9083'/>
<seriesInfo name='DOI' value='10.17487/RFC9083'/>
</reference>

<reference anchor='RFC9224' target='https://www.rfc-editor.org/info/rfc9224'>
<front>
<title>Finding the Authoritative Registration Data Access Protocol (RDAP) Service</title>
<author fullname='M. Blanchet' initials='M.' surname='Blanchet'><organization/></author>
<date month='March' year='2022'/>
<abstract><t>This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses, or Autonomous System numbers. This document obsoletes RFC 7484.</t></abstract>
</front>
<seriesInfo name='STD' value='95'/>
<seriesInfo name='RFC' value='9224'/>
<seriesInfo name='DOI' value='10.17487/RFC9224'/>
</reference>

<reference anchor='RFC6973' target='https://www.rfc-editor.org/info/rfc6973'>
<front>
<title>Privacy Considerations for Internet Protocols</title>
<author fullname='A. Cooper' initials='A.' surname='Cooper'><organization/></author>
<author fullname='H. Tschofenig' initials='H.' surname='Tschofenig'><organization/></author>
<author fullname='B. Aboba' initials='B.' surname='Aboba'><organization/></author>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/></author>
<author fullname='J. Morris' initials='J.' surname='Morris'><organization/></author>
<author fullname='M. Hansen' initials='M.' surname='Hansen'><organization/></author>
<author fullname='R. Smith' initials='R.' surname='Smith'><organization/></author>
<date month='July' year='2013'/>
<abstract><t>This document offers guidance for developing privacy considerations for inclusion in protocol specifications.  It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices.  It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content.</t></abstract> month="March" day="28" year="2023"/>
</front>
<seriesInfo name='RFC' value='6973'/>
<seriesInfo name='DOI' value='10.17487/RFC6973'/> name="Internet-Draft" value="draft-ietf-drip-auth-30"/>
</reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-drip-registries.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9334.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3972.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5730.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7033.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7401.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7480.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8004.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8005.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8032.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9082.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9083.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9224.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6973.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>

        <reference anchor="F3586-22" target="https://www.astm.org/f3586-22.html">
          <front>
            <title>Standard Practice for Remote ID Means of Compliance to Federal Aviation Administration Regulation 14 CFR Part 89</title>
    <author >
            <author>
              <organization>ASTM International</organization>
            </author>
            <date year="2022" month="July"/>
          </front>
	  <seriesInfo name="ASTM" value="F3586-22"/>
	  <seriesInfo name="DOI" value="10.1520/F3586-22"/>
        </reference>

        <reference anchor="MOC-NOA" target="https://www.regulations.gov/document/FAA-2022-0859-0001">
          <front>
            <title>Accepted Means of Compliance; Remote Identification of Unmanned Aircraft</title>
    <author >
            <author>
              <organization>United States Federal Aviation Administration (FAA)</organization>
            </author>
            <date year="2022" month="August"/>
          </front>
	   <seriesInfo name="Document ID" value="FAA-2022-0859-0001"/>
        </reference>

        <reference anchor="CTA2063A" > anchor="CTA2063A">
          <front>
            <title>Small Unmanned Aerial Systems Serial Numbers</title>
    <author >
            <author>
              <organization>ANSI</organization>
            </author>
            <date year="2019"/> year="2019" month="September"/>
          </front>
	   <seriesInfo name="ANSI/CTA" value="2063-A"/>
        </reference>

        <reference anchor="Delegated" target="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32019R0945"> target="https://eur-lex.europa.eu/eli/reg_del/2019/945/oj">
          <front>
    <title>EU Commission
            <title>Commission Delegated Regulation (EU) 2019/945 of 12 March 2019 on unmanned aircraft systems and on third-country operators of unmanned aircraft systems</title>
    <author >
            <author>
              <organization>European Union Aviation Safety Agency (EASA)</organization>
            </author>
            <date year="2019"/> year="2019" month="March"/>
          </front>
        </reference>

        <reference anchor="Implementing" target="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32019R0947">
          <front>
    <title>EU Commission
            <title>Commission Implementing Regulation (EU) 2019/947 of 24 May 2019 on the rules and procedures for the operation of unmanned aircraft</title>
    <author > aircraft (Text with EEA relevance.)</title>
            <author>
              <organization>European Union Aviation Safety Agency (EASA)</organization>
            </author>
            <date year="2019"/> year="2019" month="May"/>
          </front>
        </reference>

        <reference anchor="Implementing_update" target="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32021R0664">
          <front>
    <title>EU COMMISSION IMPLEMENTING REGULATION
            <title>Commission Implementing Regulation (EU) 2021/664 of 22 April 2021 on a regulatory framework for the U-space</title>
    <author > U-space (Text with EEA relevance)</title>
            <author>
              <organization>European Union Aviation Safety Agency (EASA)</organization>
            </author>
            <date year="2021"/> year="2021" month="April"/>
          </front>
        </reference>

        <reference anchor="NPA" target="https://www.easa.europa.eu/downloads/134303/en">
          <front>
            <title>Notice of Proposed Amendment 2021-14 2021-14: Development of acceptable means of compliance and guidance material to support the U-space regulation</title>
    <author >
            <author>
              <organization>European Union Aviation Safety Agency (EASA)</organization>
            </author>
            <date year="2021"/> year="2021" month="December"/>
          </front>
        </reference>

        <reference anchor="LAANC" target="https://www.faa.gov/uas/programs_partnerships/data_exchange/"> target="https://www.faa.gov/      air_traffic/publications/atpubs/foa_html/chap12_section_9.html">
          <front>
            <title>Low Altitude Authorization and Notification Capability</title>
    <author >
            <author>
              <organization>United States Federal Aviation Administration (FAA)</organization>
            </author>
    <date year="n.d."/>
          </front>
        </reference>

        <reference anchor="NPRM" > target="https://www.federalregister.gov/documents/2019/                  12/31/2019-28100/remote-identification-of-unmanned-aircraft-systems">
          <front>
    <title>Notice of Proposed Rule Making on Remote
            <title>Remote Identification of Unmanned Aircraft Systems</title>
    <author >
            <author>
              <organization>United States Federal Aviation Administration (FAA)</organization>
            </author>
            <date month="December" year="2019"/>
          </front>
	  <refcontent>Notice of proposed rulemaking</refcontent>
        </reference>

        <reference anchor="TS-22.825" anchor="TR-22.825" target="https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3527">
          <front>
            <title>Study on Remote Identification of Unmanned Aerial Systems (UAS)</title>
    <author >
            <author>
              <organization>3GPP</organization>
            </author>
            <date month="September" year="2018"/>
          </front>
	  <seriesInfo name="3GPP TR" value="22.825"/>
	  <refcontent>Release 16</refcontent>
        </reference>

        <reference anchor="TR-23.755" target="https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3588">
          <front>
            <title>Study on application layer support for Unmanned Aerial Systems (UAS) (Release 17)</title>
    <author > (UAS)</title>
            <author>
              <organization>3GPP</organization>
            </author>
            <date year="2019"/> year="2021" month="March"/>
          </front>
	  <seriesInfo name="3GPP TR" value="23.755"/>
	  <refcontent>Release 17</refcontent>
        </reference>

        <reference anchor="TS-23.255" target="https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3843">
          <front>
            <title>Application layer support for Uncrewed Aerial System (UAS) (UAS); Functional architecture and information flows; (Release 17)</title>
    <author > flows</title>
            <author>
              <organization>3GPP</organization>
            </author>
            <date year="2020"/> year="2021" month="June"/>
          </front>
	  <seriesInfo name="3GPP TS" value="23.255"/>
	  <refcontent>Release 17</refcontent>
        </reference>

        <reference anchor="U-Space" target="https://www.sesarju.eu/sites/default/files/documents/u-space/CORUS%20ConOps%20vol2.pdf">
          <front>
            <title>U-space Concept of Operations</title>
    <author >
            <author>
              <organization>European Organization for the Safety of Air Navigation (EUROCONTROL)</organization>
            </author>
            <date year="2019"/> year="2019" month="October"/>
          </front>
        </reference>

        <reference anchor="FAA_RID" target="https://www.govinfo.gov/content/pkg/FR-2021-01-15/pdf/2020-28948.pdf">
          <front>
            <title>Remote Identification of Unmanned Aircraft</title>
    <author >
            <author>
              <organization>United States Federal Aviation Administration (FAA)</organization>
            </author>
            <date year="2021"/> year="2021" month="January"/>
          </front>
	  <refcontent>Federal Register, Vol. 86, No. 10</refcontent>
        </reference>

        <reference anchor="FAA_UAS_Concept_Of_Ops" target="https://www.faa.gov/uas/research_development/traffic_management/media/UTM_ConOps_v2.pdf"> target="https://www.faa.gov/sites/faa.gov/files/2022-08/UTM_ConOps_v2.pdf">
          <front>
            <title>Unmanned Aircraft System (UAS) Traffic Management (UTM) Concept of Operations (V2.0)</title>
    <author > Operations</title>
            <author>
              <organization>United States Federal Aviation Administration (FAA)</organization>
            </author>
            <date year="2020"/> year="2020" month="March"/>
          </front>
	  <refcontent>v2.0</refcontent>
        </reference>

        <reference anchor="MAVLink" target="http://mavlink.io/">
          <front>
            <title>Micro Air Vehicle Communication Protocol</title>
    <author >
      <organization></organization>
            <author>
              <organization>MAVLink</organization>
            </author>
    <date year="2021"/>
          </front>
        </reference>

        <reference anchor="FS_AEUA" target="https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_147E_Electronic_2021-10/Docs/S2-2107092.zip">
          <front>
            <title>Study of Further Architecture Enhancement for UAV and UAM</title>
    <author >
      <organization></organization>
            <author>
              <organization/>
            </author>
            <date month="October" year="2021"/>
          </front>
	  <refcontent>S2-2107092</refcontent>
        </reference>

	        <reference anchor="F3411-19" target="https://www.astm.org/f3411-19.html">
          <front>
            <title>Standard Specification for Remote ID and Tracking</title>
            <author>
              <organization>ASTM International</organization>
            </author>
            <date year="2022" month="May"/>
          </front>
	  <seriesInfo name="ASTM" value="F3411-19"/>
	    <seriesInfo name="DOI" value="10.1520/F3411-19"/>
        </reference>

      </references>
    </references>
    <section anchor="appendix-a"><name>Overview anchor="appendix-a">
      <name>Overview of Unmanned Aircraft Systems (UAS) UAS Traffic Management (UTM)</name>
      <section anchor="operation-concept"><name>Operation anchor="operation-concept">
        <name>Operation Concept</name>
        <t>The efforts of the National Aeronautics and Space Administration (NASA) and FAA's effort FAA to integrate UAS operations into the national airspace system (NAS) led to the development of the concept of UTM and the ecosystem around it.  The UTM concept was initially presented in 2013 2013, and version 2.0 was published in 2020 <xref target="FAA_UAS_Concept_Of_Ops"/>.</t>
        <t>The eventual concept refinement, initial prototype implementation, and testing were conducted by the joint FAA and NASA UTM research transition team. World efforts took place afterward.  The Single European Sky ATM Research (SESAR) started the CORUS Concept of Operation for EuRopean UTM Systems (CORUS) project to research its UTM counterpart concept, namely <xref target="U-Space"/>.  This effort is led by the European Organization for the Safety of Air Navigation (Eurocontrol).</t> (EUROCONTROL).</t>
        <t>Both NASA and SESAR have published their UTM concepts of operations to guide the development of their future air traffic management (ATM)
system and ensure safe and efficient integration of manned and unmanned aircraft into the national airspace.</t>
        <t>UTM comprises UAS operations infrastructure, procedures procedures, and local regulation compliance policies to guarantee safe UAS integration and operation.  The main functionality of UTM includes, but is not limited to, providing means of communication between UAS operators and service providers and a platform to facilitate communication among UAS service providers.</t>
      </section>
      <section anchor="uas-service-supplier-uss"><name>UAS anchor="uas-service-supplier-uss">
        <name>UAS Service Supplier (USS)</name>
        <t>A USS plays an important role to fulfill the key performance indicators (KPIs) that UTM has to offer.  Such an Entity entity acts as a proxy between UAS operators and UTM service providers.  It provides services like real-time UAS traffic monitoring and planning, aeronautical data archiving, airspace and violation control, interacting with other third-party control entities, etc.  A USS can coexist with other USS to build a large service coverage map that can load-balance, relay, and share UAS traffic information.</t>
        <t>The FAA works with UAS industry shareholders and promotes the Low Altitude Authorization and Notification Capability <xref target="LAANC"/> program, which is the first system to realize some of the envisioned functionality of UTM. The LAANC program can automate UAS operational intent (flight plan) submission submissions and application applications for airspace authorization in real-time real time by checking against multiple aeronautical databases databases, such as airspace classification and operating rules associated with it, the FAA UAS facility map, special use airspace, Notice to Airmen (NOTAM), and Temporary Flight Restriction (TFR).</t>
      </section>
      <section anchor="utm-use-cases-for-uas-operations"><name>UTM anchor="utm-use-cases-for-uas-operations">
        <name>UTM Use Cases for UAS Operations</name>
        <t>This section illustrates a couple of use case scenarios where UAS participation in UTM has significant safety improvement.</t>

<t><list style="numbers">
  <t>For
        <ol spacing="normal" type="1">
	  <li>For a UAS participating in UTM and taking off or landing in controlled airspace (e.g., Class Bravo, Charlie, Delta, and Echo in the United States), the USS under which the UAS is operating is responsible for verifying UA registration, authenticating the UAS operational intent (flight plan) by checking against a designated UAS facility map database, obtaining the air traffic control (ATC) authorization, and monitoring the UAS flight path in order to maintain safe margins and follow the pre-authorized sequence of authorized 4-D volumes (route).</t>
  <t>For (route).</li>
          <li>For a UAS participating in UTM and taking off or landing in uncontrolled airspace (e.g., Class Golf in the United States), pre-flight preflight authorization must be obtained from a USS when operating Beyond Visual Line Of Sight (BVLOS). BVLOS.  The USS either accepts or rejects the received operational intent (flight plan) from the UAS.  An accepted UAS operation may, and in some cases must, share its current flight data, such as GPS position and altitude, to the USS.  The USS may maintain (and provide to authorized requestors) the UAS operation status near real-time real time in the short term, term and may retain at least some of it in the longer term, e.g., for overall airspace air traffic monitoring.</t>
</list></t> monitoring.</li>
        </ol>
      </section>
    </section>
    <section anchor="adsb"><name>Automatic anchor="adsb">
      <name>Automatic Dependent Surveillance Broadcast (ADS-B)</name>

<t>The ADS-B
      <t>ADS-B is the de jure technology used in manned aviation for sharing location information, from the aircraft to ground and satellite-based systems, designed in the early 2000s. Broadcast RID is conceptually similar to ADS-B, ADS-B but with the receiver target being the general public on generally available devices (e.g., smartphones).</t>
      <t>For numerous technical reasons, ADS-B itself is not suitable for low-flying low-flying, small UAS. Technical reasons include include, but are not limited to to, the following:</t>

<t><list style="numbers">
  <t>Lack
      <ol spacing="normal" type="1">
	<li>lack of support for the 1090 MHz 1090-MHz ADS-B channel on any consumer handheld devices</t>
  <t>Cost, devices</li>
        <li>Cost, Size, Weight Weight, and Power (CSWaP) requirements of ADS-B transponders on CSWaP constrained UA</t>
  <t>Limited CSWaP-constrained UA</li>
        <li>limited bandwidth of both uplink and downlink, which would likely be saturated by large numbers of UAS, endangering manned aviation</t>
</list></t> aviation</li>
      </ol>
      <t>Understanding these technical shortcomings, regulators worldwide have ruled out the use of ADS-B for the small UAS for which UAS RID and DRIP are intended.</t>
    </section>
    <section numbered="no" anchor="acknowledgments"><name>Acknowledgments</name> numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>The work of the FAA's UAS Identification and Tracking (UAS ID) Aviation Rulemaking Committee (ARC) is the foundation of later ASTM and IETF DRIP WG efforts.  The work of ASTM F38.02 in balancing the interests of diverse stakeholders is essential to the necessary rapid and widespread deployment of UAS RID. Thanks to Alexandre Petrescu, Stephan Wenger, Kyle Rose, Roni Even, Thomas Fossati, Valery Smyslov, Erik Kline, John Scudder, Murray Kucheraway, Robert Wilton, Roman Daniliw, Warren Kumari, Zaheduzzaman Sarker and Dave Thaler <contact fullname="Alexandre Petrescu"/>, <contact fullname="Stephan Wenger"/>, <contact fullname="Kyle Rose"/>, <contact fullname="Roni Even"/>, <contact fullname="Thomas Fossati"/>, <contact fullname="Valery Smyslov"/>, <contact fullname="Erik Kline"/>, <contact fullname="John Scudder"/>, <contact fullname="Murray Kucheraway"/>, <contact fullname="Robert Wilton"/>, <contact fullname="Roman Daniliw"/>, <contact fullname="Warren Kumari"/>, <contact fullname="Zaheduzzaman Sarker"/>, and <contact fullname="Dave Thaler"/> for the reviews and helpful positive comments. Thanks to Laura Welch <contact fullname="Laura Welch"/> for her assistance in greatly improving this document. Thanks to Dave Thaler <contact fullname="Dave Thaler"/> for showing our authors how to leverage the RATS model for attestation in DRIP. Thanks to chairs Daniel Migault and Mohamed Boucadair <contact fullname="Daniel Migault"/> and <contact fullname="Mohamed Boucadair"/> for direction of our team of authors and editor, editors, some of whom are relative newcomers to writing IETF documents.  Thanks especially to Internet Area Director Eric Vyncke <contact fullname="Éric Vyncke"/> for guidance and support.</t>
    </section>
  </back>

<!-- ##markdown-source:
H4sIABAaBGQAA91963LbSJbmfz0FwhUzRVaRulC+V/Ts0JJsa9qy1KLs6p7d
DQdEghLKIMAGQMkqu+ax9gX2xfZ855KZAEHZ1TM90bGKirJEAnk5ee63HA6H
W3VaZ8nz6LAs8iQ6TxZFnUTHsySv03k6jeu0yKOzsqiLaZFFvcPz47N+NC6n
12mdTOtVmWzFl5dlckMD0FfNb2bFNI8XNPasjOf1ME3q+XBWpsthTE8N9/e2
ZnFN3452R/vDXfrv0dZWVcf57EOc0VqeR3W5SuiTMokXz6Pjo4uXW+my5I+r
erS7+2x3tBXTl/Td24ut2yvMky63Pt7SB3mdlHlSDw8x8xZt43mU5vNia2ta
zNKcHl3RWp5uLdPn0f+krQ2iqihponlFv90t8Mv/3tqKV/V1UT7fivhnqP9G
NFL1PJpsRwdxOXMfyk4n9Sou6+jn1pdFSVOO/xwdYV3LMv01cV9hfwkt7+Gz
h0+ig2KxSMppGmd0HumNf2qa1nfPo78U5cebNMuSQfT2L/67YkYz7+0/fPYo
+GyV1yW98m4ydh8mizjNntOMq+0pre5f40+JW8/2tFh0b3S8Hf1MR3e9SqbX
9HRrw+NZvOj+/h9qzzEtc/s2WOY3bv58Ozopqo/FbVr/2tr5eXGZ0FGvf80b
f31xQTvLq1VWE76t7fzBg9Y2T+OP0VlcfhxEJ8etXT58Otp/8k27LK8W/5rF
l9X2dV0PpzL75r0RBv/7dVxEvaNZWhdlv43K16s45SeaOwNtZWsbGhFBRidp
VYFfHBR0XldJ9CK7mbX2OYnzOo4OsriMW9t89mj30cNvQ2CsbPtXWtm/pkmS
bNOyNqLuq1VZFzdtpM1nZZK2v+PdvUnzj//3/yzpzKJ3OWFjWdGy13Z7fDhu
7cu/19rW5Gj46One0/3uJ3STk9uEOG57n1e8vn+NpwveYl6UC+LHN8nzLXry
/OXBaG/v2XP59enek4f28bO9R/vCC4dl8tdVWiYLQvUK3x4PD7c9Gy7TmT4H
bl/fDev4Ck+93H+4tzccjWJhfSogJmDNxDaiyTKZetkwL0onNQ4jeiS6KOPp
R9vmJh4q3GFycaK8mgeLBa/quLwClAmLl9XznZ3b29vtuKoZCjtzWxwh+UKe
FzHyb6vsDrJktLUFVu9g1d41VqTbxq/YumxlHT7JVUonniaVA6d9YKDe33+o
J7C3637dHz3es1+fPRnpr4+e7O/qr0929/ft14e7e+7Xp/bA093dh/7XR+7X
fRvs2e7T4Fcb7NloZK89fvZk/7kc5qOnjwle3Wd5RmdF+09ax3iSxHkVFXMw
52WWxjk9URfRS8LSkvj0+CaVwx/PFmkOkMif58nVKpNf9x5GBy/PwdLq6Omz
vxcqyNbuwYQoOjk9GL49HTe2P55Ok2WdzLr2+dMGHYgeepcv4jyn18ZpOWXF
4qvbIh6CeQjedVJ9FX69l+Nxf+O+SwfdavuquNkh9WoFyt6ht4bY7nD36aNn
w93d3b0AGOPVFalLDhwHF+PR7uP9JjwmizjLgu0lJaTx5K6qk0UVTeTPt6sF
CbzqG47y7eQ4WMBod+8ZZj5MSCbQJ7PG1EfvWAFQweGeCVEJA+w8e/gIR7A3
ik6gPfKHEX25skXHeiakv8mywYrogfo6LWdD5bRRsaQDIGHHh77x3a/v8WhV
0lBxjgPGOdqBTuJ5Ut9F46skn96RZB1PNhxosiqHWfJpO8FAMf2zg51nkNo1
zvTo7c7Fny92/seqTP9wcPTm6M//tD/ex6bPdwkUHeA9JgRmRg/1djOEw8c6
gPwEcBk9JCDfORATj4zKVZYISJdlMU1mpN5XzDPwpQBViWQNqP/owHzyFWB+
WC35yzZMT09OjieT49O30fHJ2Zujk6O3F8dvX0XnR6/evRlf4PPe0bs+CG9v
5/HjhwzYUTQmhTPjDwHaOFKiLgg35yUpJ7ek7jrAvhtWy3ia/ONCcLR3vkt7
a0BwtAcIvj1rspi3BYsZAgIZk8uiApshAM8AZH5pSBLjMLlJsmLJn9GTMbPp
+DJLooUx6qkXSMDGq1U64z9I2gubIjFVrZZLMudCEEaeef43QBPcOomrOADn
rLjNsyKeVTtktOzv7u+outeE2pvx+O1BA25vittoTDZEvZolxMux6vRXWQ72
D7A6EXUQL+PLNDOF9b9NMM3jmAXSKq52iD1cER5XH5Yk+XOSF9fpstqhXcYf
kk/T6zi/SnYEP85PvoYg58R0iBNBl4xYu/hWuWyi6+8Hhia7uJhAC3k6etRS
slazu29ceFPi9t6NJ/2vL37/1dlZ56EA++Nse/9quWRFaZZUH2uiq2IGNr7T
UOBbfx4mNdkeFSlZy0//owq/OZ79Yf/RqMUtn/L2z4ej/e0njzZsP14Sxeqm
s/guKR2Bgs/dC4Ood04aQVwl0d6Tf0yAPH26AR/2t0ctgIy/Aodpmdy24aBg
eLnKp6IVR3HgYWMW4IwdGGNZcVv99A8PtacP95vMbxdQezecgFU3YOb490GR
QxiAak5N3fg9etppeRXnxjlNvipDpzGJc0Rv45v0Sgn96N356cHp24vz0zeb
+V6VVHH5ywrsvaIjITaXzONVVu/MU8DH9PNqZyWb2Dk4PX83+afRLm3mdFnR
LzdFNtpezuYdOESs5sP58WEDGv+olgkxf2AhCwHTGJYfr3Zeng9ZtO+SdH+0
Q/vcwVkPR0+fPXy6tm2RgNg2ofwHPe8Pp/MPBKoGFDaxe6WVC/qIYEOCI4+v
WImjLy5O+t0oFPXej7Z3v4FK/l4CkxTpBDT9YeaVn51a9vBh4faws0hmabxD
G/kg2PPhZh1zhI5Oxu/ha2rA7CSdlgVj+fvkOp1mCdsEq7zt4V9bMq14Ed9k
NN52Wux0Hdjkw/jo3biL9c+Jb5VEZ2UjLBAd5ddQ2fhkmPON3zMjezc+2Qgx
x4Pm9XKnrq4+VPHOz69GHzDwzsXk1WT0Ye/hk6MPRxlNUha0rw+iVO7uHBZT
Yk6j4Whv98nus9H2r+lybRvD4TCKL3F603pr6+I6rSKj3oi43rRML9n8aXJf
LH6pgBPjqErKG9JiqlAL/Qq6dtN0j0i/z0PW6k0bRMtsVRGQJhF9NyyTjO3k
aXiM1XbEa2/KiBmdgCyJLbnAJRhlhLEJRAh/xRGc8/B7B4Te+cuDCI7F/rZA
a5HOZlmytfUdnDYlSQSWT9F3RjOfv0uDz3/7xwbq/QBNmgus44+0FtpdAQMF
foXosqivo+mqLBlUaT7NVogyYR+syfYD80P2lBf5EBGtiEa9xmxZVKlPrtoG
sJK/wyF+/qze4d9+E80ho82DY9HA12RnwAlEREujLKIpncsl7K56EJHiDr6J
k3l19Hb4JPpTMRlEt8RHriM61CyZy5fzFa8VJqzArexcBkHlJp3J0SefSFjM
ePUBFuku6UGy/RaRaABY8Yp0mikpNnQuyloGcPC0MN7NxBZ15cFyxG7u6CK+
inqHRxd9gsiaR5xgc5vSmALNcFw6l+++i05vgI7JLYtdIUYBJm3R3KqmZ3z3
3daWPZMKqgc6YH0d11GSw74VuqZtE8hTRVoCyuUdf75RognXnMBDBwqJJisM
T0YXfT+B9vz5M01IAE4/DePfflPch0Msgnl2F7HfP6XpqxWdZUxnGd/Sh3SY
wp+3MeddhFBSOvMiM9m+2h5ElWhPQqKE/QTafjRLp5CQsjms7RJoAGrM7tzW
sGWC5kF6k4YiVKxbXk/vYDyu+kClbHZLr9FBwMYn6LLjSoG6HeExozyagDBm
scrgQYxIwrNeTJJmeBnDnAxpkJc3K4gO60jU0zslxb+ukmoQXa7qiLYL2TWl
8yf0nIFUBBRJXhHT6KBcQPB+pwXt+t1k/I3qw9a/MBXR79FydUlkfg232tcs
5c+fYVsTGqfi1Yv01Il/EJ+kDYVjPXiZwqjA+w/khdEejaDK52+/DaJ0QVNg
3AYx0xpxBgTe1Txm6ijV42oO1oFyRR/dxddlQlaOOviVR2DpAGGd6LEQHhSw
Z6bRYQLkBb5PVuVNQvyKfT0vyiKeERsgMhgfToYv+tEpHZfy9bxaFvQOLYdY
GI6XEHAFGEF60KgVThqOIaXLrm3Ro8LdzPUpdAu8rJKE4BPPqkuiJzrN3+Ur
ogM9zgn+ZbVKa2W10QM1cR4At0xBjSPAnCZ248dpKXwQZEeoXl0TSTCLMH8r
+GPb+TrgKTB749g/f3aedkIUTxgOZ37nqW9wshP2OFkIisJxZOmCFWmCcdcR
CFJUxLejO9KLB7L2OKuKcAM5OHfgo21ugoxrzAiXGykaMERB/Zs82FhF4e0B
j8QswWmHBUE0G3iMyKNbonPxCs8CoulwGv/223Y0vt/3CXIdQ+jQmH6HNipB
ScVltCjKpGHsx5fFSpycs/9av+m6zxQ6CdZcptALJsU0BXIDehdJxYDCoCc6
FpEJwnmM7+txvQG9Y5yTAxN1TTT1cv+p6G4DovXLafj59u6IBjQ9z5tu9OjP
8JYfQ+/7+Y+PH+0+3BsYLBJmeTI98TMLGhOgf3cce9vtg+z7NE9AB4SiSR2q
AI2DAUXcFgL8AdljB0Px91w6xoVHjs/04zypoTMN9JxM/SSopiSBo+M5EB4T
ER+rPFv11htpadfFrBJiZ9oJl7NA/O8yMUSaRcSjZBRe4HYLPqkoTOviLSIx
mlbGtvCShF/pnQcSSD0NA6kPot7J6UFfsVFYVa3iDLhOG//8WaOzNITqfPTt
987KieYsnZgDB0JJ9K2KlEc6QeUltL9woqogIBQsv6EiqEq9T5t4leQWrTrz
LmpQ5i80WNSDN4wx92fSAiPnSHsswMW3QktJrSjWwcWQYkUG8OfPzjGsizaD
APxd8MdptKa/L4pL4leGEy0DCOJRNfNiPk9YALBuo5yZdSLmoN4D6Bdjblpd
TMMtp4tlryV9PycVmvl9Isa66Jm6kKZQ0H2JSq9qu2QL4ptQ4W0o6T5IQ3u6
JdHORyhPg3OBHhlJH77igR69MpiYjPh9ToaWe1XdIOxnfq+adHlJoIWP5KSQ
MAq+PIGVoE4OUaocaJ+SxSNTK5Rk/23aRNQjrRa0v/o2SeSgeL7JBP4c2U3b
PklxImKOLOI7p8TElUdDQuxhBm7HI4JaAhbWtHxJ5QDeVesmzMXdMqkcI3P8
D5YLW+xNJDErDTslBld3vyxskoXYOv/lJXwX6HDnPN130efvLrHfra0mOzKe
G7c5Lll2FZlDIsRnhI5T0naIMw9v47tBwGpZJ9TwNz1MFoKSbVQQHKIX2Sqp
CyAaDfNzOnyZCgVVYnN428J2RUcAjv6GWbctYtulnEY9Gkc4z88Q22PSd6O3
grl9qHg5LZQMHzpnMNOcRs6TBGzZlBHNMrprMPGsKD6ulmBtp5cgQ2heK9bQ
WAHg7dNQ9E+S3ii5MjNoArq6LlbZDOg0dyEFem1VMc3RgVVpvVJNCGYwqWx+
Z+HilaPCalmsFq1ZEO7jWAS26L0MM8FqHPNwnl4xLvzHf/yH87Paz4/DDT8/
rj36pcMTRETbj77cO2px/6iNGe7/FizLo6I7B6DWV15UVI3OXwq84GONeoD3
Wf8/saKb4NsOQBbrHzUA8MXhF4lh0qXA7s3eX5C8XF7Tupvg3Xhc7Vlw1p+f
R985BNhqoo2TIiHiM4WIqruer8NHre4agX10Hs/SInoJESWm1/nLPnIvk+Hp
fDhJr67prTen0DOJe0G/gS1FNkkWl9Aj3qfVisQDPRH13stzTAdxVCJ2TWo/
nqJDL4tPKZRnen0v+rhgppE2l66M+3uy1G4S+Oi+F/bjiNQxKZGiixiOjhuy
V5gaoaaBuI3+BuIsAs1XoTkMjZ+YDJyDBdk+5ZUIz6yA8qZQuZFtFXy2CtjS
gewlI5+6Segg1MrVdeO4aMBVvRCTF8xaGVrAvPMO5j0IWBSrpYzocBGB8ZR3
IvxV4XTaZRMpjLYGgSRws3e7eenrIbt6PR+KISYyREdpAz+wxA1PShTIMoFG
ogpy4Le7EpXRq7D03TYkp6EPK5tz8UTynN0vidaFh/WjVweEZa9KMptniE6R
bM04wERLIrwTqqPnSCMhY3XJrJdeyopLpOP5aOUEaJjBTWVO8Fdv4f6bJSWj
GTDBrLj1vUPIQ0vyewNZAT1oeX2GxSpXNYAGE4tStfVpcYWgKr19/5GYg/JM
KLx0ZxRNzhqUyCuYkKUDF07ghMGqgB3OME/n7MJMp+lSPyDFipQp26Ef31nV
laOow7SagkOL83Jyl0+vETP6tbnY3iGAyEpCSIaKtHV0HVeh44AWcBOXaUF6
88PhoffX3BTZCl7o3iQR7/ZoewRsCbzx/YEFRIxa7CXzmjTS7OQcx/k6qw68
8mYcDdwY7gwHiu+3yaXQ/CAiZom05q/SFkFuSUZrx0Ee0kFu+YNkj02Msxwo
94YjuQmu2GmXXRDjTb5j/jFfMZk5HHQLN8t3/ZTEXPOL8zskS8Mjh9pU1/FN
0j5LPYEUA1Y4Oj6a2PntAuBjbHGHiLuJLSdMxG711rldNNcVX12V7Ilryg4n
I1hiuLHClYs/ld2djiDbi2qpafb6/Qpa7hS056qgNUX8jyz2f1j72SLtAT/E
PVSX4OfwP0c8+IDHM0WkcOO1NZkftvwg/t+O59a1kB8br35vH/8wHPZ+7AfP
/SBLCEf70ni1McmX9getj5qvbn911oBHfflde71n1o5Xt79xrx2vfgk/uAfC
97z6d5zi+799Y40PvoT0+P8zOO8nuxY4A1byxSgbCoufZSM4D8VuUJh8G/Po
WrAZDI4hbW3BY8x+pUBl6h2M+uLlZJbmTHysVvkisSQIf1a+SGG43o4OnGHf
U88b4g1cJ9GPRJWDYuoFWktb/gkh8+QGEWg2EFI4mGIWVy+SO+LJzpQgpRUy
Q22PF2xVBEJhAF0i9GYW8zoxlTSmwcskIx1Y7ENEjFN1Oc1k4oZuoj4msP0E
wQi4EXr0EjxWmhAN/yqCO85VfZ3EiND0JXuw4SFR6AGQDfC1VbYSgKgSE40H
IwXyxfWK9tflI6ftk6TMWagW4uizmTRcifnV1wn9dAAFlbUbzMXKV6djYmCL
9ty1S8HkzCrTthohIBWZAXOmVd9yeLdrI20rTQIpl5LeMgs4SxUug5awjUBH
x2MSYtI5f+90RrSqD1bbQY1HZX5bhnDby2b5OLZHVhGSTJ28rPhYIEGjrGwq
ERoO62IIbAwQx9HdfUtre/qWpVtE6EaunOO0faoeaAOHNIcAbHRca8jQD9nc
D2j+3yanb/uNwd0SbTQ/w7Z4aKfsPotnsxIkWbXyPQj9ORNi0+LVBGSzjzVW
ZSmOxjks1MZqNgabw0zWVjgRGOzAa94BLiiaeecZ/Ati0q5cEoYCkvGVyTDP
kSCV31Gu2bMrIXg843JC8Dm/JEws+ZRKeDBcU5PG+6w3wzhQJ7U6TwnjcqL/
skzJ+t8UaUtd2IQMumUiZlWIU4GfoiN9h/gAQ5tpX13+8Hxz6EdBN5DUCUyl
p9X079vOkpjUczsZJAMxiZ+g/nuZCc+xAojGFhwPj6sqBUKpRweYHMGGQmUe
/TpFTTV7AIh9sL3yMS9us2RG46mBRU/GwgXTRA2sh96s0sAQ2zPxVIPdi4Jj
tw4xBkTktuLxxJFVWvIa4BCvrhFWZzuBhxququprntwfW7I9/LvTpzue7ImO
4d2R9jd9N9rg3S0aIxfhTEXnTIHC1PVXexZRVL401JYvHX+0X/vqPPLYV14L
d/gtr6meWuDk9iPV+7a/+toXN1vhtDX/+ddea27t3td+xARFeEI/6szu867X
dPhC9gYiKUJN/MvG1wgMilQ/Booofz665zU/W/jzldlCvA9/gs+7IfnVn6+9
Fhra9732jT9OBfe0vsZG1xq/MA/9/Jm7vHDEEHHTINc0jq7Eh2ksfQUPL7Hw
JIcDbbvlARYBA97DXizmPxIHRbwLbFd8JPmdqqz4jZNic8lgYk9KCZ4lPnxh
aqsqumVpXpCKwom9yh1z5+IhkwN5n1FrL1gCaXO0Bi52+FQPRDN22ZRSlkMA
m8cIlV6KPdAQUwy0XhwmL/bE9iAZQZpVmcz6ofgYB9x3IMJGzA6kZd3mrCyL
OZSJy9m+IGk7IH0f20o11tdwyXMYgHMJaN/srnMSicYMX2ymprhQFz/OCxLB
3Xs/et+P2F8t70kw4jZCfjUiMpo3agnXFpuOeofjcV8FSZdx+C3U0cJefpGl
SRetbB4m0vdGQjs/dHz7zcO4v2gYJwN/7BqG9r9DwOsYJngPw3yJ1MlWmLn+
DT8/CNfi977YagpjvL9nU8F7ChvP6KM283vDgeuKfw/ZXxS+1zXMl+jV2elh
ILgCkXY2oW++fNMwzdV8cf/7natp/oTDNGHTGuZg1B7m/ehYH27jt//GD0Pv
+9V8b+fYONZg+rUDp5/v1zYVThJ1/Lnpm85hij/Qj6rK9Fs4TPObYm2YHzc7
f3/wcqxzNT8G6PeFDYrib4FNwa9+CUjTVnMuORiiojdg0/GNvbrOKHqc54NU
/TaIN30jsLmP+33bN+tq6NqPIOa9iRI/+sdaX3Ro7WeIs00j0Za+dxhL1Fqm
N0jJ75jri8HzzlDqy/oXX1th1Cbp7hWuD1J8w2NfosO3k6/kXLiZf9zaIib+
HM1OoAuh0VQ0vinS2RZ42XNNPswMVM62EYfpFtjac/tSM8jbzxCXoPE1fQ2u
F7LeS1KVypU03SMB0vxef3WaXKDKSEJ62/iX4L8vFfJxLZLWHIRPLZrFWgxZ
xggKsysK+WgllDln+TtCLpOqWJVTTqK3jFLnVBi4JEfkjIcbqsQIvYTaAhfJ
opglWdXHZIskqRs1ONOMFInMqxZIrKpIcvAyOcfQaj1Q7iR5HPQ4F2K5Io6B
5ndak5SmQ4HTw8UB+4mTmrPwzaDGoDO5vV0GR2Z7xjkNrkSpkSOpvg3VMk0r
dTsOa5Nc+gny7WlAgML0vKt42fRDISX2e6uHrVoFsevOQdJS01qB6iKN6v3x
fkjkCxdZcWUKMCka3mPerqo7rqpV4pYrMWrT8H2FwHMg6A+E+VV6xd41bv14
W5T19Z1WFflyqdL5N1n/RaXaHiqgOIkS6RReI7WIePKJpq/EpQIsx55os1J6
McRfpJdK25xD9pXRYk4sn7Nq4DsfYLGI6cjeQq22TAwwDyYm9AfjdWAiSfFL
Ssuc1xQFrjgQ6pesWuGbobtIU3PkKf4iuVK0pE/lBfdxH7sJgXJ+9IqAgofx
20i3ZInwUbMfmguuc26SpOFEy/gObUwiWRHDQErYIgKEzxNgf3F3Ik90C3da
mHIyzeJ0kSDPmbM+6MxQjMdn7YvWYglf6DPe8WcvHx6fHOHVJHXgaI6yjh62
/9eS58Shm+4lc2rmxYngKxAisJKKpXZmYPrlgsZKncEHZXE7iybM9mZBgmzv
YCKuxe4cqzBtigcN+0QgVeA2vlvfzaOQaTtklRPEi2kORgWLjeaLHb6pw7pJ
oI5bBK5B57NdplkhdSa5JpRpvqkeHNhVPK2/tpHZXR4vCOn08bX9POzYD2sS
0ztO9mmnAfekVgc5b3D1Q7So9xwLW8qbNPGlMITtrX/h+rqQHWt2LG+Ja/ki
JuhlkYpPIMklLdeCG5KQzOLDNXuw4IDtG2ltU9l9SxR8F10kpTYqO/RiNfpO
AlAfkzvUP9LpPTh5N7l4MJB/o7en/Pv50Z/eHZ8fHeL3yevxmzfuF3ti8vr0
3ZtD/5t/E72rjt4eysv0adT66GT8lwcidh+cnqGV1fjNA6G3EFrg11qyKp1U
uSQirlwwidNJXhycoRkgnyUaVhJ18u/oWImyJ2I4A+3VBmcC/8muHVSuxuy1
gWN7Gi/TOs7E7SI+ILjlIVHBgaZEY2BPEN1lcq0kmCdTYIfm5sQzIVXnflH2
wz4fJGATwy+NEDiQqMLWffQ9Bz8W4ozSlLxkxgtJ8zXhztU6NR9xkBHfROqJ
Sx1E/UpZ5Hf0NHv3l9kKmuKc52P2VyaMjc5zIz6wtGR5tUL+Kj9siYO8ci6x
XjLlFvcUzdsI/ajRkafVTolIjBfV50PgHFgiK0goa6iimoppI+LXSyspIK7Y
tcZ8c3MqnERpxrNZqlx1zO2lU+VLnGoa6KDQvOgB0mQPjy6eR/+cX1bLn77l
/616i62to9nhZPy1EY5mHAgeHiD/NjpMr4CTiOznMSts4+wKFczXi62t16+P
L55/+3pekwLDCh2SdulVGuD49+xHRylIcknKXn2HIc5+zxiNt31LkC3s5G8e
hoHbPNIGs3OFJooSYYkJl6EB/x8cQMqDNR0h7RDVZfg9nxVlxfzU2NVBUmq2
YvIASMpFM0Q0OG6UYkoQ1z/EeQRx4AE1XRuMhAtsGV+tvj18VRi3Gmt/JIbV
NMTc1H/efrT7DNXu2AJrtGNRWqSEtwqyox1cRPjIU6g4Gl+oFomGs7/99pOm
jJCUSxONF1bEvCSDzymL4pau04WvLsN3El5EJ+SdmzhbQadLy23EzDW6jcj5
JaR/xSoAz0OgEIBpoPfBn7EAiAn6DUBcchSVQGSiYwE0QB1xqWoHPUhsGy+B
y8gA9IFI/L884GpqPV0Gk/1h5xddFmWJDJUNAOsElGaYD3z9EEMV8jdAHzmW
PAo+EhWzWrJKwgGGzaegOlQv3SZDDLYKWn5wSTuPdFOsptemD0DaXDEuAUiw
HtBAmrUL3S9wxaOZYUyAswYPaSmR+DUP0KA6dQUoahvVdy2k4AUC6HEUNIPQ
3jFhewhfLYSKV6sHqtABxRAqmF3m1ARkhgxmkgJaXq/jCUEjC2XBPajvfTsG
fYzPTvs4VK5gqQrLNYh0xejSoqm43LHyKSZ3GAU3CWllTH2VpUg41JLIkXs7
l8rcWZJx629S3qYfQ6RwAxyEfICnRx5ulTAZMU5cp1fXWp7nDsErwmXgRdzh
uhcoLNozBkqLr/W8LjLRu8siY1J/fTgeEDLS/2BJFqKLs50T9ZqJTpBBIN15
+okprcQbsEjjZaKfSPoFCU/RSPmNeL1lyrGzsiNIYKn1aPDtWSN5p+3LQPsH
6AsIE6nnpqkgN/sMcP4Dm1MKOj+9Vvs470tHnXJH0bfkSrtWq9BHCPopNxyg
E/uFgIfhhaeTxkTYklehn6Mpn9sSjlQjQK7a1FEGOmuSzYfCpdktdnbz2EwF
7r+SSsE+c1ut50R5JRY0kNp/qSihs2X1K3SFSM6Gps+s+0WgZzZnN11eFDQt
6QDCXRHeC5o299h7fdwfeJw6PT94TQsUMGrTHvZMGDbsbz8Sxa4DGmLRx8wd
RG1SBZipVRsOCyLSc6+Pf/IfaD6guBp8aY0L8TL0GDJBCSSMKRxpOmUvVuC+
v9ZDvQtb/ijRaCla4/mZqxvpSWc25aLfxt3YZ6mJVXdpolT9+liMExSnD4Xt
ApIfrc0NgTngsf2IRHY6cxVcWGfivSMB1MSKYDFu3iaYONzgJrsTNTss2w3c
aGfad4nbMbKGNt5EjexhVSvwwYVHyQeCDu1mVOKVG9CmyLznZLfD4aOWVdRX
QbSGlYQxK/RBSkVPk3Qo7X/YcgYMGo4LtoLM5+GBFWzDnEi1mHIOTLStrMiv
fL0TnovRF+nCe3rXbHst5iPuAsnkVCCvRaqulCbaskGkuV+Ol7vMNdZKyewc
atbiXPIdM46+8To7cv1Sqxg5wo+jabQIw7Hs24GMoIm9luTmpkOs4URFgkHo
z/GF1A+1axD4GgZJmvx2DJF0w4VS+NecZdgYc249zIHeQ7H3bAAPQHHLbROU
JPA8F5/3CJtGonDu9zUxAp22dwlWdbLW3II4biV8lRbp/J4T5+UV96w4+Ceu
rVPYlzpsJIqirsNTCUZIJ7PGDrhGkGYSTwBUKKwJD6f5jAQwdtyxBiTNYokD
ZG3fgA/sPZPdCFHREe05H0bjGJtUNG55Yszo3m+Z3ANZNFtCGdcKJrP71hVx
Wxr2erFZpSVG8ScuMQoBwC29AofyScuJTFQ+2t3TvUkmD0G/9ZJ0KJBj3peT
fth5rB3vRY/C86SjCrvzcRo17WLT8amrwgCxthdxrfYm45P+tnQLYeg84i4E
htF+f+oGWS2kYUmAAuMTXqw/b3aF4UIdeZM1NFaomktQMDbaLPHUpSgM3Txb
2BPpAsU05aNujQrvqYgHUwbj6KC8W9Zo7L0kBaihDKqzklfcQ0aq694n3VSr
SLktzFBXJHuLNm8oOXBhQtdKAtvU9Gq2weuUOxMEy5+Gi2FWZIWuLgNdgygf
kzvXryZoq+fztAhIB2ujvXLsduz0s97BqzFrd3qni6qUnYqg6oF6uQtaQEV4
W+XyBZrskVXRsADKBLfKkGiHn1MzkVnGWPMnQE25G59KsriE4GU9lf0VYYxo
lohqZUi+puaENlogKUQta4AXXOFaQBg3J0GzMiR0MaBcMEQg8X0VnAAtu55u
o4k9SbWraxkR4juVjhyoki+mJBkHXgmExJ5JCL1GN0oRadygp6GQcZU/yue1
Vx8njaeILdI2kpmkrjmP6OWd9jbksFv0Mi3p9A7ggZVfJxLKWBa0cgL/WZkM
SdpfJbLkuK7p3ARp2EWyICSSy0rq65K3xrjdWKBacwPUYH+08+ATZOPV1b++
Pm6S3DgKlKmNlhhMsWsysQJb4Dcoa6rTmRkRdA0KrQaLeMJJ3wh76bOXqzSr
LbeSFnW3QD2RHKq6jNSMkEChd5hL2fxmOnW5gx0EK/o6wY2QTjU7yPtba9TU
E+WfjaWG6wMG+wprKVVP63MZ/iqGWZ9oWyhxSMiqm4iuE4Xp+MYgLQ7rVmff
hfn/wd5doMy/xwVexPw1vrUOmkuSB4YfHhhhLiaG/kkYu2vKw8ZgMDNxKzIF
gxouT74dMPbTpJVjGr7JENkQxCiypHWsXQ9eEPa+uGvYgwP7ih1BaGpQ1bpX
0a4DqrHWnjDN1d7u4ELeAWQ+2SInk4kUdiZS2rvWT8j21mA8vORGC7E6og0s
rx13lLpCocEuKnbc2BqADSyRmV+RbSFJRS2YxhjcU1XgJZwkYQeW6fbeqRkc
S8jV4vALsYr01cAhinXo5BIh55xgLv2zqTLkMgQWwztQlxUEIfSJ7lg53/XU
twMmxY95b8oBYXZohw7JbfCcd+MIquhyqZ2MmiyFI5fWgw58H9k58FzllkEM
c4LByKkg4K8O9wkRg70zbvvOEPzOLUcdhbkY9U2LUqvjxa3maHEQJC1YWoPz
ReheJs3NqCalrdDC5iddG8vSj8ltWiU/rXEB4Ogs0bZP6m+A7waNZCJJjwJa
hhMEHaYEX5GyqC1T/Bu11HqtvfWTe4UX6nyJDZZ2bHlF3z6uQfmOxeFlIon2
qBSbBc1NfrJxN04+YNebeb0Er5100AI4Z31bT7yQLIyJAH1oRrj1oSS1Ct0c
78A6Ga86a0ejk/Ff2oepDht+qUOtbJvu7I/19wSCtBoxI2ATkVNRElYCBv7R
n0S9a6+cQeLcLFKlKr541Hx1byOWbhuschuCVkW4rW0JUHKTXAv4aJtcAai1
FtUmdXoz2rYmihVqRVhm53GgGJ67HbGf8jZBWVqlNhiGMvV7wJOD38tSNIic
lpxtFU1WquzKIufxFGoxZpNUEnOmBHEBbWLN++ADe00PIicPVwJcZXCU1iup
5vY2j9SDJDnLi3aiGrgB+2AacQ64p4Xla08+55dQ1WkGMyzlqBStuRa/7tOn
Q7HnkOQQHc1Gjx6RYS/JELv7I2m9ySNe3hmHCG3Vvcf8Ps884P57D+UDjvDV
8WJZ+TrYx/qdTRMyuPumNpGO3Z04oQx733IinRIVW7AbL4UJo5J659x7AhMp
HV4knPVFfJADVU4jPsYU+yNz2pD+y42syoYuxE4xbgZq2FnM58ifbESh5ok4
lZlw5uALgXOXjGqBywbPhHkxsiS/QgF7dMpo67ZqldAJ9wEioOmaAw+X4QDp
GZYOkyw0GZUJb7zGNOyNSkNzbBtwyQ9HF2tuhi3CUfxuYQfmgcN71zSawClh
LJGIYjHmuI9WsfU6LpHJ0JL32pPVrohky5WpsLkGzSZiDA2aa0OD5aZ2zHZA
1q1t+tRR0f/ejZGayy2+gQerZcHOUsGy2HTIVCxEuEbQDgG6QKhWy7Eui8oy
NZUvhxAStxlzuc+fq6l0MSPbRRWigeeiaCFbVda4Tfsy0qrV6Z40Y4GtOKD5
reXl4vImtZY6vCC4CsBdYDtzw1fVwVqcxSvbcGfC751q4IEZPLsvblLiZ7wG
NmpJBR4uiyWX+SOjbyEJU9Nr1jTWir6FNbKdHQo0tf6v4bOmddy306iHCzTE
ikajh4YqzwPjnuS+10QJs1cL4RmZ9O2SpbFjiCOXPAwfUZdA0EB2ah1MGQ+d
YhaYxI3qDOxIyo+8qYxeS/lMumn+5m9nEAEbs9OhlFb8BBdtuulbuEoeVrxM
Z3LZgN5jIf3spINmV3/uwPfESP/KRdmq9NeGd1wd506JCpzqQUtTvguoaW7X
kFKNcEzMl4yQAlzMdWnwFINklqvaJzHKHj1b6jR8XJPhOoylrfmV4lbwTIJk
PLs3jpzddezSxsRsYavNj5m20uY646pI+pfcMh53JBF3Tvc4946tcWUyy+6Y
QF/I8dhyizm41M7AsnTu4JXXh+O+3WwSQMnJF1pyY/3YG+2BDH86jiuElOtu
B5vYskzIYsyKidgIhiq7cPX5r48rCSM2yjlFOWgFeCCH97vCbMlGJ1gTDdgj
xoQ8o1HN5FPysPNkW9/QSthL2BY6cDTq0RuyiKfHu3hEdoWEqHxZa3tFlVTu
vIH4HMYa2usQsT9NdqVYwzYGzlr+POdEfJXHeI2XkyOS9DdNeAnsADZ+uM1N
R4I/dzdsJ/mfnR+/JzWqdWrq4uGueObkWbNBOkg45DpVEiS8ITalamMB7sMB
5YpoQN3QA6dpy1MVRHRqOUtx496SQehn2lTBYD19SLEU0vZr8fCyDNINWYFf
mSKAuxMSYT6EjN0+107OJ0HeVOeVHqIA/nrQtzvH97nEVgeS0s6R75HEv/n/
jwdyzvv6L33KNRryz0j+2XcVGw9F/GnSYYfVdSeSrlkeoh23iaFcSa/R7yxs
o3DsgF0g3lhArxGYKZ1JQ0/wofgmOa/xS2EZh2Niql/ju31YndaqeiDZ+IE2
2TpsG5dBNh7jLsz75EA/Mnw2Rc02oHiqJUoujs6Mi8Z3E4CL/a8vxNIs4TNU
6Gw+3+6rb6jdAXtrg084naOxqZTrizbg235vbJELdRqlD3aLDTerzGWM0Isz
YE7e6DMcN5qJBl2DpD0/W17OL2NuUFbmZBddPcu3260uVSLykryLqXF/KWfC
SDtNZq4dTUG/8wSwgTPfCYKv21nmCwljXpxD6QwAzSZEWgX3TePb6S5TJBbe
RZLNp2jiBL1Fl+jz7XT5eDsul3FfWp9xrh3wKISYeLJYdi2DbTQAR/av7y1l
FtzLPx2+jXovuRfqn1ZkkbBCGRSd9TVuxsmLpmPx6bIj5PwcxKCAPyeNo5z1
zQew+6hR29iBm4r+wHgOZBIJnF2cq+jg4d9PMH4+S369QW7HRNDVT/HQlI7q
PsYDOja/EIFvcnQAQrdNdbxnPaThTk7z60S7aXiuZXYWErdqzsMNOkyF7Ktv
JRw4Nqn1CTVU7ytzx4kEFm2ubAWsdHgvC1SHxjBlB1x2lcTo6kcPkzmaBz4P
OhHiOzAY5StpI1Ly0XCRi+s5qy/0XOsSLKjPORua4nVTfGTvAqhjs1fO5ENT
0blHQHRKVy3U6pKtkvbr8nO1cCV4oZPUQvHA2L+WEUXU77SHbykyfr4mzq3Q
uFle3FldzFb1PK01V9K5Y5AD4/L7g+wEMagJaTgdSy0ZRhlvDoRsIGABgaal
aWMuedBNZUnF/r4bQ4l7lB/vGA3Eil4ApMal9n8J85nkvFa5a92cSziDnZFI
XPfh/lg6nPFe1RJwM6oPxHlz/JxBo0Pl5SGWHll/PkbAn8UwOzy6CN2TsbSw
DHO21sM9DfeP86s1vV3OM+400fh+0gkD6YFJ75IFvUJ+ROZs9+o1nBBX7V3A
x+J39w3r975ep1xgIonFoJVnrl3U312cdIHIe/X9BK4MHGFCaYUUiFd1/Ekw
QaC2rQ7SEAE1iOKe0fI+bgjILSSDKvkDEifhvYyFNJqzG+TE8jS3j+dsGwW/
ZWWFCsC9RKIZjHQwVSXpIv67oCG4xUtnM7Rql9ivXPEmvdNJj5RS19T3E8z4
ZPJovduBFNtAmkzlXrZKc0cu74y5sbOMCwxZ4TuSsmKMeRZWC1iRVtQ7OjsT
Sfvoyf6uL5tOPGxYNxyLGezfOz8cn1m20tNdq858tvt0FPwu/gJ/UdG9IHUJ
RrEm7mrz/kDrCv1UZDXNACwUr8Rl07IVphuWEVtNum8G7+yt0eihu15onOmN
czdJE2n+dkxZcP9eONZydSYMg45b4P6KJNC48CeXw1y8mQByvvoNJszPyeVL
2hB72wH43X2ETcwwFowEbYmuFAd7se2Hd0IR0gRKtuRGWF7RlOiNdIqy6vRk
cI4R+yx8qTzYriV9bEj6TtvVDNzCOM4Q9JoViahioazzWUciZXvwTJbJcjVL
1W/gq7WjGxxuUcx5XIvP+6op/+Sg6aZAllk/IGN/wSTHIa3EY60Il9U1u9Oh
w0LoCRcNsYcYktAX3zqnPTlXgdtW8/hpJnH7s79fELov2j23MSBG70q0/G2l
7IKZcSITIiwS8bEIB/vcuy8z5gWZYSi3B4Z1hLbFRkp7XOtSEOrRQAyXz6tA
MMKj514fI60viL3wOi3AOdAuIcANzRbBBPS4sFS+NcJS6GRUywLHJgPXtrNl
T9lOTHxeFETpWukIaZAFzDIuviPzXC7+4fQBNFu1DhurXEoY2STQm2FCeW71
RPSeBXvcaboASi+MtDF83qj2v/Oedly4+8AGuFdTav4gxOWWmCTx/aYtK9au
ZhFunS6CS2is1Fsm0oH7BnWnAgYdGAxJXANlf1bObmA9QKsdtEBGNP31TP0O
RwMX/tWAbIYIqXbvvrflTfSyceXRhgYb0jGxZdTp0UC5BCouAzHQuucMwCpy
DgU3cy/kEiSJhVmjdUCJJSnSgFxZiAQOfCmdXQDeUVfrRKslQ7A3nCT5ZZq7
RtDeqyn9MTvjzZW7/7vRg3djdgfscI15c6k+M/ue7Lw/aEQqxWIRjn8oJYpx
xrFZkDrsTAd8Vsq4DYduGt2ob+K8lWzrgpPfV+G4IUbB63//8Nq/xRGwXt3C
nnENMqsYDecW5qYdQ6QZpRG3Pq1tNEEFRlNC5ci+5pNR1CGBitSJKhEEb1TG
touGpLq6Lq4SUdp9dNRwxPIzHHBdFS+XOYJefFBRwZh7MLpaZPEIqs+5Nw0X
vEEKDwJMFw27lcdvHXrWkvHETRTehf23urX3xK09GpiT23m3983HbVkgUl3a
2WjHtcVZa7dzbO12WEdZb5VDZId6jTjXe6DMNHaVntbi1RrfM5o1WRAWGGa4
cbdSvkSNG2BLNiLal3ZeGM7pXBxv16b3UOA0ZDALewQJo8CRXxd6GbSags3l
0Hhhz3LRufkObK50j5sXITXfxWKc/sN3MGW+izd7yG7Ff8Uh05m0n1qfDRf0
2mb99fBV4wbeJRBavcvri+AcHX/jtECRzj3LglYtbaD7rmtx4LyIVbkL6s5y
V3aGcAPf+XWKqhf+jPu0sKe5sIRN4eNhXzU+F9dIia2N5ibqogkXI08fzeSE
JpqfMQrwhalThZjHRq/LlptnyafUCjtg/vH9vQiogtEy1jMjVKSwPg2u1xuU
6+fRFfGZGl+ncIhKiXzegKSoD+zknKM8RO5LxB2k3pr96b/k/kDmyNbgbYgL
E7nxvwRem+B02cYSNiy5/YS6GeCBrGpxvYI5u2OZWg2kpLfIhSU+DhOLpzJO
S7bfB+YavuLkUAKAckXx9VawntmC4q32rY5/ig5dw0o7dKEfMynhrLdxdFgz
r/3Nl+b68vXayyWTFnvzoNsf+BExjKmXhvasVBIDYW8A/VIMFK/wsLQFiybh
6UwI15UsMjHh1y/TmxxOzvpIiluuak0uJgzW0V6i0gxBz3G1pn2R/SV1wtZz
jxtkD8ImY9CzGB7GnFlm4RN3rWA0R+8hs9n1XfWWk/LkYu6qk8WtDdLiLZY3
lyaTVcxUTErb9KOpayD8mbsXXXxTHBhgRXDbwe4QV6NZAMH3nOP0XdpNWvEt
lMkOhPWOuwdH0ifXNsFshDMu0PuwlFi92/iAi/iQvxbkbnmomFJkCWCuNlm9
I6WUS7GV5xxebFiHNkDY35I9eU6V5/w9tbVcLj2tlxUrGMBQR7JY7J+kLHE1
iOXWu/kWnFnGjc5dUblAV8gT8OXgKxHoSQAIVtLDlo8A9/L6ruIwrlwZ0uw6
oqaTHcIFVnc6j8YlzBSy3y5Ox31Rrdbua9Y70fWbmqO/LOal7L8yqiSLh/DM
piBoSEGiO5KBqvySb988LcsbXJ+Kdq5XjAeEITP6nkZgMODza3fl6qPTmOx5
MJ4wDhCiT/POWzMTrQUEJ4qhMykdVcnUx10k5ytNoUXjB1Em5RbZVizbWdXo
yz+toEExV3CtEvmzalYt3Y3brCUHG3RFk6xhSQM0DevUzTrFr7U9dGE21xHk
vybJ4pGooXt7A5cvsdfiet7e5O6qLljIJI4ndIhdaWpbe0E4ZOHmnnN8AZlY
ymGjHrrKLlpEEhiccnku61gN3iwxufBYYE82H9HYuTHXllLvQOzsSo5a8e3y
UDZcEx0+HzeIhWskRhxwUPZRNRcg4thFdAY+HsR9aOARXdZOBmlfnaa8MXql
0V/b3Wmp67oIFibkIKnA7sI1d5OCkTlfadB9EZTqz/zXNEOnCAGAmAG4Dgq0
RupHchuMywG+YPuDMIQJnlniijQUMEq8cZVW1yz9VV4gRUI93u3rc3VKyV0L
Fr2GCiwGPSIwLQZowF8Hd4VK6hPbi0EqsbK2KpRS6jVp4yUXITjMbJX2cm8N
0VXWtIjGivTsDLAuqtiCbXCZGhLiC7tpNrybqvHgYdeDOBicBvyh4qSUXAa7
l2zTKcVy86+RaVg+pCjWCDhILq13mB9og1Lzk1t/UzU7RG6wUHCRD2kzx+kF
YoI02xVIwduC9S++QXxDEqNEhNyt36F7gjsIWENXMQ3rZEMz10YRqbYH4iau
g+iMe7ke55HeqzhwmsGg8x7mTaFG5gHaF1s8FeHNIbF62+ZIf+BKznItagjE
Lp2r189j12mpyqd6O+cqevjRQNlKGnrp0MinXdGh4dnQ+TJvDa+Uk7GpoFtA
7R5yC+qOBKS+FiaF25uxn0qqWVqgnyV8W6UUIEUPxuPxg6jX9AUOojGpGZVV
PGhm2q/2p8Tr9KpL/pvsHgm60Htlermy90hU97mEA13NaXAA3eKntk/dv7+3
+0DuXNnY4Mfl0cauNl2blqsQlkRs7UeA6nv/btjWKew6oDbRnA24ns9q8L3L
2I9SX997F/g8u+MWEr7amrjhTFyKjRUGbaCt7NORUaNptbU54E7nOL7rdOma
RnZ3IvOGoGTtMA/oyE4NvNItCFpXlkfKL3gwzadwWn0rTa5JK4GfijR7Xyoh
LZpnjYTJzaPY3eVB3bsbKLjc76sHwl2hjbz6YWsSaeiE2m5hoF5z7ZxT4jks
xUixDi/P9C1CkkqQV0/hzlftej+u6C3GIeNOHsnu5DzJGg2rjy6i18cDbdQg
+kA4AzOmVlORu+emuIsQGeCeen9pPRnCRV4sOOblKnP5GXurUv6MLEuw5qCe
2TczNlTzHb60+kcw6vCtFd4ig0eab1j9Tefmq6QmZONDZkF5fEaPgRu+Pj5D
r1+XAOkyGdDcENdDtm6GnHJBbpK70DTU1FBkibjpnY7O+m1OqTg2OdZshP3R
4z0QLAKUf6VVvB/9ecMrnz+fjN+/IfVc2vxjvwdyuyxbgkh3kef5ggGD4nMp
t5VIrZX/+Mu4VpXWhwNng7aKBNy+5PJVRXbjxJVkTWIsC46s8wtGpLUZFMGj
nsfq/k926KVXbtZevExFedFsnTNE1Wu3P+hBFj7qN6uDw44VWovF0VbLLvCJ
vi4VwSKh1gyRy7PiTTvV5gNMccpXJQP1BQmT6Mhuwey9OPqzsO8XLAmO5CpZ
+ie6WIEa8cTRxX3mYttAZOvtsWlsA5/dI6/ErmFcuaFtFg/wVKzAZ5qTP9J/
Hzmzct+51NtJgHC5CzJ0d3yfWNXygbrgFZWhW1bT3zQUi6KwtaYdUikUNimk
+W9WWa65RsKnXCFRWEdkCYRci63VShYws+b+ZUkWofPosAzG5lZcHy1b4qA/
6UMiJbEcfx2IKz6Ker6HpM3R1S6SdyNltqwaps2rXML+mGFQum+XSqdzTr/V
xo98pwSWzC5DrGMHlaJYLEdE2e+cSzoFy/y7RmqtCydr5WwgkBpOLDaaeOPO
rdexN4TmllKu0hqdi7OgVM7gtoq5E6ma1XJ5AUsoXjFfY+OSUFA2eFFIMdnM
1ZJJVygX+DZvmBplss/1FWhBht9xsx6jcUl1X75stttwoOWWo2VtmVx+vdtI
3sCiJPNv3lqguWeDgKpbD9MNO1salSXWqLfR7jYsO7XEdNuHu/jd8vPbFxO0
KwrhpXb+sFaxodPeOMHsAJcMFIu0spt6pdbNZ1vIoc7QwoSmXMIuRcn14v6B
YYYxP56iFT+7Rm61ITfij5cxF7sVqsgFGGMNTxfQwqVApIpTi8ZLWKVMq4/m
9vItcBhIBfeAulFxhvUHSchLNmym6nGwTGJTvzilFWtu6Pqu5Gyc6a0oYZ1x
Q/sXdcWlptzZt5rPbt9zBk+FvWkOqtA5vmKSdMUs275fn/Rbcen5gXnAHbyq
6E5uT79MXIC+nUCPru5n5tN2rNty48N2ni6vOmiT1azzlD7FaFemXq5K3FxB
5puxfI9JkinqytHD2yxUe8QOWA/E355BF44YvbgwikDWNlenpG5oN9h6XyE3
ZqMxdlqHBLaIXW8zvty7gRIYwIGKWzDFaM79Jok/6s3e7WQli4F6p4y601wb
ViLAIgd6NvKkue82M0/uTke6j7jO62QpETp3XQkio+KbkqZcfCcpzZ0sNXLa
WhKhVcqd6JsJRHYOJrg0uYWZgmQFgOr5ZnfaQ0+flqAPX30u6+FbzhV9rO/F
DCpSCYMMyWLY2IM52Xc0ZxZfPbBUJiQJgdr5VlmOhsVZcGOB5LZ3Q1kw/U+r
OK9Xi+hcm2fVYT9Eh+pl4itNcoLZfI7ou5KQdaOvCyevl0h6/KsOLVoE+0aC
oZEl5PImWAfs8Ga39H0OeBVeG7B0D1MzvmFaKxTyLhKp16lXOXuS4PnFQXM3
IhCHiCntWOHaDkibWbNyxTLWku3blMTWrctdc3eZ8TOzVdnth9pm/ds5laL5
ihMVGLBYwpxz4cPttTaFB7QvX2X6GeK6cDtJl29QbiWOAjLm2Gs256KokDR8
3GumiVl0NiTFEMEKwM5XMv/kYnqYfCK1CW9XKoNK3yqIgzCODWkmmHyiuR9M
1A12CYve36EBB+AUuQ+SpmXg2XDgTMy+O41vBBNilk9zlPorcR1b3xbfuiJL
5hIG0jmRaSG0c5jk2PHp3EXke4cFaUxnnqODfvykdsVhg7MJgt0iDAzSYc0n
Ddq9sfORIQho291IpdYWcJJZfqfXBBFWnb+MfokXsPVN6bccXK6tzBvN54g7
LCO9N9snX0m+Zqzpq35pPnxj0oN5IcEws+J8wpvFsg4DgvRumsxl0MPTie+i
Wal9C6adSaj9OmiG5vfhbJgx3FsYQ4WWzmZ5VpY0vtNMNpaKXVFg5e48flAe
svuGJvpu9M+EI/x24xBhnAUvbW2NmYt0OBgHbhlqHV7GdWA/o4ydUB/Hygn0
7PjVWx+0I7i3r5fZym54atbHMSDizUsQ0+2SPZlNUAQWk90l5lRpqXYN04lT
5SSBl0uNnhd8Z4MPLOvVJ838440N+PoRPNiZXCrJy2HfizZV9DZBWEgtl8B3
WwGmiHwPao3n8NwNBHpxK33amI8Umaxlig+aaeKStsa5KENWOPlDjjy5jKYN
CeB9u91Fb5XQul8utyzkShSE/1zjLkI8ToiY6BWpYBydlwPq1Tolt7SbxZIX
RFugh1uNYH+T3DRLffRNwtjQ6M7DHrQCVZZpWMlYaHYFOz1PPxHvuMO99BcH
wchoXAH/Q6VSdJHOcq6a4T375iB7NO0svpNG7XvPGhG5vWdPdgV6e495NvHG
3ySNeSAnr8XSaczIrog60D65/gJYRjhEZnHp41Q+ixJdlup+u6e4Ak5pQBfj
1oCANwnz6d0gWKDszjpdm44hxZ26HsYeCZy5sbhETnvwWeqPa9hPp1lpCiqj
H2pJMNje9iPbe3vlrgbHbrt1q5KAqSgBr95O2G3vrhWRLk28GPSortOar2aF
CsG/SppjUpC1hOhGJg8E0Vf1FbrLn3xiLIQcz6d6DFufVpqRxzfoo8w5RlHn
jcTzsKA6KDgIMlIFcx89fUwwaCAuA7jsMLNUDT+XxvZWCSmGpst1n0SvoAbl
0p1rqX3BX52RCUX/Y62YXh4u0mlZqO/NEENw2J2SZiUxA7e+yW5P78YuB9Hn
2bmmcNYyXuy8NQzUQJOO3sKNiNs3EAoRx+F70rkMk0fyTXWmSZbxBYJvLo48
gQQYwxeC1r7nZsDJtCsMNEF7Jnzv1rI4w2why99dy5XJu29E1QTiTXP40ikD
lsdpRji5GcfYxUpv34ozsuzFLWv3ihIXhgKMm9/yaaeTtnWP6NbWhoIWnJ7V
PDQvJu25exiCyw8fP3vC3X1Mow6Txq2ltFWT/UIbqCCjeFFrxRscN9rBWVsG
yLYv3NxwJRNDacP1qVzS5Zwa2iczdFc03ltpiZq144M937gWwOw96ONSYl5p
xhfsBA1+BwE8OrVLgWLQ695cBFjCbcHJF9u4OKxRvQFr3E0ZtOWe3i2vUdPz
qTafuYSnuF2KZGXPErdLqfay3g6dc/wiCpRvuN4eVbo7aG9dDxjczycPNMZ0
4RdOPOO26dKblNv6+cX7K5Rjrnsh49I5tW2WHpbkw7HMehR2ECQDXZKbm/vG
NS+g50OqgzK47/naPvncOUC+59O0UGYWM5VaN1TnXot6oogHJZUuH2DQLvvV
GCot+qyBYpKKX0vSwCoX48OHoX0KhyW2JrPnoZ8S0w5dM+cm/w+vYvspfAnl
KEFSSpik8ROggLgphhGdstFfdtb2Y6gW65MwXFOy9lYDKnT6usVWU98rMmPu
1gjywUUcUNi9Dw8CYsuTuEQVuvR8kD7cRf69uhMaU7i8pIBauniCsB+mezH0
rh2DMyd0fAlx0Eowmt/LkmZppbcCaVKYXi3CV0lURgzzDPqntUqU4LTU+Dq2
vc7DrPwumNAZLEgUqiz6tyxuOTpDXGM7elvU1q3ZqS/09NUKdsettSXmIBR6
pi2smKUO+pwNJENahFEwvdNFS85/DXuFttm6pgvbDQF2Ks2+BBay99eVN9LS
2z4PnsPdcE0Sczgc8t2IkJ2nN2COyS1Tyearg/lqKpKuuMErvCKtR5TVZ9GK
C5/JVvw0jLkhjW9GATnM2aXmeX9rxSNj2lNO1JNO5UzkxrJxoyld1Hs7nmir
R1IXiVGp/5LTYTSHNWrwycqbKq5OxeWBKafAqP0oC3x7wSVRLs1K1q38wwQQ
aWambkoRS1pr6RWespduYwuiZ9xzizMsxQQno2nfDExm86PtXX6efUYWnRzt
jnZVRabdfVAgfjidfzhdSiALU7Lxg9oem9ej2MDmF3zhXPR2g17ekzoxbrWA
GIl33ufxC9+e/lLDczgL3ib2A7QVl6OGo5J4sR39XJSkMsohcVHSR3XXEz4R
Z4/LmUJrIt2Oj1ZAbJIhk4930ZiGPrehe5Ojyfi8LxZhIsA/OD0nrZ42ZDXq
biHML/kAVnyfOTi/AmXAnX3YzH43ZCTj5sjsI1RsYleh27RbU3hdmHN1qmQl
tCA6IWw2+yfq4T3tKoG8hxewuhlkjN3Yjd4O7g5aHEQB4rCaG6Aybn5YWSeG
dSRNHZVz4EgJNIgA9gik/a3APgpDJvy3u5TPyEl5jvICKb+3P4wxbKYw2rds
Z0GcsOJk5hZtNhs4hZE9tCviujXfVCYoRPTpkAwUvRlGdiI9OP36ffkea9CM
cNywqlGZaKStXQLVv65BBu/8D4u8gjS4MAnLsnL8Zq2IUJVPc6naBV4giprr
BJE+4bvjN4eNF4VeJLk2jL8D0vzXXGuGVKUeh/6lMwrUOngRJbvTXWbIt9Fy
Tm82T9W9xbFCKTWI5eJmrtjiupg/nh3jojzWVfW2OdxnAH3btRnPralFjLY3
evF08enuHuBwF6O1nUnRg9VrOr87tJqgVJtLdg3hSeWjQc0nwZWTYt06EWPq
AQvbG/nShAIz47RwGKfZuix1NdWR/TnWeS51l33qs8GtCJzBFgngxYzkPmfh
APiKSxNSpAdo0aaBga8olWb2y8g1UsBNccPLOJOCXL6rQ0133ELegEXYilCE
BLg3Ah+aSy60MltJByW8j/a2hpnIjSgsfPymuEUzHnEVNXKbRRwUtVdTDtzd
Z8Rn34zHbw9QaVwiJrQw9UTrYObcq1iZEjNxIsdfE2mg5xw87hKPLpoVtZSn
sUmkZnFVF4s1lSDOLAO9JzolowgM9kutVROqFJ+f4/YeQRpbD9sx8H1Q8C4z
7mlmj6stWkO/y1juC9ZGJDb+NEMTLwfKgHuhOwHXbwdJTXrjzsDVeiv/QOrH
chBpsbXEpnSGAZ+VBM1JapFoIBXo9GJ80hc0ukjAGpCd8FLgc253PECuXbw8
1+onEOw7GveA98GV/jT/qWfvouSFvX+zbMXKnIYJVku5BxurY29oNSVTpEwL
vllDcVkSadAUQOFtTIc7sgJOyH0TOaxdjyHtaI170hEobg8j1yY7PU5SHoh/
cZuRWIIcqaP9TGSdHI5GCw5wRtGLMr4hgXBAZEO8dhAdJlkdCwyPpteFK93L
WXZMwNOr/leTr/1hcw4x30buchR8xtu7cSOWNGg0jfD55F/H+y6kjcO7wdpY
5ZB3oA4dmy5UO4wZks5x0G/SzED9yo5N21JtWbhAAHGjcibBTXcBL4v3BbFI
BJ0xiLibNCEiGcbe6STmu9bE+48fDg+1/IMEGansNZfy/ScRhVjS11DlVZHN
N+EDVq5bb/IW88cLlJOZuRuAPJws5VHlRXIHz/R7Ke5/gyQ9RLN50N6L929O
J9b1DS9b68KpapkIS/4i9zOFKYZfRZ3QzQNBl+uQijTeA7AwEZVqZ1Tpo4UN
DlRscWKApn/oJMAzX24ML72r8mYOnVlgI8yHcptEbNlhTk/FmZS2FiFK6M2T
RclKTYtouJPNSpwpAaO3jk7XbH0m5UJxWvq/YkKS1VkCp4TJMd+WGmGYpNTX
fCtqlvVZYJ42tHhHLYSuZKqPRbSh5bCrO27U4ntndm98OBm+6Edimc+qS81N
5o/93QZwRidh2rBlbJi6f5N6YYgjCxsHNHNrHVo4EwFKunZ5gJ6CBB3iJslQ
apJE+FcDZTo+OJ1wncZod3eXFMGme17u4AWyaU8uX+bJGxP13eXDumB5DQWr
trgdfWN36WmSRpGHYTTXWdsuXFkvCgf/APPIiadwlpekB4rlElfsj1FQy80e
alK4ciMpTL4datGNC7WRVtMeyYwTqREqk5ZtouEcrbl+znztDV8+MW/c782B
291nu9HJ6191bVo1I6267+x645LkbD67xgX3CgAMeVCAaidcxv5zInyLTvUM
LjRUhv8cn/Wbafkwj3ka9hAgj4CjAaQn4uFGPtK7Ma9a9+RzlqxBC6kMyKvh
FMbiFqnJH02hlACV+jule8/KXbYuinW+cnm1XGtFlMPZedpoNsRzMl15mXXs
2tZVSXC4TPtkoUl/kkafojLDohOx76Gxzdw1VxqRFGjYWfjoqk9wCTPo1TEo
tbi5Xj01RSyGhr5iEG/9ofWz9fm57jaZ/eFBXjxQquf2MqpWiw+NXfSaFxLo
nBdk7bC86+kdRtHYOACaCGmiKIpNkWNG4m58ftB3Sj0nh5r3gOOCkTZ4mvn7
xqOfX5lzSPm2rY6ffbn/dHt3BF4gxo5RLJtiid4TM+MsVk4V+Ohsl7Rqdo9k
54QvusKtP5oE7ZK6Z8kyK+7Mm+KvfScC+Mj27ThLPtE7dApnSU3TT1dEA3Wy
RBj15wRINIj+iESK8wKa0Tkx7OjoJiF2eHFNrLoiDaNCtHsQvUcvlbtosrir
suJmEB2V6cfoj0isH0T/Vlzn0WS6ms0w3smKazn+SBKQONIthOh5cYlGLD+n
WQ1We05D59FhnJN2dkvkGEOA0gvEn2imf4+vk9nq119jPDSJSySLMUIBMWlr
mfQnUg4J16+oVUTxy/kqU3F7I54I6QHoAfImJuqirWcadbzW/sZyc6s0OMpM
JU/tql7zPYcjtZdj/dKR5GF3j6MhAz3qGobXXChwMZE+32Kh+eJbS2UNZ0Ey
Eg0EWNELJ+lVTJYZb/ekuI4Ra35RrKbxDGIXw7maLPbCrUr2aXp1UiCVzFKu
sDYpf3sNDY1bamgqSZ7cTrlvK9agt6ULCXg3fGTLDJpj4aI+axo4RtenQ14P
LewI0dv3d/n0owgP+AQZ5BK+Zz6P/Iv/B6K/quAT6gAA

-->
</rfc>