rfc9434xml2.original.xml   rfc9434.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!DOCTYPE rfc [
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.9 (Ruby 2.6
.10) -->
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc ipr="trust200902" docName="draft-ietf-drip-arch-31" category="info" submiss <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.9 (Ruby 2.6.1
ionType="IETF" tocInclude="true" sortRefs="true" symRefs="true"> 0) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-drip-arch-31" number="9434" submissionType="IETF" category="info" consensu
s="true" tocInclude="true" sortRefs="true" symRefs="true" updates="" obsoletes="
" xml:lang="en" version="3">
<!-- xml2rfc v2v3 conversion 3.16.0 -->
<front> <front>
<title abbrev="DRIP Architecture">Drone Remote Identification Protocol (DRIP ) Architecture</title> <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"> <author initials="S." surname="Card" fullname="Stuart W. Card">
<organization>AX Enterprize</organization> <organization>AX Enterprize</organization>
<address> <address>
<postal> <postal>
<street>4947 Commercial Drive</street> <street>4947 Commercial Drive</street>
<city>Yorkville, NY</city> <city>Yorkville</city>
<region>NY</region>
<code>13495</code> <code>13495</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>stu.card@axenterprize.com</email> <email>stu.card@axenterprize.com</email>
</address> </address>
</author> </author>
<author initials="A." surname="Wiethuechter" fullname="Adam Wiethuechter"> <author initials="A." surname="Wiethuechter" fullname="Adam Wiethuechter">
<organization>AX Enterprize</organization> <organization>AX Enterprize</organization>
<address> <address>
<postal> <postal>
<street>4947 Commercial Drive</street> <street>4947 Commercial Drive</street>
<city>Yorkville, NY</city> <city>Yorkville</city>
<region>NY</region>
<code>13495</code> <code>13495</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>adam.wiethuechter@axenterprize.com</email> <email>adam.wiethuechter@axenterprize.com</email>
</address> </address>
</author> </author>
<author initials="R." surname="Moskowitz" fullname="Robert Moskowitz"> <author initials="R." surname="Moskowitz" fullname="Robert Moskowitz">
<organization>HTT Consulting</organization> <organization>HTT Consulting</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city>Oak Park, MI</city> <city>Oak Park</city>
<region>MI</region>
<code>48237</code> <code>48237</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>rgm@labs.htt-consult.com</email> <email>rgm@labs.htt-consult.com</email>
</address> </address>
</author> </author>
<author initials="S." surname="Zhao (Editor)" fullname="Shuai Zhao"> <author initials="S." surname="Zhao" fullname="Shuai Zhao" role="editor">
<organization>Intel</organization> <organization>Intel</organization>
<address> <address>
<postal> <postal>
<street>2200 Mission College Blvd</street> <street>2200 Mission College Blvd.</street>
<city>Santa Clara</city> <city>Santa Clara</city>
<code>95054</code> <code>95054</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>shuai.zhao@ieee.org</email> <email>shuai.zhao@ieee.org</email>
</address> </address>
</author> </author>
<author initials="A." surname="Gurtov" fullname="Andrei Gurtov"> <author initials="A." surname="Gurtov" fullname="Andrei Gurtov">
<organization>Linköping University</organization> <organization>Linköping University</organization>
<address> <address>
<postal> <postal>
<street>IDA</street> <street>IDA</street>
<city>Linköping</city> <city>Linköping</city>
<code>SE-58183 Linköping</code> <code>58183</code>
<country>Sweden</country> <country>Sweden</country>
</postal> </postal>
<email>gurtov@acm.org</email> <email>gurtov@acm.org</email>
</address> </address>
</author> </author>
<date year="2023" month="July"/>
<date year="2023" month="March" day="05"/> <area>int</area>
<area>INT</area>
<workgroup>drip</workgroup> <workgroup>drip</workgroup>
<keyword>Internet-Draft</keyword> <keyword>UAS</keyword>
<keyword>RID</keyword>
<keyword>F3411</keyword>
<keyword>DRIP</keyword>
<keyword>drone</keyword>
<abstract> <abstract>
<t>This document describes an architecture for protocols and services to
<t>This document describes an architecture for protocols and services to support support Unmanned Aircraft System Remote Identification and tracking
Unmanned Aircraft System (UAS) Remote Identification (RID) and tracking, plus U (UAS RID), plus UAS-RID-related communications. This architecture adheres to t
AS RID-related communications. This architecture adheres to the requirements lis he requirements listed in the Drone Remote Identification Protocol (DRIP) Requir
ted in the DRIP Requirements document (RFC 9153).</t> ements document (RFC 9153).</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction">
<section anchor="introduction"><name>Introduction</name> <name>Introduction</name>
<t>This document describes an architecture for protocols and services to
<t>This document describes an architecture for protocols and services to support support Unmanned Aircraft System Remote Identification and tracking
Unmanned Aircraft System (UAS) Remote Identification (RID) and tracking, plus R (UAS RID), plus UAS-RID-related communications. The architecture takes into ac
ID-related communications. The architecture takes into account both current (inc count both current (including proposed) regulations and non-IETF technical stand
luding proposed) regulations and non-IETF technical standards.</t> ards.</t>
<t>The architecture adheres to the requirements listed in the DRIP Require
<t>The architecture adheres to the requirements listed in the DRIP Requirements ments document <xref target="RFC9153"/> and illustrates how all of them can be m
document <xref target="RFC9153"/> and illustrates how all of them can be met, ex et, except for GEN-7 QoS, which is left for future work. The requirements docume
cept for GEN-7 QoS, which is left for future work. The requirements document pro nt provides an extended introduction to the problem space and use cases. Further
vides an extended introduction to the problem space and use cases. Further, this , this architecture document frames the DRIP Entity Tag (DET) <xref target="RFC9
architecture document frames the DRIP Entity Tag (DET) <xref target="I-D.ietf-d 374"/> within the architecture.</t>
rip-rid"/> within the architecture.</t> <section anchor="overview-of-uas-rid-and-its-standardization">
<name>Overview of UAS RID and Its Standardization</name>
<section anchor="overview-of-uas-rid-and-its-standardization"><name>Overview of <t>UAS RID is an application that enables UAS to be identified by UAS Tr
UAS RID and its Standardization</name> affic Management (UTM), UAS Service Suppliers (USS) (<xref target="appendix-a"/>
), and third-party entities, such as law enforcement. Many considerations (e.g.,
<t>UAS RID is an application that enables UAS to be identified by UAS Traffic Ma safety and security) dictate that UAS be remotely identifiable.</t>
nagement (UTM) and UAS Service Suppliers (USS) (<xref target="appendix-a"/>) and <t>Civil Aviation Authorities (CAAs) worldwide are mandating UAS RID. CA
third party entities such as law enforcement. Many considerations (e.g., safety As currently promulgate performance-based regulations that do not specify techni
and security) dictate that UAS be remotely identifiable.</t> ques but rather cite industry consensus technical standards as acceptable means
of compliance.</t>
<t>Civil Aviation Authorities (CAAs) worldwide are mandating UAS RID. CAAs curre <dl newline="true" spacing="normal">
ntly promulgate performance-based regulations that do not specify techniques, bu <dt>USA Federal Aviation Administration (FAA)</dt>
t rather cite industry consensus technical standards as acceptable means of comp <dd>The FAA published a Notice of Proposed Rule Making <xref target="NPR
liance.</t> M"/> in 2019 and thereafter published a "Final Rule" in 2021 <xref target="FAA_
RID"/>, imposing requirements on UAS manufacturers and operators, both commercia
<t>USA Federal Aviation Administration (FAA)</t> l and recreational. The rule states that Automatic Dependent Surveillance Broad
cast (ADS-B) Out and transponders cannot be used to satisfy the UAS RID requirem
<ul empty="true"><li> ents on UAS to which the rule applies (see <xref target="adsb"/>).
<t>The FAA published a Notice of Proposed Rule Making <xref target="NPRM"/> in </dd>
2019 and thereafter published a "Final Rule" in 2021 <xref target="FAA_RID"/>, <dt>European Union Aviation Safety Agency (EASA)</dt>
imposing requirements on UAS manufacturers and operators, both commercial and r <dd>In pursuit of the "U-space" concept of a single European airspace sa
ecreational. The rule states that Automatic Dependent Surveillance Broadcast (A fely shared by manned and unmanned aircraft, the EASA published a <xref target="
DS-B) Out and transponders cannot be used to satisfy the UAS RID requirements on Delegated"/> regulation in 2019, imposing requirements on UAS manufacturers and
UAS to which the rule applies (see <xref target="adsb"/>).</t> third-country operators, including but not limited to UAS RID requirements. The
</li></ul> same year, the EASA also published a regulation <xref target="Implementing"/>, l
aying down detailed rules and procedures for UAS operations and operating person
<t>European Union Aviation Safety Agency (EASA)</t> nel, which then was updated in 2021 <xref target="Implementing_update"/>. A Noti
ce of Proposed Amendment <xref target="NPA"/> was published in 2021 to provide m
<ul empty="true"><li> ore information about the development of acceptable means of compliance and guid
<t>In pursuit of the "U-space" concept of a single European airspace safely sh ance material to support U-space regulations.</dd>
ared by manned and unmanned aircraft, the EASA published a <xref target="Delegat <dt>American Society for Testing and Materials (ASTM)</dt>
ed"/> regulation in 2019 imposing requirements on UAS manufacturers and third-co <dd><t>ASTM International, Technical Committee F38 (UAS), Subcommittee F
untry operators, including but not limited to UAS RID requirements. The same yea 38.02 (Aircraft Operations), Work Item WK65041 developed an ASTM standard <xref
r, EASA also published an <xref target="Implementing"/> regulation laying down d target="F3411-22a"/>, titled "Standard Specification for Remote ID and Tracking"
etailed rules and procedures for UAS operations and operating personnel, which t .</t>
hen was updated in 2021 <xref target="Implementing_update"/>. A Notice of Propos <t>ASTM defines one set of UAS RID information and two means, Media Acce
ed Amendment <xref target="NPA"/> was published in 2021 to provide more informat ss Control (MAC) layer broadcast and IP layer network, of communicating it. If a
ion about the development of acceptable means of compliance and guidance materia UAS uses both communication methods, the same information must be provided via
l to support U-space regulations.</t> both means. <xref target="F3411-22a"/> is the technical standard basis of the Me
</li></ul> ans Of Compliance (MOC) specified in <xref target="F3586-22"/>. The FAA has acce
pted <xref target="F3586-22"/> as a MOC to the FAA's UAS RID Final Rule <xref ta
<t>American Society for Testing and Materials (ASTM)</t> rget="FAA_RID"/>, with some caveats, as per <xref target="MOC-NOA"/>. Other CAAs
are expected to accept the same or other MOCs likewise based on <xref target="F
<ul empty="true"><li> 3411-22a"/>.</t>
<t>ASTM International, Technical Committee F38 (UAS), Subcommittee F38.02 (Air </dd>
craft Operations), Work Item WK65041, developed the ASTM <xref target="F3411-22a <dt>3rd Generation Partnership Project (3GPP)</dt>
"/> Standard Specification for Remote ID and Tracking.</t> <dd>With Release 16, the 3GPP completed the UAS RID requirement study <x
</li></ul> ref target="TR-22.825"/> and proposed a set of use cases in the mobile network a
nd services that can be offered based on UAS RID. The Release 17 study <xref ta
<ul empty="true"><li> rget="TR-23.755"/> and specification <xref target="TS-23.255"/> focus on enhance
<t>ASTM defines one set of UAS RID information and two means, MAC-layer broadc d UAS service requirements and provide the protocol and application architecture
ast and IP-layer network, of communicating it. If an UAS uses both communicatio support that will be applicable for both 4G and 5G networks. The study of Furth
n methods, the same information must be provided via both means. <xref target="F er Architecture Enhancement for Uncrewed Aerial Vehicles (UAV) and Urban Air Mob
3411-22a"/> is the technical standard basis of the <xref target="F3586-22"/> "Me ility (UAM) in Release 18 <xref target="FS_AEUA"/> further enhances the communic
ans Of Compliance" (MOC) accepted by the FAA as per <xref target="MOC-NOA"/> to ation mechanism between UAS and USS/UTM. The DET in <xref target="rid"/> may be
the FAA's UAS RID final rule <xref target="FAA_RID"/> and is expected to be acce used as the 3GPP CAA-level UAS ID for RID purposes.</dd>
pted by some other CAAs.</t> </dl>
</li></ul> </section>
<section anchor="overview-of-types-of-uas-remote-id">
<t>The 3rd Generation Partnership Project (3GPP)</t> <name>Overview of Types of UAS Remote ID</name>
<t>This specification introduces two types of UAS Remote IDs as defined
<ul empty="true"><li> in ASTM <xref target="F3411-22a"/>.</t>
<t>With Release 16, the 3GPP completed the UAS RID requirement study <xref tar <section anchor="brid">
get="TS-22.825"/> and proposed a set of use cases in the mobile network and serv <name>Broadcast RID</name>
ices that can be offered based on UAS RID. The Release 17 study <xref target="T <t><xref target="F3411-22a"/> defines a set of UAS RID messages for di
R-23.755"/> and specification <xref target="TS-23.255"/> focus on enhanced UAS s rect, one-way broadcast transmissions from the Unmanned Aircraft (UA) over Bluet
ervice requirements and provides the protocol and application architecture suppo ooth or Wi-Fi. These are currently defined as MAC layer messages. Internet (or
rt that will be applicable for both 4G and 5G networks. The study of Further Arc other Wide Area Network) connectivity is only needed for UAS registry informatio
hitecture Enhancement for Uncrewed Aerial Vehicles (UAV) and Urban Air Mobility n lookup by Observers using the directly received UAS ID. Broadcast RID should
(UAM) <xref target="FS_AEUA"/> in Release 18 further enhances the communication be functionally usable in situations with no Internet connectivity.</t>
mechanism between UAS and USS/UTM. The DRIP Entity Tag in <xref target="rid"/> m <t>The minimum Broadcast RID data flow is illustrated in <xref target=
ay be used as the 3GPP CAA-level UAS ID for Remote Identification purposes.</t> "brid-fig"/>.</t>
</li></ul> <figure anchor="brid-fig">
<name>Minimum Broadcast RID Data Flow</name>
</section> <artwork><![CDATA[
<section 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 defined in ASTM <xre
f target="F3411-22a"/>.</t>
<section anchor="brid"><name>Broadcast RID</name>
<t><xref target="F3411-22a"/> defines a set of UAS RID messages for direct, one-
way, broadcast transmissions from the UA over Bluetooth or Wi-Fi. These are cur
rently defined as MAC-Layer messages. Internet (or other Wide Area Network) conn
ectivity is only needed for UAS registry information lookup by Observers using t
he directly received UAS ID. Broadcast RID should be functionally usable in sit
uations 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[
+------------------------+ +------------------------+
| Unmanned Aircraft (UA) | | Unmanned Aircraft (UA) |
+-----------o------------+ +-----------o------------+
| |
| app messages directly over | app messages directly over
| one-way RF data link (no IP) | one-way RF data link (no IP)
| |
v v
+------------------o-------------------+ +------------------o-------------------+
| Observer's device (e.g., smartphone) | | Observer's device (e.g., smartphone) |
+--------------------------------------+ +--------------------------------------+
]]></artwork></figure> ]]></artwork>
<t>Broadcast RID provides information only about unmanned aircraft (UA) within d </figure>
irect Radio Frequency (RF) Line-Of-Sight (LOS), typically similar to Visual LOS <t>Broadcast RID provides information only about UA within direct Radi
(VLOS), with a range up to approximately 1 km. This information may be 'harvest o Frequency (RF) Line Of Sight (LOS), typically similar to Visual LOS (VLOS), wi
ed' from received broadcasts and made available via the Internet, enabling surve th a range up to approximately 1 km. This information may be 'harvested' from r
illance of areas too large for local direct visual observation or direct RF link eceived broadcasts and made available via the Internet, enabling surveillance of
-based ID (see <xref target="harvestbridforutm"/>).</t> areas too large for local direct visual observation or direct RF link-based ide
ntification (see <xref target="harvestbridforutm"/>).</t>
</section> </section>
<section anchor="nrid"><name>Network RID</name> <section anchor="nrid">
<name>Network RID</name>
<t><xref target="F3411-22a"/>, using the same data dictionary that is the basis <t><xref target="F3411-22a"/>, using the same data dictionary that is
of Broadcast RID messages, defines a Network Remote Identification (Net-RID) dat the basis of Broadcast RID messages, defines a Network Remote Identification (Ne
a flow as follows.</t> t-RID) data flow as follows.</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The information to be reported via UAS RID is generated by the U
<t>The information to be reported via UAS RID is generated by the UAS. Typical AS. Typically, some of this data is generated by the UA and some by the Ground C
ly some of this data is generated by the UA and some by the GCS (Ground Control ontrol Station (GCS), e.g., their respective locations derived from the Global N
Station), e.g., their respective Global Navigation Satellite System (GNSS) deriv avigation Satellite System (GNSS).</li>
ed locations.</t> <li>The information is sent by the UAS (UA or GCS) via unspecified m
<t>The information is sent by the UAS (UA or GCS) via unspecified means to the eans to the cognizant Network Remote Identification Service Provider (Net-RID SP
cognizant Network Remote Identification Service Provider (Net-RID SP), typicall ), typically the USS under which the UAS is operating if it is participating in
y the USS under which the UAS is operating if participating in UTM.</t> UTM.</li>
<t>The Net-RID SP publishes via the Discovery and Synchronization Service (DSS <li>The Net-RID SP publishes, via the Discovery and Synchronization
) over the Internet that it has operations in various 4-D airspace volumes (Sect Service (DSS) over the Internet, that it has operations in various 4-D airspace
ion 2.2 of <xref target="RFC9153"/>), describing the volumes but not the operati volumes (<xref target="RFC9153" section="2.2" sectionFormat="of" />), describing
ons.</t> the volumes but not the operations.</li>
<t>An Observer's device, which is expected, but not specified, to be web-based <li>An Observer's device, which is expected but not specified to be
, queries a Network Remote Identification Display Provider (Net-RID DP), based on the Web, queries a Network Remote Identification Display Provider (Net-
typically also a USS, about any operations in a specific 4-D airspace volume.</t RID DP),
> typically also a USS, about any operations in a specific 4-D airspace volume.</l
<t>Using fully specified web-based methods over the Internet, the Net-RID DP q i>
ueries all Net-RID SPs that have operations in volumes intersecting that of the <li>Using fully specified Web-based methods over the Internet, the N
Observer's query for details on all such operations.</t> et-RID DP queries all Net-RID SPs that have operations in volumes intersecting t
<t>The Net-RID DP aggregates information received from all such Net-RID SPs an hat of the Observer's query for details on all such operations.</li>
d responds to the Observer's query.</t> <li>The Net-RID DP aggregates information received from all such Net
</list></t> -RID SPs and responds to the Observer's query.</li>
</ul>
<t>The minimum Net-RID data flow is illustrated in <xref target="nrid-fig"/>:</t <t>The minimum Net-RID data flow is illustrated in <xref target="nrid-
> fig"/>:</t>
<figure anchor="nrid-fig">
<figure anchor="nrid-fig"><artwork><![CDATA[ <name>Minimum Net-RID Data Flow</name>
<artwork><![CDATA[
+-------------+ ****************** +-------------+ ******************
| UA | * Internet * | UA | * Internet *
+--o-------o--+ * * +--o-------o--+ * *
| | * * +------------+ | | * * +------------+
| '--------*--(+)-----------*-----o | | '--------*--(+)-----------*-----o |
| * | * | | | * | * | |
| .--------*--(+)-----------*-----o Net-RID SP | | .--------*--(+)-----------*-----o Net-RID SP |
| | * * | | | | * * | |
| | * .------*-----o | | | * .------*-----o |
| | * | * +------------+ | | * | * +------------+
skipping to change at line 199 skipping to change at line 181
| | * | * +------------+ | | * | * +------------+
| | * '------*-----o | | | * '------*-----o |
| | * * | Net-RID DP | | | * * | Net-RID DP |
| | * .------*-----o | | | * .------*-----o |
| | * | * +------------+ | | * | * +------------+
| | * | * | | * | *
| | * | * +------------+ | | * | * +------------+
+--o-------o--+ * '------*-----o Observer's | +--o-------o--+ * '------*-----o Observer's |
| GCS | * * | Device | | GCS | * * | Device |
+-------------+ ****************** +------------+ +-------------+ ****************** +------------+
]]></artwork></figure> ]]></artwork>
</figure>
<t>Command and Control (C2) must flow from the GCS to the UA via some path. Curr <t>Command and Control (C2) must flow from the GCS to the UA via some
ently (in the year 2022) this is typically a direct RF link; however, with incr path. Currently (in the year 2023), this is typically a direct RF link; however,
easing Beyond Visual Line of Sight (BVLOS) operations, it is expected often to b with increasing Beyond Visual Line Of Sight (BVLOS) operations, it is expected
e a wireless link at either end with the Internet between.</t> 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 U
<t>Telemetry (at least the UA's position and heading) flows from the UA to the G A to the GCS via some path, typically the reverse of the C2 path. Thus, UAS RID
CS via some path, typically the reverse of the C2 path. Thus, UAS RID informatio information pertaining to both the GCS and the UA can be sent by whichever has I
n pertaining to both the GCS and the UA can be sent, by whichever has Internet c nternet connectivity to the Net-RID SP, typically the USS managing the UAS opera
onnectivity, to the Net-RID SP, typically the USS managing the UAS operation.</t tion.</t>
> <t>The Net-RID SP forwards UAS RID information via the Internet to sub
scribed Net-RID DPs, typically the USS. Subscribed Net-RID DPs then forward RID
<t>The Net-RID SP forwards UAS RID information via the Internet to subscribed Ne information via the Internet to subscribed Observer devices. Regulations require
t-RID DPs, typically USS. Subscribed Net-RID DPs then forward RID information vi and <xref target="F3411-22a"/> describes UAS RID data elements that must be tra
a the Internet to subscribed Observer devices. Regulations require and <xref tar nsported end to end from the UAS to the subscribed Observer devices.</t>
get="F3411-22a"/> describes UAS RID data elements that must be transported end-t <t><xref target="F3411-22a"/> prescribes the protocols between the Net
o-end from the UAS to the subscribed Observer devices.</t> -RID SP, Net-RID DP, and DSS. It also prescribes data elements (in JSON) betwee
n the Observer and the Net-RID DP. DRIP could address standardization of secure
<t><xref target="F3411-22a"/> prescribes the protocols between the Net-RID SP, N protocols between the UA and the GCS (over direct wireless and Internet connecti
et-RID DP, and the DSS. It also prescribes data elements (in JSON) between the on), between the UAS and the Net-RID SP, and/or between the Net-RID DP and Obser
Observer and the Net-RID DP. DRIP could address standardization of secure protoc ver devices.</t>
ols between the UA and GCS (over direct wireless and Internet connection), betwe <t><em>Neither link-layer protocols nor the use of links (e.g.
en the UAS and the Net-RID SP, and/or between the Net-RID DP and Observer device , the link often existing between the GCS and the UA) for any purpose other than
s.</t> carriage of UAS RID information are in the scope of Network RID <xref target="F
3411-22a"/>.</em></t>
<ul empty="true"><li> </section>
<ul empty="true"><li> </section>
<t>Informative note: Neither link layer protocols nor the use of links (e.g. <section anchor="overview-of-uss-interoperability">
, the link often existing between the GCS and the UA) for any purpose other than <name>Overview of USS Interoperability</name>
carriage of UAS RID information is in the scope of <xref target="F3411-22a"/> N <t>With Net-RID, there is direct communication between each UAS and its
etwork RID.</t> USS. Multiple USS exchange information with the assistance of a DSS so all USS c
</li></ul> ollectively have knowledge about all activities in a 4-D airspace. The interact
</li></ul> ions among an Observer, multiple UAS, and their USS are shown in <xref target="i
nter-uss"/>.</t>
</section> <figure anchor="inter-uss">
</section> <name>Interactions Between Observers, UAS, and USS</name>
<section anchor="overview-of-uss-interoperability"><name>Overview of USS Interop <artwork><![CDATA[
erability</name>
<t>With Net-RID, there is direct communication between each UAS and its USS. Mul
tiple USS exchange information with the assistance of a DSS so all USS collectiv
ely have knowledge about all activities in a 4D airspace. The interactions amon
g an Observer, multiple UAS, and their USS are shown in <xref target="inter-uss"
/>.</t>
<figure anchor="inter-uss"><artwork><![CDATA[
+------+ +----------+ +------+ +------+ +----------+ +------+
| UAS1 | | Observer | | UAS2 | | UAS1 | | Observer | | UAS2 |
+---o--+ +-----o----+ +--o---+ +---o--+ +-----o----+ +--o---+
| | | | | |
******|*************|************|****** ******|*************|************|******
* | | | * * | | | *
* | +---o--+ | * * | +---o--+ | *
* | .------o USS3 o------. | * * | .------o USS3 o------. | *
* | | +--o---+ | | * * | | +--o---+ | | *
* | | | | | * * | | | | | *
* +-o--o-+ +--o--+ +-o--o-+ * * +-o--o-+ +--o--+ +-o--o-+ *
* | o----o DSS o-----o | * * | o----o DSS o-----o | *
* | USS1 | +-----+ | USS2 | * * | USS1 | +-----+ | USS2 | *
* | o----------------o | * * | o----------------o | *
* +------+ +------+ * * +------+ +------+ *
* * * *
* Internet * * Internet *
**************************************** ****************************************
]]></artwork></figure> ]]></artwork>
</figure>
</section> </section>
<section anchor="overview-of-drip-architecture"><name>Overview of DRIP Architect <section anchor="overview-of-drip-architecture">
ure</name> <name>Overview of DRIP Architecture</name>
<t><xref target="arch-intro"/> illustrates a global UAS RID usage scenar
<t><xref target="arch-intro"/> illustrates a global UAS RID usage scenario. Broa io. Broadcast RID links are not shown, as they reach from any UA to any listenin
dcast RID links are not shown as they reach from any UA to any listening receive g receiver in range and thus would obscure the intent of the figure. <xref targe
r in range and thus would obscure the intent of the figure. <xref target="arch-i t="arch-intro"/> shows, as context, some entities and interfaces beyond the scop
ntro"/> shows, as context, some entities and interfaces beyond the scope of DRIP e of DRIP (as currently (2023) chartered). Multiple UAS are shown, each with its
(as currently (2022) chartered). Multiple UAS are shown, each with its own UA c own UA controlled by its own GCS, potentially using the same or different USS,
ontrolled by its own GCS, potentially using the same or different USS, with the with the UA potentially communicating directly with each other (V2V), especially
UA potentially communicating directly with each other (V2V) especially for low l for low-latency, safety-related purposes (DAA).</t>
atency safety related purposes (DAA).</t> <figure anchor="arch-intro">
<name>Global UAS RID Usage Scenario</name>
<figure anchor="arch-intro"><artwork><![CDATA[ <artwork><![CDATA[
*************** *************** *************** ***************
* UAS1 * * UAS2 * * UAS1 * * UAS2 *
* * * * * * * *
* +--------+ * DAA/V2V * +--------+ * * +--------+ * DAA/V2V * +--------+ *
* | UA o--*----------------------------------------*--o UA | * * | UA o--*----------------------------------------*--o UA | *
* +--o--o--+ * * +--o--o--+ * * +--o--o--+ * * +--o--o--+ *
* | | * +------+ Lookups +------+ * | | * * | | * +------+ Lookups +------+ * | | *
* | | * | GPOD o------. .------o PSOD | * | | * * | | * | GPOD o------. .------o PSOD | * | | *
* | | * +------+ | | +------+ * | | * * | | * +------+ | | +------+ * | | *
* | | * | | * | | * * | | * | | * | | *
skipping to change at line 281 skipping to change at line 256
+----------+ | +----------+ +----------+ | +----------+
+--o--+ +--o--+
| DNS | | DNS |
+-----+ +-----+
DAA: Detect And Avoid DAA: Detect And Avoid
GPOD: General Public Observer Device GPOD: General Public Observer Device
PSOD: Public Safety Observer Device PSOD: Public Safety Observer Device
V2I: Vehicle-to-Infrastructure V2I: Vehicle-to-Infrastructure
V2V: Vehicle-to-Vehicle V2V: Vehicle-to-Vehicle
]]></artwork></figure> ]]></artwork>
</figure>
<ul empty="true"><li> <aside>
<t>Informative note: see <xref target="RFC9153"/> for detailed definitions.</t <t>Informative note: See <xref target="RFC9153"/> for detailed defin
> itions.</t>
</li></ul> </aside>
<t>DRIP is meant to leverage existing Internet resources (standard proto
<t>DRIP is meant to leverage existing Internet resources (standard protocols, se cols, services, infrastructures, and business models) to meet UAS RID and closel
rvices, infrastructures, and business models) to meet UAS RID and closely relate y related needs. DRIP will specify how to apply IETF standards, complementing <
d needs. DRIP will specify how to apply IETF standards, complementing <xref tar xref target="F3411-22a"/> and other external standards, to satisfy UAS RID requi
get="F3411-22a"/> and other external standards, to satisfy UAS RID requirements. rements.</t>
</t> <t>This document outlines the DRIP architecture in the context of the UA
S RID architecture. This includes closing the gaps between the CAAs' concepts o
<t>This document outlines the DRIP architecture in the context of the UAS RID ar f operations and <xref target="F3411-22a"/> as it relates to the use of Internet
chitecture. This includes closing the gaps between the CAAs' Concepts of Operat technologies and UA-direct RF communications. Issues include, but are not limit
ions and <xref target="F3411-22a"/> as it relates to the use of Internet technol ed to:</t>
ogies and UA direct RF communications. Issues include, but are not limited to:</ <ul spacing="normal">
t> <li>the design of trustworthy remote identifiers required by GEN-1
(<xref target="rid"/>), especially but not exclusively for use as single-use se
<ul empty="true"><li> ssion IDs,</li>
<t><list style="symbols"> <li>mechanisms to leverage the Domain Name System (DNS) <xref targ
<t>Design of trustworthy remote identifiers required by GEN-1 (<xref target= et="RFC1034"/> for registering and publishing public and private information (se
"rid"/>), especially but not exclusively for use as single-use session IDs.</t> e Sections <xref target="publicinforeg" format="counter"/> and <xref target="pri
</list></t> vateinforeg" format="counter"/>), as required by REG-1 and REG-2,</li>
</li></ul> <li>specific authentication methods and message payload formats to
enable verification that Broadcast RID messages were sent by the claimed sender
<ul empty="true"><li> (<xref target="driptrust"/>) and that the sender is in the claimed DRIP Identit
<t><list style="symbols"> y Management Entity (DIME) (see Sections <xref target="ei" format="counter"/> an
<t>Mechanisms to leverage the Domain Name System (DNS <xref target="RFC1034" d <xref target="driptrust" format="counter"/>), as required by GEN-2,</li>
/>), for registering and publishing public and private information (see <xref ta <li>harvesting Broadcast RID messages for UTM inclusion, with the
rget="publicinforeg"/> and <xref target="privateinforeg"/>) as required by REG-1 optional DRIP extension of Crowdsourced Remote ID (CS-RID) (<xref target="harves
and REG-2.</t> tbridforutm"/>), using the DRIP support for gateways required by GEN-5 <xref tar
</list></t> get="RFC9153"/>,</li>
</li></ul> <li>methods for instantly establishing secure communications betwe
en an Observer and the pilot of an observed UAS (<xref target="dripcontact"/>),
<ul empty="true"><li> using the DRIP support for dynamic contact required by GEN-4 <xref target="RFC91
<t><list style="symbols"> 53"/>, and</li>
<t>Specific authentication methods and message payload formats to enable ver <li>privacy in UAS RID messages (personal data protection) (<xref
ification that Broadcast RID messages were sent by the claimed sender (<xref tar target="privacyforbrid"/>).</li>
get="driptrust"/>) and that the sender is in the claimed DIME (<xref target="ei" </ul>
/> and <xref target="driptrust"/>) as required by GEN-2.</t> <t>This document should serve as a main point of entry into the set
</list></t> of IETF documents addressing the basic DRIP requirements.</t>
</li></ul> </section>
</section>
<ul empty="true"><li> <section anchor="terms-and-definitions">
<t><list style="symbols"> <name>Terms and Definitions</name>
<t>Harvesting Broadcast RID messages for UTM inclusion, with the optional DR <t>
IP extension of Crowd Sourced Remote ID (CS-RID, <xref target="harvestbridforutm The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"/>), using the DRIP support for gateways required by GEN-5 <xref target="RFC915 IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
3"/>.</t> NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
</list></t> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
</li></ul> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
<ul empty="true"><li> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
<t><list style="symbols"> when, and only when, they appear in all capitals, as shown here.
<t>Methods for instantly establishing secure communications between an Obser </t>
ver and the pilot of an observed UAS (<xref target="dripcontact"/>), using the D <t>To encourage comprehension necessary for adoption of DRIP by the intend
RIP support for dynamic contact required by GEN-4 <xref target="RFC9153"/>.</t> ed user community, the UAS community's norms are respected herein.</t>
</list></t> <t>This document uses terms defined in <xref target="RFC9153"/>.</t>
</li></ul> <t>Some of the acronyms have plural forms that remain the same as their si
ngular forms, e.g., "UAS" can expand to "Unmanned Aircraft System" (singular) or
<ul empty="true"><li> "Unmanned Aircraft Systems" (plural), as appropriate for the context. This usa
<t><list style="symbols"> ge is consistent with <xref target="RFC9153" section="2.2" sectionFormat="of" />
<t>Privacy in UAS RID messages (personal data protection) (<xref target="pri .</t>
vacyforbrid"/>).</t> <section anchor="definitionsandabbr">
</list></t> <name>Additional Abbreviations</name>
<dl newline="false" spacing="normal" indent="10">
<t>This document should serve as a main point of entry into the set of IETF do <dt>DET:</dt> <dd>DRIP Entity Tag</dd>
cuments addressing the basic DRIP requirements.</t> <dt>EdDSA:</dt> <dd>Edwards-curve Digital Signature Algorithm</dd>
</li></ul> <dt>HHIT:</dt> <dd>Hierarchical HIT</dd>
<dt>HI:</dt> <dd>Host Identity</dd>
</section> <dt>HIP:</dt> <dd>Host Identity Protocol</dd>
</section> <dt>HIT:</dt> <dd>Host Identity Tag</dd>
<section anchor="terms-and-definitions"><name>Terms and Definitions</name> </dl>
</section>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", <section anchor="additional-definitions">
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this d <name>Additional Definitions</name>
ocument are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <x <t>This section introduces the terms "Claim", "Evidence", "Endorsement",
ref target="RFC8174"/> when, and only when, they appear in all capitals, as show and "Certificate", as used in DRIP. A DRIP certificate has a different context
n here.</t> compared with security certificates and Public Key Infrastructure used in X.509.
</t>
<t>To encourage comprehension necessary for adoption of DRIP by the intended use <dl newline="true" spacing="normal">
r community, the UAS community's norms are respected herein.</t> <dt>Claim:</dt>
<dd>A claim shares the same definition as a claim in Remote ATtestation
<t>This document uses terms defined in <xref target="RFC9153"/>.</t> procedureS (RATS) <xref target="RFC9334"/>; it is a piece of asserted informatio
n, sometimes in the form of a name/value pair. It could also been seen as a pred
<t>Some of the acronyms have plural forms that remain the same as their singular icate (e.g., "X is Y", "X has property Y", and most importantly "X owns Y" or "X
forms, e.g., UAS can expand to Unmanned Aircraft System (singular) or Unmanned is owned by Y").</dd>
Aircraft Systems (plural), as appropriate for the context. This usage is consis <dt>Evidence:</dt>
tent with Section 2.2 of <xref target="RFC9153"/>.</t> <dd>Evidence in DRIP borrows the same definition as in RATS <xref target
="RFC9334"/>, that is, a set of claims.</dd>
<section anchor="definitionsandabbr"><name>Additional Abbreviations</name> <dt>Endorsement:</dt>
<dd>An Endorsement is inspired from RATS <xref target="RFC9334"/>; it is
<t>DET:        DRIP Entity Tag</t> a secure (i.e., signed) statement vouching the integrity and veracity of eviden
ce.</dd>
<t>EdDSA:      Edwards-Curve Digital Signature Algorithm</t> <dt>Certificate:</dt>
<dd>A certificate in DRIP is an endorsement, strictly over identity info
<t>HHIT:       Hierarchical HIT</t> rmation, signed by a third party. This third party should be one with no stake i
n the endorsement over which it is signing.</dd>
<t>HI:         Host Identity</t> <dt>DRIP Identity Management Entity (DIME):</dt>
<dd>A DIME is an entity that performs functions similar to a domain regi
<t>HIP:        Host Identity Protocol</t> strar/registry. A DIME vets Claims and/or Evidence from a registrant and deliver
s back Endorsements and/or Certificates in response. It is a high-level entity i
<t>HIT:        Host Identity Tag</t> n the DRIP registration/provisioning process that can hold the role of HHIT Doma
in Authority (HDA), Registered Assigning Authority (RAA), or root of trust (typi
</section> cally the HHIT prefix owner or DNS apex owner) for DETs.</dd>
<section anchor="additional-definitions"><name>Additional Definitions</name> </dl>
</section>
<t>This section introduces the terms "Claim", "Evidence", "Endorsement", and "Ce </section>
rtificate" as used in DRIP. A DRIP certificate has a different context compared <section anchor="rid">
with security certificates and Public Key Infrastructure used in X.509.</t> <name>HHIT as the DRIP Entity Identifier</name>
<t>This section describes the DRIP architectural approach to meeting the b
<t>Claim:</t> asic requirements of a DRIP entity identifier within the external technical stan
dard ASTM <xref target="F3411-22a"/> and regulatory constraints. It justifies an
<ul empty="true"><li> d explains the use of Hierarchical Host Identity Tags (HHITs) <xref target="RFC9
<t>A claim shares the same definition as a claim in RATS <xref target="RFC9334 374"/> as self-asserting IPv6 addresses suitable as a UAS ID type and, more gene
"/>; it is a piece of asserted information, sometimes in the form of a name/valu rally, as trustworthy multipurpose remote identifiers.</t>
e pair. It could also been seen as a predicate (e.g., "X is Y", "X has property <t>Self-asserting in this usage means that, given the Host Identity (HI),
Y", and most importantly "X owns Y" or "X is owned by Y").</t> the HHIT Overlay Routable Cryptographic Hash IDentifier (ORCHID) construction (s
</li></ul> ee <xref target="RFC9374" section="3.5" sectionFormat="of" />), and a signature
of the DIME on the HHIT and HI, the HHIT can be verified by the receiver as a tr
<t>Evidence:</t> usted UAS ID. The explicit registration hierarchy within the HHIT provides regis
tration discovery (managed by a DIME) to either yield the HI for third-party (s
<ul empty="true"><li> eeking UAS ID endorsement) validation or prove that the HHIT and HI have been re
<t>Evidence in DRIP borrows the same definition as in RATS <xref target="RFC93 gistered uniquely.</t>
34"/>; that is, a set of claims.</t> <section anchor="uas-remote-identifiers-problem-space">
</li></ul> <name>UAS Remote Identifiers Problem Space</name>
<t>A DRIP entity identifier needs to be "Trustworthy" (see DRIP requirem
<t>Endorsement:</t> ents GEN-1, 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 i
<ul empty="true"><li> dentifier claimed therein uniquely belongs to the claimant. To satisfy DRIP requ
<t>An Endorsement is inspired from RATS <xref target="RFC9334"/>; it is a secu irements and maintain important security properties, the DRIP identifier should
re (i.e. signed) statement vouching the integrity and veracity of evidence.</t> be self-generated by the entity it names (e.g., a UAS) and registered (e.g., wit
</li></ul> h a USS; see DRIP requirements GEN-3 and ID-2).</t>
<t>However, Broadcast RID, especially its support for Bluetooth 4, impos
<t>Certificate:</t> es severe constraints. A previous revision of the ASTM UAS RID, <xref target="F3
411-19"/>, allowed a UAS ID of types (1, 2, and 3), each of 20 bytes. <xref targ
<ul empty="true"><li> et="F3411-22a"/> adds type 4, Specific Session ID, for other Standards Developme
<t>A certificate in DRIP is an endorsement, strictly over identity information nt Organizations (SDOs) to extend ASTM UAS RID. Type 4 uses one byte to index th
, signed by a third party. This third party should be one with no stake in the e e Specific Session ID subtype, leaving 19 bytes (see ID-1 of DRIP Requirements <
ndorsement over which it is signing.</t> xref target="RFC9153"/>). As described in <xref target="RFC9153" section="3" sec
</li></ul> tionFormat="of" />, ASTM has allocated Specific Session ID subtype 1 to IETF DRI
P.</t>
<t>DRIP Identity Management Entity (DIME):</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 Au
<ul empty="true"><li> thentication Type 5 for other SDOs (including the IETF) to extend ASTM UAS RID w
<t>An entity that performs functions similar to a domain registrar/registry. A ith Specific Authentication Methods (SAMs). With Type 5, one of the 201 bytes is
DIME vets Claims and/or Evidence from a registrant and delivers back Endorsemen consumed to index the SAM Type, leaving only 200 bytes for DRIP authentication
ts and/or Certificates in response. It is a high-level entity in the DRIP regist payloads, including one or more DRIP entity identifiers and associated authentic
ration/provisioning process that can hold the role of HDA, RAA, or root of trust ation data.</t>
(typically the HHIT prefix owner or DNS apex owner) for DETs.</t> </section>
</li></ul> <section anchor="hhit-as-a-cryptographic-identifier">
<name>HHIT as a Cryptographic Identifier</name>
</section> <t>The only (known to the authors at the time of writing) existing types
</section> of IP-address-compatible identifiers cryptographically derived from the public
<section anchor="rid"><name>HHIT as the DRIP Entity Identifier</name> keys of the identified entities are Cryptographically Generated Addresses (CGAs)
<xref target="RFC3972"/> and Host Identity Tags (HITs) <xref target="RFC7401"/>
<t>This section describes the DRIP architectural approach to meeting the basic r . CGAs and HITs lack registration/retrieval capability. To provide this, each H
equirements of a DRIP entity identifier within external technical standard ASTM HIT embeds plaintext information designating the hierarchy within which it is re
<xref target="F3411-22a"/> and regulatory constraints. It justifies and explains gistered, a cryptographic hash of that information concatenated with the entity'
the use of Hierarchical Host Identity Tags (HHITs) <xref target="I-D.ietf-drip- s public key, etc. Although hash collisions may occur, the DIME can detect them
rid"/> as self-asserting IPv6 addresses suitable as a UAS ID type and, more gene and reject registration requests rather than issue credentials, e.g., by enforci
rally, as trustworthy multipurpose remote identifiers.</t> ng a First Come First Served policy <xref target="RFC8126"/>. Preimage hash atta
cks are also mitigated through this registration process, locking the HHIT to a
<t>Self-asserting in this usage means that given the Host Identity (HI), the HHI specific HI.</t>
T ORCHID construction (see section 3.5 of <xref target="I-D.ietf-drip-rid"/>) an </section>
d a signature of the DIME on the HHIT and HI; the HHIT can be verified by the re <section anchor="hhittrustworthy">
ceiver as a trusted UAS ID. The explicit registration hierarchy within the HHIT <name>HHIT as a Trustworthy DRIP Entity Identifier</name>
provides registration discovery (managed by a DRIP Identity Management Entity (D <t>A Remote UAS ID that can be trustworthy for use in Broadcast RID can
IME)) to either yield the HI for a 3rd-party (seeking UAS ID endorsement) valida be built from an asymmetric key pair. In this method, the UAS ID is cryptographi
tion or prove that the HHIT and HI have been registered uniquely.</t> cally derived directly from the public key. The proof of UAS ID ownership (verif
iable endorsement versus mere claim) is guaranteed by signing this cryptographic
<section anchor="uas-remote-identifiers-problem-space"><name>UAS Remote Identifi UAS ID with the associated private key. The association between the UAS ID and
ers Problem Space</name> 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. T
<t>A DRIP entity identifier needs to be "Trustworthy" (see DRIP Requirement GEN- he public key is designated as the HI, while the UAS ID is designated as the HIT
1, ID-4 and ID-5 in <xref target="RFC9153"/>). This means that given a sufficien .</t>
t collection of UAS RID messages, an Observer can establish that the identifier <t>By construction, the HIT is statistically unique through the mandator
claimed therein uniquely belongs to the claimant. To satisfy DRIP requirements a y use of cryptographic hash functions with second-preimage resistance. The crypt
nd maintain important security properties, the DRIP identifier should be self-ge ographically bound addition of the hierarchy and a HHIT registration process pro
nerated by the entity it names (e.g., a UAS) and registered (e.g., with a USS, s vide complete, global HHIT uniqueness. This registration forces the attacker to
ee Requirements GEN-3 and ID-2).</t> generate the same public key rather than a public key that generates the same HH
IT. This is in contrast to general IDs (e.g., a Universally Unique Identifier (U
<t>However Broadcast RID, especially its support for Bluetooth 4, imposes severe UID) or device serial number) as the subject in an X.509 certificate.</t>
constraints. A previous revision of the ASTM UAS RID, F3411-19, allowed a UAS I <t>A UA equipped for Broadcast RID <bcp14>MUST</bcp14> be provisioned no
D of types (1, 2, and 3), each of 20 bytes. <xref target="F3411-22a"/> adds type t only with its HHIT but also with the HI public key from which the HHIT was der
4, Specific Session ID, for other Standards Development Organizations (SDOs) to ived and the corresponding private key to enable message signature.</t>
extend ASTM UAS RID. Type 4 uses one byte to index the Specific Session ID subt <t>A UAS equipped for DRIP-enhanced Network RID <bcp14>MUST</bcp14> be p
ype, leaving 19 bytes (see ID-1 of DRIP Requirements <xref target="RFC9153"/>). rovisioned likewise; the private key resides only in the ultimate source of Netw
As described in Section 3 of <xref target="RFC9153"/>, ASTM has allocated Specif ork RID messages. If the GCS is the source of the Network RID messages, the GCS
ic Session ID subtype 1 to IETF DRIP.</t> <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, the UA <bcp14>MUST</bcp14>
<t>The maximum ASTM UAS RID Authentication Message payload is 201 bytes each for hold the private key, just as a UA that directly connects to the network rather
Authentication Types 1, 2, 3, and 4. <xref target="F3411-22a"/> adds Authentica than through its GCS.</t>
tion Type 5 for other SDOs (including the IETF) to extend ASTM UAS RID with Spec <t>Each Observer device functioning with Internet connectivity <bcp14>MA
ific Authentication Methods (SAM). With type 5, one of the 201 bytes is consumed Y</bcp14> be provisioned either with public keys of the DRIP identifier root reg
to index the SAM Type, leaving only 200 bytes for DRIP authentication payloads, istries or certificates for subordinate registries; each Observer device that ne
including one or more DRIP entity identifiers and associated authentication dat eds to operate without Internet connectivity at any time <bcp14>MUST</bcp14> be
a.</t> so provisioned.</t>
<t>HHITs can also be used throughout the USS/UTM system. Operators and P
</section> rivate Information Registries, as well as other UTM entities, can use HHITs for
<section anchor="hhit-as-a-cryptographic-identifier"><name>HHIT as a Cryptograph their IDs. Such HHITs can facilitate DRIP security functions, such as those used
ic Identifier</name> with 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 littl
<t>The only (known to the authors at the time of this writing) existing types of e as 88 bytes when Ed25519 <xref target="RFC8032"/> is used by only including th
IP address compatible identifiers cryptographically derived from the public key e 16-byte HHIT, two 4-byte timestamps, and the 64-byte Ed25519 signature.</t>
s of the identified entities are Cryptographically Generated Addresses (CGAs) <x <t>Ed25519 <xref target="RFC8032"/> is used as the HHIT mandatory-to-imp
ref target="RFC3972"/> and Host Identity Tags (HITs) <xref target="RFC7401"/>. lement signing algorithm, as GEN-1 and ID-5 <xref target="RFC9153"/> can best be
CGAs and HITs lack registration/retrieval capability. To provide this, each HHIT met by restricting the HI to 32 bytes. A larger public key would rule out the
embeds plaintext information designating the hierarchy within which it is regis offline endorsement feature that fits within the 200-byte Authentication Message
tered and a cryptographic hash of that information concatenated with the entity' maximum length. Other algorithms that meet this 32-byte constraint can be adde
s public key, etc. Although hash collisions may occur, the DIME can detect them d as deemed needed.</t>
and reject registration requests rather than issue credentials, e.g., by enforci <t>A DRIP identifier can be assigned to a UAS as a static HHIT by its ma
ng a First Come First Served policy. Pre-image hash attacks are also mitigated t nufacturer, such as a single HI and derived HHIT encoded as a hardware serial nu
hrough this registration process, locking the HHIT to a specific HI.</t> mber, per <xref target="CTA2063A"/>. Such a static HHIT <bcp14>SHOULD</bcp14> o
nly be used to bind one-time-use DRIP identifiers to the unique UA. Depending u
</section> pon implementation, this may leave a HI private key in the possession of the man
<section anchor="hhittrustworthy"><name>HHIT as A Trustworthy DRIP Entity Identi ufacturer (see also <xref target="sc"/>).</t>
fier</name> <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
<t>A Remote UAS ID that can be trustworthy for use in Broadcast RID can be built of the UAS ID), even in disconnected environments, by prepopulating small caches
from an asymmetric keypair. In this method, the UAS ID is cryptographically der on Observer devices with DIME public keys and a chain of Endorsements or Certif
ived directly from the public key. The proof of UAS ID ownership (verifiable end icates (tracing a path through the DIME tree). This is assuming all parties on t
orsement, versus mere claim) is guaranteed by signing this cryptographic UAS ID he trust path also use HHITs for their identities.</t>
with the associated private key. The association between the UAS ID and the priv </section>
ate key is ensured by cryptographically binding the public key with the UAS ID; <section anchor="hhitregandlookup">
more specifically, the UAS ID results from the hash of the public key. The publi <name>HHIT for DRIP Identifier Registration and Lookup</name>
c key is designated as the HI while the UAS ID is designated as the HIT.</t> <t>UAS RID needs a deterministic lookup mechanism that rapidly provides
actionable information about the identified UA. Given the size constraints impo
<t>By construction, the HIT is statistically unique through the mandatory use of sed by the Bluetooth 4 broadcast media, the UAS ID itself needs to be a non-spoo
cryptographic hash functions with second-preimage resistance. The cryptographic fable inquiry input into the lookup.</t>
ally-bound addition of the Hierarchy and an HHIT registration process provide co <t>A DRIP registration process based on the explicit hierarchy within a
mplete, global HHIT uniqueness. This registration forces the attacker to generat HHIT provides manageable uniqueness of the HI for the HHIT. The hierarchy is de
e the same public key rather than a public key that generates the same HHIT. Thi fined in <xref target="RFC9374"/> and consists of 2 levels: an RAA and then an H
s is in contrast to general IDs (e.g., a UUID or device serial number) as the su DA. The registration within this hierarchy is the defense against a cryptographi
bject in an X.509 certificate.</t> c hash second-preimage attack on the HHIT (e.g., multiple HIs yielding the same
HHIT; see Requirement ID-3 in <xref target="RFC9153"/>). The First Come First Se
<t>A UA equipped for Broadcast RID MUST be provisioned not only with its HHIT bu rved registration policy is adequate.</t>
t also with the HI public key from which the HHIT was derived and the correspond <t>A lookup of the HHIT into the DIME provides the registered HI for HHI
ing private key, to enable message signature.</t> T proof of ownership and deterministic access to any other needed actionable inf
ormation based on inquiry access authority (more details in <xref target="privat
<t>A UAS equipped for DRIP enhanced Network RID MUST be provisioned likewise; th einforeg"/>).</t>
e private key resides only in the ultimate source of Network RID messages. If th </section>
e GCS is the source of the Network RID messages; the GCS MUST hold the private k </section>
ey. If the UA is the source of the Network RID messages and they are being relay <section anchor="ei">
ed by the GCS; the UA MUST hold the private key, just as a UA that directly conn <name>DRIP Identifier Registration and Registries</name>
ects to the network rather than through its GCS.</t> <t>DRIP registries hold both public and private UAS information (see PRIV-
1 in <xref target="RFC9153"/>) resulting from the DRIP identifier registration p
<t>Each Observer device functioning with Internet connectivity MAY be provisione rocess. Given these different uses, and to improve scalability, security, and s
d either with public keys of the DRIP identifier root registries or certificates implicity of administration, the public and private information can be stored in
for subordinate registries; each Observer device that needs to operate without different registries. This section introduces the public and private informati
Internet connectivity at any time MUST be so provisioned.</t> on registries for DRIP identifiers. In this section, for ease of comprehension,
the registry functions are described (using familiar terminology) without detail
<t>HHITs can also be used throughout the USS/UTM system. Operators and Private I ing their assignment to specific implementing entities (or using unfamiliar jarg
nformation Registries, as well as other UTM entities, can use HHITs for their ID on). Elsewhere in this document, and in forthcoming documents detailing the DRIP
s. Such HHITs can facilitate DRIP security functions such as used with HIP to st registration processes and entities, the more specific term "DRIP Identity Mana
rongly mutually authenticate and encrypt communications.</t> gement Entity" (DIME) will be used. This DRIP identifier registration process sa
tisfies the following DRIP requirements defined in <xref target="RFC9153"/>: GEN
<t>A self-endorsement of a HHIT used as a UAS ID can be done in as little as 88- -3, GEN-4, ID-2, ID-4, ID-6, PRIV-3, PRIV-4, REG-1, REG-2, REG-3, and REG-4.</t>
bytes when Ed25519 <xref target="RFC8032"/> is used by only including the 16-byt <section anchor="publicinforeg">
e HHIT, two 4-byte timestamps, and the 64-byte Ed25519 signature.</t> <name>Public Information Registry</name>
<section anchor="background">
<t>Ed25519 <xref target="RFC8032"/> is used as the HHIT Mandatory to Implement s <name>Background</name>
igning algorithm as <xref target="RFC9153"/> GEN-1 and ID-5 can best be met by r <t>The public information registry provides trustable information, suc
estricting the HI to 32 bytes. A larger public key would rule out the offline e h as endorsements of UAS RID ownership and registration with the HDA. Optionall
ndorsement feature that fits within the 200-byte Authentication Message maximum y, pointers to the registries for the HDA and RAA implicit in the UAS RID can be
length. Other algorithms that meet this 32 byte constraint can be added as deem included (e.g., for HDA and RAA HHIT|HI used in endorsement signing operations)
ed needed.</t> . This public information will be principally used by Observers of Broadcast RI
D messages. Data on UAS that only use Network RID is available via an Observer'
<t>A DRIP identifier can be assigned to a UAS as a static HHIT by its manufactur s Net-RID DP that would directly provide all public registry information. The Ne
er, such as a single HI and derived HHIT encoded as a hardware serial number per t-RID DP is the only source of information for a query on an airspace volume.</t
<xref target="CTA2063A"/>. Such a static HHIT SHOULD only be used to bind one- >
time use DRIP identifiers to the unique UA. Depending upon implementation, this <aside><t>Note: In the above paragraph, | signifies concatenation of in
may leave a HI private key in the possession of the manufacturer (see also <xre formation, e.g., X | Y is the concatenation of X
f target="sc"/>).</t> and Y.</t></aside>
</section>
<t>In general, Internet access may be needed to validate Endorsements or Certifi <section anchor="public-drip-identifier-registry">
cates. This may be obviated in the most common cases (e.g., endorsement of the U <name>Public DRIP Identifier Registry</name>
AS ID), even in disconnected environments, by pre-populating small caches on Obs <t>A DRIP identifier <bcp14>MUST</bcp14> be registered as an Internet
erver devices with DIME public keys and a chain of Endorsements or Certificates domain name (at an arbitrary level in the hierarchy, e.g., in .ip6.arpa). Thus,
(tracing a path through the DIME tree). This is assuming all parties on the trus the DNS can provide all the needed public DRIP information. A standardized HHIT
t path also use HHITs for their identities.</t> Fully Qualified Domain Name (FQDN) can deliver the HI via a HIP Resource Record
(RR) <xref target="RFC8005"/> and other public information (e.g., RAA and HDA P
</section> TRs and HIP Rendezvous Servers (RVSs) <xref target="RFC8004"/>). These public in
<section anchor="hhitregandlookup"><name>HHIT for DRIP Identifier Registration a formation registries can use DNSSEC to deliver public information that is not in
nd Lookup</name> herently trustable (e.g., everything other than endorsements).</t>
<t>This DNS entry for the HHIT can also provide a revocation service.
<t>UAS RID needs a deterministic lookup mechanism that rapidly provides actionab For example, instead of returning the HI RR, it may return some record showing
le information about the identified UA. Given the size constraints imposed by t that the HI (and thus HHIT) has been revoked.</t>
he Bluetooth 4 broadcast media, the UAS ID itself needs to be a non-spoofable in </section>
quiry input into the lookup.</t> </section>
<section anchor="privateinforeg">
<t>A DRIP registration process based on the explicit hierarchy within a HHIT pro <name>Private Information Registry</name>
vides manageable uniqueness of the HI for the HHIT. The hierarchy is defined in <section anchor="background-1">
<xref target="I-D.ietf-drip-rid"/> and consists of 2-levels, a Registered Assig <name>Background</name>
ning Authority (RAA) and then a Hierarchical HIT Domain Authority (HDA). The reg <t>The private information required for DRIP identifiers is similar to
istration within this hierarchy is the defense against a cryptographic hash seco that required for Internet domain name registration. A DRIP identifier solutio
nd pre-image attack on the HHIT (e.g., multiple HIs yielding the same HHIT, see n can leverage existing Internet resources, i.e., registration protocols, infras
Requirement ID-3 in <xref target="RFC9153"/>). The First Come First Served regis tructure, and business models, by fitting into a UAS ID structure compatible wit
tration policy is adequate.</t> h DNS names. The HHIT hierarchy can provide the needed scalability and manageme
nt structure. It is expected that the private information registry function will
<t>A lookup of the HHIT into the DIME provides the registered HI for HHIT proof be provided by the same organizations that run a USS and likely integrated with
of ownership and deterministic access to any other needed actionable information a USS. The lookup function may be implemented by the Net-RID DPs.</t>
based on inquiry access authority (more details in <xref target="privateinforeg </section>
"/>).</t> <section anchor="information-elements">
<name>Information Elements</name>
</section> <t>When a DET is used as a UA's Session ID, the corresponding manufact
</section> urer-assigned serial number <bcp14>MUST</bcp14> be stored in a private informati
<section anchor="ei"><name>DRIP Identifier Registration and Registries</name> on registry that can be identified uniquely from the DET. When a DET is used as
either a UA's Session ID or a UA's manufacturer-assigned serial number, and the
<t>DRIP registries hold both public and private UAS information (see PRIV-1 in < operation is being flown under UTM, the corresponding UTM-system-assigned Operat
xref target="RFC9153"/>) resulting from the DRIP identifier registration process ional Intent Identifier <bcp14>SHOULD</bcp14> be so stored. Other information <b
. Given these different uses, and to improve scalability, security, and simplic cp14>MAY</bcp14> be stored as such, and often must, to satisfy CAA regulations o
ity of administration, the public and private information can be stored in diffe r USS operator policies.</t>
rent registries. This section introduces the public and private information reg </section>
istries for DRIP identifiers. This DRIP Identifier registration process satisfie <section anchor="private-drip-identifier-registry-methods">
s the following DRIP requirements defined in <xref target="RFC9153"/>: GEN-3, GE <name>Private DRIP Identifier Registry Methods</name>
N-4, ID-2, ID-4, ID-6, PRIV-3, PRIV-4, REG-1, REG-2, REG-3 and REG-4.</t> <t>A DRIP private information registry supports essential registry ope
rations (e.g., add, delete, update, and query) using interoperable open standard
<section anchor="publicinforeg"><name>Public Information Registry</name> protocols. It can accomplish this by leveraging aspects of the Extensible Provi
sioning Protocol (EPP) <xref target="RFC5730"/> and the Registry Data Access Pro
<section anchor="background"><name>Background</name> tocol (RDAP) <xref target="RFC7480"/> <xref target="RFC9082"/> <xref target="RFC
9083"/>. The DRIP private information registry in which a given UAS is register
<t>The public information registry provides trustable information such as endors ed needs to be findable, starting from the UAS ID, using the methods specified i
ements of UAS RID ownership and registration with the HDA (Hierarchical HIT Doma n <xref target="RFC9224"/>.</t>
in Authority). Optionally, pointers to the registries for the HDA and RAA (Regis </section>
tered Assigning Authority) implicit in the UAS RID can be included (e.g., for HD <section anchor="alternative-private-drip-registry-methods">
A and RAA HHIT|HI used in endorsement signing operations). This public informa <name>Alternative Private DRIP Registry Methods</name>
tion will be principally used by Observers of Broadcast RID messages. Data on U <t>A DRIP private information registry might be an access-controlled D
AS that only use Network RID, is available via an Observer's Net-RID DP that wou NS (e.g., via DNS over TLS). Additionally, WebFinger <xref target="RFC7033"/> c
ld directly provide all public registry information. The Net-RID DP is the only an be supported. These alternative methods may be used by a Net-RID DP with spec
source of information for a query on an airspace volume.</t> ific customers.</t>
</section>
</section> </section>
<section anchor="public-drip-identifier-registry"><name>Public DRIP Identifier R </section>
egistry</name> <section anchor="driptrust">
<name>DRIP Identifier Trust</name>
<t>A DRIP identifier MUST be registered as an Internet domain name (at an arbitr <t>While the DRIP entity identifier is self-asserting, it alone does not p
ary level in the hierarchy, e.g., in .ip6.arpa). Thus DNS can provide all the ne rovide the trustworthiness (i.e., non-repudiation, protection vs. spoofing, mess
eded public DRIP information. A standardized HHIT FQDN (Fully Qualified Domain age integrity protection, scalability, etc.) essential to UAS RID, as justified
Name) can deliver the HI via a HIP RR (Resource Record) <xref target="RFC8005"/> in <xref target="RFC9153"/>. For that, it <bcp14>MUST</bcp14> be registered (und
and other public information (e.g., RAA and HDA PTRs, and HIP RVS (Rendezvous S er DRIP registries) and actively used by the party (in most cases the UA). A se
ervers) <xref target="RFC8004"/>). These public information registries can use D nder's identity cannot be proved merely by its possessing of a DRIP Entity Tag (
NSSEC to deliver public information that is not inherently trustable (e.g., ever DET) and broadcasting it as a claim that it belongs to that sender. Sending dat
ything other than endorsements).</t> a 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
<t>This DNS entry for the HHIT can also provide a revocation service. For examp signature on novel (i.e., frequently changing and unpredictable) data that can b
le, instead of returning the HI RR it may return some record showing that the HI e externally validated by the Observer (such as a signed Location/Vector message
(and thus HHIT) has been revoked.</t> that matches actually seeing the UA at the location and time reported in the si
gned message) proves that the observed UA possesses the private key and thus the
</section> claimed UAS ID.</t>
</section> <t>The severe constraints of Broadcast RID make it challenging to satisfy
<section anchor="privateinforeg"><name>Private Information Registry</name> 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,
<section anchor="background-1"><name>Background</name> it is possible to establish levels of trust in the asserted information and the
operator.</t>
<t>The private information required for DRIP identifiers is similar to that requ <t>A combination of different DRIP Authentication Messages enables an Obse
ired for Internet domain name registration. A DRIP identifier solution can leve rver, without Internet connection (offline) or with (online), to validate a UAS
rage existing Internet resources: registration protocols, infrastructure, and bu DRIP ID in real time. Some messages must contain the relevant registration of t
siness models, by fitting into a UAS ID structure compatible with DNS names. Th he UA's DRIP ID in the claimed DIME. Some messages must contain sender signatur
e HHIT hierarchy can provide the needed scalability and management structure. It es over both static (e.g., registration) and dynamically changing (e.g., current
is expected that the private information registry function will be provided by UA location) data. Combining these two sets of information, an Observer can pi
the same organizations that run a USS, and likely integrated with a USS. The lo ece together a chain of trust, including real-time evidence to make a determinat
okup function may be implemented by the Net-RID DPs.</t> ion on the UA's claims.</t>
<t>This process (combining the DRIP entity identifier, registries, and aut
</section> hentication formats for Broadcast RID) can satisfy the following DRIP requiremen
<section anchor="information-elements"><name>Information Elements</name> ts defined in <xref target="RFC9153"/>: GEN-1, GEN-2, GEN-3, ID-2, ID-3, ID-4, a
nd ID-5.</t>
<t>When a DET is used as a UA's Session ID, the corresponding manufacturer assig </section>
ned serial number MUST be stored in a Private Information Registry that can be i <section anchor="harvestbridforutm">
dentified uniquely from the DET. When a DET is used as either as UA's Session ID <name>Harvesting Broadcast Remote ID Messages for UTM Inclusion</name>
or as a UA's manufacturer assigned serial number, and the operation is being fl <t>ASTM anticipated that regulators would require both Broadcast RID and N
own under UTM, the corresponding UTM system assigned Operational Intent Identifi etwork RID for large UAS but allow UAS RID requirements for small UAS to be sati
er SHOULD be so stored. Other information MAY be so stored, and often must to sa sfied with the operator's choice of either Broadcast RID or Network RID. The EA
tisfy CAA regulations or USS operator policies.</t> SA initially specified Broadcast RID for essentially all UAS and is now also con
sidering Network RID. The FAA UAS RID Final Rules <xref target="FAA_RID"/> perm
</section> it only Broadcast RID for rule compliance but still encourage Network RID for co
<section anchor="private-drip-identifier-registry-methods"><name>Private DRIP Id mplementary functionality, especially in support of UTM.</t>
entifier Registry Methods</name> <t>One opportunity is to enhance the architecture with gateways from Broad
cast RID to Network RID. This provides the best of both and gives regulators and
<t>A DRIP private information registry supports essential registry operations (e operators flexibility. It offers advantages over either form of UAS RID alone,
.g., add, delete, update, query) using interoperable open standard protocols. It i.e., greater fidelity than Network RID reporting of <xref target="FAA_RID"/> p
can accomplish this by leveraging aspects of Extensible Provisioning Protocol ( lanned area operations, together with surveillance of areas too large for local
EPP <xref target="RFC5730"/>) and the Registry Data Access Protocol (RDAP <xref direct visual observation and direct Radio Frequency Line Of Sight (RF-LOS) link
target="RFC7480"/> <xref target="RFC9082"/> <xref target="RFC9083"/>). The DRIP -based Broadcast RID (e.g., a city or a national forest).</t>
private information registry in which a given UAS is registered needs to be fin <t>These gateways could be pre-positioned (e.g., around airports, public g
dable, starting from the UAS ID, using the methods specified in <xref target="RF atherings, and other sensitive areas) and/or crowdsourced (as nothing more than
C9224"/>.</t> a smartphone with a suitable app is needed). Crowdsourcing can be encouraged by
quid pro quo, providing CS-RID Surveillance Supplemental Data Service Provider
</section> (SDSP) outputs only to CS-RID Finders. As Broadcast RID media have a limited ran
<section anchor="alternative-private-drip-registry-methods"><name>Alternative Pr ge, messages claiming sender (typically UA) locations far from a physical layer
ivate DRIP Registry Methods</name> receiver thereof ("Finder" below, typically Observer device) should arouse suspi
cion of possible intent to deceive; a fast and computationally inexpensive consi
<t>A DRIP private information registry might be an access-controlled DNS (e.g., stency check can be performed (by the Finder or the Surveillance SDSP) on applic
via DNS over TLS). Additionally, WebFinger <xref target="RFC7033"/> can be supp ation layer data present in the gateway (claimed UA location vs physical receive
orted. These alternative methods may be used by Net-RID DP with specific custome r location), and authorities can be alerted to failed checks. CS-RID SDSPs can u
rs.</t> se messages with precise date/time/position stamps from the gateways to multilat
erate UA locations, independent of the locations claimed in the messages, which
</section> are entirely self-reported by the operator in UAS RID and UTM, and thus are subj
</section> ect not only to natural time lag and error but also operator misconfiguration or
</section> intentional deception.</t>
<section anchor="driptrust"><name>DRIP Identifier Trust</name> <t>Multilateration technologies use physical layer information, such as pr
ecise Time Of Arrival (TOA) of transmissions from mobile transmitters at receive
<t>While the DRIP entity identifier is self-asserting, it alone does not provide rs with a priori precisely known locations, to estimate the locations of the mob
the trustworthiness (non-repudiation, protection vs spoofing, message integrity ile transmitters.</t>
protection, scalability, etc.) essential to UAS RID, as justified in <xref targ <t>Further, gateways with additional sensors (e.g., smartphones with camer
et="RFC9153"/>. For that it MUST be registered (under DRIP Registries) and be ac as) can provide independent information on the UA type and size, confirming or r
tively used by the party (in most cases the UA). A sender's identity cannot be efuting those claims made in the UAS RID messages.</t>
proved merely by its possessing a DRIP Entity Tag (DET) and broadcasting it as a <t>Sections <xref target="csridfinder" format="counter"/> and <xref target
claim that it belongs to that sender. Sending data signed using that HI's priv ="csridsdsp" format="counter"/> define two additional entities that are required
ate key proves little, as it is subject to trivial replay attacks using previous to provide this Crowdsourced Remote ID (CS-RID).</t>
ly broadcast messages. Only sending the DET and a signature on novel (i.e., fre <t>This approach satisfies the following DRIP requirements defined in <xre
quently changing and unpredictable) data that can be externally validated by the f target="RFC9153"/>: GEN-5, GEN-11, and REG-1. As Broadcast messages are inhere
Observer (such as a signed Location/Vector message, matching actually seeing th ntly multicast, GEN-10 is met for local-link multicast to multiple Finders (this
e UA at the location and time reported in the signed message) proves that the ob is how multilateration is possible).</t>
served UA possesses the private key and thus the claimed UAS ID.</t> <section anchor="csridfinder">
<name>The CS-RID Finder</name>
<t>The severe constraints of Broadcast RID make it challenging to satisfy UAS RI <t>A CS-RID Finder is the gateway for Broadcast Remote ID Messages into
D requirements. From received Broadcast RID messages and information that can be UTM. It performs this gateway function via a CS-RID SDSP. A CS-RID Finder coul
looked up using the received UAS ID in online registries or local caches, it is d implement, integrate, or accept outputs from a Broadcast RID receiver. Howeve
possible to establish levels of trust in the asserted information and the Opera r, it should not depend upon a direct interface with a GCS, Net-RID SP, Net-RID
tor.</t> DP, or Net-RID client. It would present a new interface to a CS-RID SDSP, simil
ar to but readily distinguishable from that which a UAS (UA or GCS) presents to
<t>A combination of different DRIP Authentication Messages enables an Observer, a Net-RID SP.</t>
without Internet connection (offline) or with (online), to validate a UAS DRIP I </section>
D in real-time. Some messages must contain the relevant registration of the UA' <section anchor="csridsdsp">
s DRIP ID in the claimed DIME. Some messages must contain sender signatures ove <name>The CS-RID SDSP</name>
r both static (e.g., registration) and dynamically changing (e.g., current UA lo <t>A CS-RID SDSP aggregates and processes (e.g., estimates UA locations
cation) data. Combining these two sets of information, an Observer can piece to using multilateration when possible) information collected by CS-RID Finders. A
gether a chain of trust including real-time evidence to make a determination on CS-RID SDSP should present the same interface to a Net-RID SP as it does to a Ne
the UA's claims.</t> t-RID DP and to a Net-RID DP as it does to a Net-RID SP, but its data source mus
t be readily distinguishable via Finders rather than direct from the UAS itself.
<t>This process (combining the DRIP entity identifier, registries, and authentic </t>
ation formats for Broadcast RID) can satisfy the following DRIP requirements def </section>
ined in <xref target="RFC9153"/>: GEN-1, GEN-2, GEN-3, ID-2, ID-3, ID-4, and ID- </section>
5.</t> <section anchor="dripcontact">
<name>DRIP Contact</name>
</section> <t>One of the ways in which DRIP can enhance <xref target="F3411-22a"/> wi
<section anchor="harvestbridforutm"><name>Harvesting Broadcast Remote ID message th immediately actionable information is by enabling an Observer to instantly in
s for UTM Inclusion</name> itiate secure communications with the UAS remote pilot, Pilot In Command, operat
or, USS under which the operation is being flown, or other entity potentially ab
<t>ASTM anticipated that regulators would require both Broadcast RID and Network le to furnish further information regarding the operation and its intent and/or
RID for large UAS, but allow UAS RID requirements for small UAS to be satisfied to immediately influence further conduct or termination of the operation (e.g.,
with the operator's choice of either Broadcast RID or Network RID. The EASA in land or otherwise exit an airspace volume). Such potentially distracting communi
itially specified Broadcast RID for essentially all UAS, and is now also conside cations demand strong "AAA" (Authentication, Attestation, Authorization, Access
ring Network RID. The FAA UAS RID Final Rules <xref target="FAA_RID"/> permit o Control, Accounting, Attribution, Audit), per applicable policies (e.g., of the
nly Broadcast RID for rule compliance, but still encourage Network RID for compl cognizant CAA).</t>
ementary functionality, especially in support of UTM.</t> <t>A DRIP entity identifier based on a HHIT, as outlined in <xref target="
rid"/>, embeds an identifier of the DIME in which it can be found (expected typi
<t>One opportunity is to enhance the architecture with gateways from Broadcast R cally to be the USS under which the UAS is flying), and the procedures outlined
ID to Network RID. This provides the best of both and gives regulators and opera in <xref target="driptrust"/> enable Observer verification of that relationship.
tors flexibility. It offers advantages over either form of UAS RID alone: great A DRIP entity identifier with suitable records in public and private registries
er fidelity than Network RID reporting of planned area operations; surveillance , as outlined in <xref target="driptrust"/>, can enable lookup not only of infor
of areas too large for local direct visual observation and direct RF-LOS link ba mation regarding the UAS but also identities of and pointers to information rega
sed Broadcast RID (e.g., a city or a national forest).</t> rding the various associated entities (e.g., the USS under which the UAS is flyi
ng an operation), including means of contacting those associated entities (i.e.,
<t>These gateways could be pre-positioned (e.g., around airports, public gatheri locators, typically IP addresses).</t>
ngs, and other sensitive areas) and/or crowd-sourced (as nothing more than a sma <t>A suitably equipped Observer could initiate a secure communication chan
rtphone with a suitable app is needed). Crowd-sourcing can be encouraged by qui nel, using the DET HI, to a similarly equipped and identified entity, i.e., the
d pro quo, providing CS-RID Surveillance Supplemental Data Service Provider (SDS UA itself, if operating autonomously; the GCS, if the UA is remotely piloted and
P) outputs only to CS-RID Finders. As Broadcast RID media have limited range, ga the necessary records have been populated in the DNS; the USS; etc. Assuming se
teways receiving messages claiming locations far from the gateway can alert auth cure communication setup (e.g., via IPsec or HIP), arbitrary standard higher-lay
orities or a Surveillance SDSP to the failed sanity check possibly indicating in er protocols can then be used for Observer to Pilot (O2P) communications (e.g.,
tent to deceive. CS-RID SDSPs can use messages with precise date/time/position s SIP <xref target="RFC3261"/> et seq), Vehicle to Everything (V2X) (or more speci
tamps from the gateways to multilaterate UA location, independent of the locatio fically Aircraft to Anything (A2X)) communications (e.g., <xref target="MAVLink"
ns claimed in the messages, which are entirely operator self-reported in UAS RID />), etc.
and UTM, and thus are subject not only to natural time lag and error but also o Certain preconditions are necessary: 1) each party needs a currently usable
perator misconfiguration or intentional deception.</t> means (typically a DNS) of resolving the other party's DRIP entity
identifier to a currently usable locator (IP address), and 2) there must
<t>Multilateration technologies use physical layer information, such as precise be currently usable bidirectional IP connectivity (not necessarily
Time Of Arrival (TOA) of transmissions from mobile transmitters at receivers wit via the Internet) between the parties. One method directly supported by the use
h a priori precisely known locations, to estimate the locations of the mobile tr of HHITs as DRIP entity identifiers is initiation of a HIP Base Exchange (BEX) a
ansmitters.</t> nd Bound End-to-End Tunnel (BEET).</t>
<t>This approach satisfies DRIP requirement GEN-6 Contact, supports satisf
<t>Further, gateways with additional sensors (e.g., smartphones with cameras) ca action of DRIP requirements GEN-8, GEN-9, PRIV-2, PRIV-5, and REG-3 <xref target
n provide independent information on the UA type and size, confirming or refutin ="RFC9153"/>, and is compatible with all other DRIP requirements.</t>
g those claims made in the UAS RID messages.</t> </section>
<section anchor="iana">
<t><xref target="csridfinder"/> and <xref target="csridsdsp"/> define two additi <name>IANA Considerations</name>
onal entities that are required to provide this Crowd Sourced Remote ID (CS-RID) <t>This document has no IANA actions.</t>
.</t> </section>
<section anchor="sc">
<t>This approach satisfies the following DRIP requirements defined in <xref targ <name>Security Considerations</name>
et="RFC9153"/>: GEN-5, GEN-11, and REG-1. As Broadcast messages are inherently m <t>The size of the public key hash in the HHIT is vulnerable to a second-p
ulticast, GEN-10 is met for local-link multicast to multiple Finders (how multil reimage attack. It is well within current server array technology to compute ano
ateration is possible).</t> ther key pair that hashes to the same HHIT (given the current ORCHID constructio
n hash length to fit UAS RID and IPv6 address constraints). Thus, if a receiver
<section anchor="csridfinder"><name>The CS-RID Finder</name> were to check HHIT/HI pair validity only by verifying that the received HI and a
ssociated information, when hashed in the ORCHID construction, reproduce the rec
<t>A CS-RID Finder is the gateway for Broadcast Remote ID Messages into UTM. It eived HHIT, an adversary could impersonate a validly registered UA. To defend ag
performs this gateway function via a CS-RID SDSP. A CS-RID Finder could implem ainst this, online receivers should verify the received HHIT and received HI wit
ent, integrate, or accept outputs from a Broadcast RID receiver. However, it sh h the HDA (typically USS) with which the HHIT/HI pair purports to be registered.
ould not depend upon a direct interface with a GCS, Net-RID SP, Net-RID DP or Ne Online and offline receivers can use a chain of received DRIP link endorsements
t-RID client. It would present a new interface to a CS-RID SDSP, similar to but from a root of trust through the RAA and the HDA to the UA, e.g., as described
readily distinguishable from that which a UAS (UA or GCS) presents to a Net-RID in <xref target="I-D.ietf-drip-auth"/> and <xref target="I-D.ietf-drip-registrie
SP.</t> s"/>.</t>
<t>Compromise of a DIME private key could do widespread harm <xref target=
</section> "I-D.ietf-drip-registries"/>. In particular, it would allow bad actors to impers
<section anchor="csridsdsp"><name>The CS-RID SDSP</name> onate trusted members of said DIME. These risks are in addition to those involvi
ng key management practices and will be addressed as part of the DIME process. A
<t>A CS-RID SDSP aggregates and processes (e.g., estimates UA location using mul ll DRIP public keys can be found in the DNS, thus they can be revoked in the DNS
tilateration when possible) information collected by CS-RID Finders. A CS-RID SD , and users <bcp14>SHOULD</bcp14> check the DNS when available. Specific key rev
SP should present the same interface to a Net-RID SP as does a Net-RID DP and to ocation procedures are as yet to be determined.</t>
a Net-RID DP as does a Net-RID SP, but its data source must be readily distingu <section anchor="private-key-physical-security">
ishable as via Finders rather than direct from the UAS itself.</t> <name>Private Key Physical Security</name>
<t>The security provided by asymmetric cryptographic techniques depends
</section> upon protection of the private keys. It may be necessary for the GCS to have the
</section> key pair to register the HHIT to the USS. Thus, it may be the GCS that generate
<section anchor="dripcontact"><name>DRIP Contact</name> s the key pair and delivers it to the UA, making the GCS a part of the key secur
ity boundary. Leakage of the private key, from either the UA or the GCS, to the
<t>One of the ways in which DRIP can enhance <xref target="F3411-22a"/> with imm component manufacturer is a valid concern, and steps need to be in place to ensu
ediately actionable information is by enabling an Observer to instantly initiate re safe keeping of the private key. Since it is possible for the UAS RID sender
secure communications with the UAS remote pilot, Pilot In Command, operator, US of a small harmless UA (or the entire UA) to be carried by a larger dangerous UA
S under which the operation is being flown, or other entity potentially able to as a "false flag", it is out of scope to deal with secure storage of the privat
furnish further information regarding the operation and its intent and/or to imm e key.</t>
ediately influence further conduct or termination of the operation (e.g., land o </section>
r otherwise exit an airspace volume). Such potentially distracting communication <section anchor="quantum-resistant-cryptography">
s demand strong "AAA" (Authentication, Attestation, Authorization, Access Contro <name>Quantum Resistant Cryptography</name>
l, Accounting, Attribution, Audit) per applicable policies (e.g., of the cogniza <t>There has been no effort as of yet in DRIP to address post quantum co
nt CAA).</t> mputing cryptography. Small UAS and Broadcast Remote ID communications are so c
onstrained that current post quantum computing cryptography is not applicable.
<t>A DRIP entity identifier based on a HHIT as outlined in <xref target="rid"/> Fortunately, since a UA may use a unique HHIT for each operation, the attack win
embeds an identifier of the DIME in which it can be found (expected typically to dow can be limited to the duration of the operation.
be the USS under which the UAS is flying) and the procedures outlined in <xref One potential future DRIP use for post quantum cryptography is for key pairs tha
target="driptrust"/> enable Observer verification of that relationship. A DRIP e t have long usage lives but that rarely, if ever, need to be transmitted over ba
ntity identifier with suitable records in public and private registries as outli ndwidth constrained links, such as for serial numbers or operators. As the HHIT
ned in Section 5 can enable lookup not only of information regarding the UAS, bu contains the ID for the cryptographic suite used in its creation, a future post
t also identities of and pointers to information regarding the various associate quantum computing safe algorithm that fits Remote ID constraints may be readily
d entities (e.g., the USS under which the UAS is flying an operation), including added. This is left for future work.</t>
means of contacting those associated entities (i.e., locators, typically IP add </section>
resses).</t> <section anchor="denial-of-service-dos-protection">
<name>Denial of Service (DoS) Protection</name>
<t>A suitably equipped Observer could initiate a secure communication channel, u <t>Remote ID services from the UA use a wireless link in a public space.
sing the DET HI, to a similarly equipped and identified entity: the UA itself, i As such, they are open to many forms of RF jamming. It is trivial for an attack
f operating autonomously; the GCS, if the UA is remotely piloted and the necessa er to stop any UA messages from reaching a wireless receiver. Thus, it is pointl
ry records have been populated in DNS; the USS, etc. Assuming secure communicati ess to attempt to provide relief from DoS attacks, as there is always the ultima
on setup (e.g. via IPsec or HIP), arbitrary standard higher layer protocols can te RF jamming attack. Also, DoS may be attempted with spoofing/replay attacks; f
then be used for Observer to Pilot (O2P) communications (e.g., SIP <xref target= or which, see <xref target="spoofreplay"/>.</t>
"RFC3261"/> et seq), V2X communications (e.g., <xref target="MAVLink"/>), etc. C </section>
ertain preconditions are necessary: each party needs a currently usable means (t <section anchor="spoofreplay">
ypically DNS) of resolving the other party's DRIP entity identifier to a current <name>Spoofing &amp; Replay Protection</name>
ly usable locator (IP address); and there must be currently usable bidirectional <t>As noted in <xref target="driptrust"/>, spoofing is combatted by the
IP (not necessarily Internet) connectivity between the parties. One method dir intrinsic self-attesting properties of HHITs, plus their registration. Also, as
ectly supported by the use of HHITs as DRIP entity identifiers is initiation of noted in <xref target="driptrust"/>, to combat replay attacks, a receiver <bcp14
a HIP Base Exchange (BEX) and Bound End-to-End Tunnel (BEET).</t> >MUST NOT</bcp14> trust any claims nominally received from an observed UA (not e
ven the Basic ID message purportedly identifying that UA) until the receiver ver
<t>This approach satisfies DRIP requirement GEN-6 Contact, supports satisfaction ifies that the private key used to sign those claims is trusted, that the sender
of requirements <xref target="RFC9153"/> GEN-8, GEN-9, PRIV-2, PRIV-5 and REG-3 actually possesses that key, and that the sender appears indeed to be that obse
, and is compatible with all other DRIP requirements.</t> rved UA. This requires receiving a complete chain of endorsement links from a ro
ot of trust to the UA's leaf DET, plus a message containing suitable nonce-like
</section> data signed with the private key corresponding to that DET, and verifying all th
<section anchor="sc"><name>Security Considerations</name> e foregoing. The term "nonce-like" describes data that is readily available to t
he prover and the verifier, changes frequently, is not predictable by the prover
<t>The size of the public key hash in the HHIT is vulnerable to a second preimag , and can be checked quickly at low computational cost by the verifier; a Locati
e attack. It is well within current server array technology to compute another k on/Vector message is an obvious choice.</t>
ey pair that hashes to the same HHIT (given the current ORCHID construction hash </section>
length to fit UAS RID and IPv6 address constraints). Thus, if a receiver were t <section anchor="timestamps-time-sources">
o check HHIT/HI pair validity only by verifying that the received HI and associa <name>Timestamps &amp; Time Sources</name>
ted information, when hashed in the ORCHID construction, reproduce the received <t><xref target="harvestbridforutm"/> and, more fundamentally, <xref tar
HHIT, an adversary could impersonate a validly registered UA. To defend against get="hhittrustworthy"/> both require timestamps. In Broadcast RID messages, <xre
this, online receivers should verify the received HHIT and received HI with the f target="F3411-22a"/> specifies both 32-bit Unix-style UTC timestamps (seconds
HDA (typically USS) with which the HHIT/HI pair purports to be registered. Onlin since midnight going into the 1st day of 2019, rather than 1970) and 16-bit rela
e and offline receivers can use a chain of received DRIP link endorsements from tive timestamps (tenths of seconds since the start of the most recent hour or ot
a root of trust through the RAA and the HDA to the UA, e.g., as described in <xr her specified event). <xref target="F3411-22a"/> requires that 16-bit timestamp
ef target="I-D.ietf-drip-auth"/> and <xref target="I-D.ietf-drip-registries"/>.< accuracy, relative to the time of applicability of the data being timestamped, a
/t> lso 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 lati
<t>Compromise of a DIME private key could do widespread harm <xref target="I-D.i tude, longitude, and geodetic altitude must be reported and most small UAS use G
etf-drip-registries"/>. In particular, it would allow bad actors to impersonate NSS for positioning and navigation.</t>
trusted members of said DIME. These risks are in addition to those involving key <aside>
management practices and will be addressed as part of the DIME process. All DRI <t>Informative note: For example, to satisfy <xref target="FAA_RID"/
P public keys can be found in DNS thus they can be revoked in DNS and users SHOU >, <xref target="F3586-22"/> specifies tamper protection of the entire RID subsy
LD check DNS when available. Specific key revocation procedures are as yet to be stem and use of the GPS operated by the US Government. The GPS has sub-microseco
determined.</t> nd accuracy and 1.5-second precision. In this example, UA-sourced messages can b
e assumed to have timestamp accuracy and precision of 1.5 seconds at worst.</t>
<section anchor="private-key-physical-security"><name>Private Key Physical Secur </aside>
ity</name> <t>GCS often have access to cellular LTE or other time sources better th
an the foregoing, and such better time sources would be required to support mult
<t>The security provided by asymmetric cryptographic techniques depends upon pro ilateration in <xref target="harvestbridforutm"/>, but such better time sources
tection of the private keys. It may be necessary for the GCS to have the key pai cannot be assumed generally for purposes of security analysis.</t>
r to register the HHIT to the USS. Thus it may be the GCS that generates the key </section>
pair and delivers it to the UA, making the GCS a part of the key security bound </section>
ary. Leakage of the private key either from the UA or GCS to the component manuf <section anchor="privacyforbrid">
acturer is a valid concern and steps need to be in place to ensure safe keeping <name>Privacy &amp; Transparency Considerations</name>
of the private key. Since it is possible for the UAS RID sender of a small harml <t>Broadcast RID messages can contain personal data (<xref target="RFC6973
ess UA (or the entire UA) to be carried by a larger dangerous UA as a "false fla " section="3.2" sectionFormat="of"/>), such as the operator ID, and, in most jur
g", it is out of scope to deal with secure storage of the private key.</t> isdictions, must contain the pilot/GCS location. The DRIP architectural approach
for personal data protection is symmetric encryption of the personal data using
</section> a session key known to the UAS and its USS, as follows. Authorized Observers ob
<section anchor="quantum-resistant-cryptography"><name>Quantum Resistant Cryptog tain plaintext in either of two ways: 1) an Observer can send the UAS ID and the
raphy</name> cyphertext to a server that offers decryption as a service, and 2) an Observer
can send just the UAS ID to a server that returns the session key so that the Ob
<t>There has been no effort as yet in DRIP to address post quantum computing cry server can directly, locally decrypt all cyphertext sent by that UA during that
ptography. Small UAS and Broadcast Remote ID communications are so constrained session (UAS operation). In either case, the server can be a public safety USS,
that current post quantum computing cryptography is not applicable. Fortunately the Observer's own USS, or the UA's USS if the latter can be determined (which,
, since a UA may use a unique HHIT for each operation, the attack window can be under DRIP, can be from the UAS ID itself). Personal data is protected unless th
limited to the duration of the operation. One potential future DRIP use for post e UAS is otherwise configured, i.e., as part of DRIP-enhanced RID subsystem prov
quantum cryptography is for keypairs that have long usage lives, but rarely if isioning, as part of UTM operation authorization, or via subsequent authenticate
ever need to be transmitted over bandwidth constrained links; such as for Serial d communications from a cognizant authority. Personal data protection <bcp14>MUS
Numbers or Operators. As the HHIT contains the ID for the cryptographic suite u T NOT</bcp14> be used if the UAS loses connectivity to its USS; if the UAS loses
sed in its creation, a future post quantum computing safe algorithm that fits Re connectivity, Observers nearby likely also won't have connectivity enabling dec
mote ID constraints may readily be added. This is left for future work.</t> ryption of the personal data. The UAS always has the option to abort the operati
on if personal data protection is disallowed, but if this occurs during flight,
</section> the UA then <bcp14>MUST</bcp14> broadcast the personal data without protection u
<section anchor="denial-of-service-dos-protection"><name>Denial Of Service (DoS) ntil it lands and is powered off. Note that normative language was used only min
Protection</name> imally in this section, as privacy protection requires refinement of the DRIP ar
chitecture and specification of interoperable protocol extensions, which are lef
<t>Remote ID services from the UA use a wireless link in a public space. As such t for future DRIP documents.</t>
, they are open to many forms of RF jamming. It is trivial for an attacker to st </section>
op any UA messages from reaching a wireless receiver. Thus it is pointless to at
tempt to provide relief from DOS attacks as there is always the ultimate RF jamm
ing attack. Also DOS may be attempted with spoofing/replay attacks, for which se
e <xref target="spoofreplay"/>.</t>
</section>
<section anchor="spoofreplay"><name>Spoofing &amp; Replay Protection</name>
<t>As noted in <xref target="driptrust"/>, spoofing is combatted by the intrinsi
c self-attesting properties of HHITs plus their registration. Also as noted in <
xref target="driptrust"/>, to combat replay attacks, a receiver MUST NOT trust t
hat an observed UA is that identified in the Basic ID message (i.e. possesses th
e corresponding private key) until it receives a complete chain of endorsement l
inks from a root of trust to the UA's leaf DET, plus a signed message containing
frequently changing, unpredictable but sanity-checkable data (e.g., a Location/
Vector message) and verifies all the foregoing.</t>
</section>
<section anchor="timestamps-time-sources"><name>Timestamps &amp; Time Sources</n
ame>
<t><xref target="harvestbridforutm"/> and more fundamentally <xref target="hhitt
rustworthy"/> both require timestamps. In Broadcast RID messages, <xref target="
F3411-22a"/> specifies both 32 bit Unix style UTC timestamps (seconds since midn
ight going into the 1st day of 2019 rather than 1970) and 16 bit relative timest
amps (tenths of seconds since the start of the most recent hour or other specifi
ed event). <xref target="F3411-22a"/> requires that 16 bit timestamp accuracy, r
elative to the time of applicability of the data being timestamped, also be repo
rted, with a worst allowable case of 1.5 seconds. <xref target="F3411-22a"/> doe
s not specify the time source, but GNSS is generally assumed, as latitude, longi
tude and geodetic altitude must be reported and most small UAS use GNSS for posi
tioning and navigation.</t>
<ul empty="true"><li>
<t>Informative note: for example, to satisfy <xref target="FAA_RID"/>, <xref t
arget="F3586-22"/> specifies tamper protection of the entire RID subsystem and u
se of the US Government operated GPS. GPS has sub-microsecond accuracy and 1.5 s
econd precision. In this example, UA-sourced messages can be assumed to have tim
estamp accuracy and precision of 1.5 seconds at worst.</t>
</li></ul>
<t>GCS often have access to cellular LTE or other time sources better than the f
oregoing, and such better time sources would be required to support multilaterat
ion in <xref target="harvestbridforutm"/>, but such better time sources cannot b
e assumed generally for purposes of security analysis.</t>
</section>
</section>
<section anchor="privacyforbrid"><name>Privacy &amp; Transparency Considerations
</name>
<t>Broadcast RID messages can contain personal data (Section 3.2 of <xref target
="RFC6973"/>) such as the operator ID and in most jurisdictions must contain the
pilot/GCS location. The DRIP architectural approach for personal data protectio
n 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 Observer can send the UAS ID and the cyphertext to a server that of
fers decryption as a service. An Observer can send just the UAS ID to a server t
hat returns the session key, so that Observer can directly locally decrypt all c
yphertext sent by that UA during that session (UAS operation). In either case, t
he server can be a Public Safety USS, the Observer's own USS, or the UA's USS if
the latter can be determined (which under DRIP it can be, from the UAS ID itsel
f). Personal data is protected unless the UAS is otherwise configured: as part o
f DRIP-enhanced RID subsystem provisioning; as part of UTM operation authorizati
on; or via subsequent authenticated communications from a cognizant authority. P
ersonal data protection MUST NOT be used if the UAS loses connectivity to its US
S, as if the UAS loses connectivity, Observers nearby likely also won't have con
nectivity enabling decryption of the personal data. The UAS always has the optio
n to abort the operation if personal data protection is disallowed, but if this
occurs during flight, the UA then MUST broadcast the personal data without prote
ction until it lands and is powered off. Note that normative language was used o
nly 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> </middle>
<back> <back>
<references title='Normative References'> <displayreference target="I-D.ietf-drip-auth" to="DRIP-AUTH"/>
<displayreference target="I-D.ietf-drip-registries" to="DRIP-REGISTRIES"/>
<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'> <references>
<front> <name>References</name>
<title>Key words for use in RFCs to Indicate Requirement Levels</title> <references>
<author fullname='S. Bradner' initials='S.' surname='Bradner'><organization/></a <name>Normative References</name>
uthor> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<date month='March' year='1997'/> 119.xml"/>
<abstract><t>In many standards track documents several words are used to signify <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
the requirements in the specification. These words are often capitalized. This 174.xml"/>
document defines these words as they should be interpreted in IETF documents. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
This document specifies an Internet Best Current Practices for the Internet Comm 153.xml"/>
unity, and requests discussion and suggestions for improvements.</t></abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
</front> 374.xml"/>
<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'> <reference anchor="F3411-22a" target="https://www.astm.org/f3411-22a.htm
<front> l">
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <front>
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></autho <title>Standard Specification for Remote ID and Tracking</title>
r> <author>
<date month='May' year='2017'/> <organization>ASTM International</organization>
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s </author>
pecifications. This document aims to reduce the ambiguity by clarifying that on <date year="2022" month="July"/>
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs </front>
tract> <seriesInfo name="ASTM" value="F3411-22A"/>
</front> <seriesInfo name="DOI" value="10.1520/F3411-22A"/>
<seriesInfo name='BCP' value='14'/> </reference>
<seriesInfo name='RFC' value='8174'/> </references>
<seriesInfo name='DOI' value='10.17487/RFC8174'/> <references>
</reference> <name>Informative References</name>
<reference anchor='RFC9153' target='https://www.rfc-editor.org/info/rfc9153'> <reference anchor="I-D.ietf-drip-auth" target="https://datatracker.ietf.org/doc/ html/draft-ietf-drip-auth-30">
<front> <front>
<title>Drone Remote Identification Protocol (DRIP) Requirements and Terminology< <title>
/title> DRIP Entity Tag Authentication Formats &amp; Protocols for Broadcast Remote ID
<author fullname='S. Card' initials='S.' role='editor' surname='Card'><organizat </title>
ion/></author> <author initials="A." surname="Wiethuechter" fullname="Adam Wiethuechter" role="
<author fullname='A. Wiethuechter' initials='A.' surname='Wiethuechter'><organiz editor">
ation/></author> <organization>AX Enterprize, LLC</organization>
<author fullname='R. Moskowitz' initials='R.' surname='Moskowitz'><organization/ </author>
></author> <author initials="S." surname="Card" fullname="Stuart W. Card">
<author fullname='A. Gurtov' initials='A.' surname='Gurtov'><organization/></aut <organization>AX Enterprize, LLC</organization>
hor> </author>
<date month='February' year='2022'/> <author initials="R." surname="Moskowitz" fullname="Robert Moskowitz">
<abstract><t>This document defines terminology and requirements for solutions pr <organization>HTT Consulting</organization>
oduced by the Drone Remote Identification Protocol (DRIP) Working Group. These s </author>
olutions will support Unmanned Aircraft System Remote Identification and trackin <date month="March" day="28" year="2023"/>
g (UAS RID) for security, safety, and other purposes (e.g., initiation of identi
ty-based network sessions supporting UAS applications). DRIP will facilitate use
of existing Internet resources to support RID and to enable enhanced related se
rvices, and it will enable online and offline verification that RID information
is trustworthy.</t></abstract>
</front> </front>
<seriesInfo name='RFC' value='9153'/> <seriesInfo name="Internet-Draft" value="draft-ietf-drip-auth-30"/>
<seriesInfo name='DOI' value='10.17487/RFC9153'/>
</reference>
<reference anchor='I-D.ietf-drip-rid' target='https://datatracker.ietf.org/doc/h
tml/draft-ietf-drip-rid-37'>
<front>
<title>DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS R
ID)</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>
<reference anchor="F3411-22a" target="https://www.astm.org/f3411-22a.html">
<front>
<title>Standard Specification for Remote ID and Tracking</title>
<author >
<organization>ASTM International</organization>
</author>
<date year="2022" month="July"/>
</front>
</reference> </reference>
</references> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
ietf-drip-registries.xml"/>
<references title='Informative References'>
<reference anchor='I-D.ietf-drip-auth' target='https://datatracker.ietf.org/doc/
html/draft-ietf-drip-auth-29'>
<front>
<title>DRIP Entity Tag Authentication Formats &amp; Protocols for Broadcas
t Remote ID</title>
<author fullname='Adam Wiethuechter' initials='A.' surname='Wiethuechter'>
<organization>AX Enterprize, LLC</organization>
</author>
<author fullname='Stuart W. Card' initials='S. W.' surname='Card'>
<organization>AX Enterprize, LLC</organization>
</author>
<author fullname='Robert Moskowitz' initials='R.' surname='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.or <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
g/doc/html/draft-ietf-drip-registries-07'> 334.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
<title>DRIP Entity Tag (DET) Identity Management Architecture</title> 034.xml"/>
<author fullname='Adam Wiethuechter' initials='A.' surname='Wiethuechter'> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<organization>AX Enterprize, LLC</organization> 261.xml"/>
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<author fullname='Jim Reid' initials='J.' surname='Reid'> 972.xml"/>
<organization>RTFM llp</organization> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
</author> 730.xml"/>
<date day='5' month='December' year='2022'/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<abstract> 033.xml"/>
<t> This document describes the high level architecture for the <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
registration and discovery of DRIP Entity Tags (DETs) using DNS. 401.xml"/>
Discovery of DETs and their artifacts are through the existing DNS <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
structure and methods by using FQDNs. A general overview of the 480.xml"/>
interfaces required between involved components is described in this <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
document with supporting documents giving technical specifications. 004.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
005.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
032.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
082.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
083.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
224.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
973.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
26.xml"/>
</t> <reference anchor="F3586-22" target="https://www.astm.org/f3586-22.html"
</abstract> >
</front> <front>
<seriesInfo name='Internet-Draft' value='draft-ietf-drip-registries-07'/> <title>Standard Practice for Remote ID Means of Compliance to Federa
l Aviation Administration Regulation 14 CFR Part 89</title>
<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> <reference anchor="MOC-NOA" target="https://www.regulations.gov/document
/FAA-2022-0859-0001">
<front>
<title>Accepted Means of Compliance; Remote Identification of Unmann
ed Aircraft</title>
<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='RFC9334' target='https://www.rfc-editor.org/info/rfc9334'> <reference anchor="CTA2063A">
<front> <front>
<title>Remote ATtestation procedureS (RATS) Architecture</title> <title>Small Unmanned Aerial Systems Serial Numbers</title>
<author fullname='H. Birkholz' initials='H.' surname='Birkholz'><organization/>< <author>
/author> <organization>ANSI</organization>
<author fullname='D. Thaler' initials='D.' surname='Thaler'><organization/></aut </author>
hor> <date year="2019" month="September"/>
<author fullname='M. Richardson' initials='M.' surname='Richardson'><organizatio </front>
n/></author> <seriesInfo name="ANSI/CTA" value="2063-A"/>
<author fullname='N. Smith' initials='N.' surname='Smith'><organization/></autho </reference>
r>
<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. T
his document provides an architectural overview of the entities involved that ma
ke such tests possible through the process of generating, conveying, and evaluat
ing evidentiary Claims. It provides a model that is neutral toward processor ar
chitectures, 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'> <reference anchor="Delegated" target="https://eur-lex.europa.eu/eli/reg_
<front> del/2019/945/oj">
<title>Domain names - concepts and facilities</title> <front>
<author fullname='P. Mockapetris' initials='P.' surname='Mockapetris'><organizat <title>Commission Delegated Regulation (EU) 2019/945 of 12 March 201
ion/></author> 9 on unmanned aircraft systems and on third-country operators of unmanned aircra
<date month='November' year='1987'/> ft systems</title>
<abstract><t>This RFC is the revised basic definition of The Domain Name System. <author>
It obsoletes RFC-882. This memo describes the domain style names and their us <organization>European Union Aviation Safety Agency (EASA)</organi
ed for host address look up and electronic mail forwarding. It discusses the cl zation>
ients and servers in the domain name system and the protocol used between them.< </author>
/t></abstract> <date year="2019" month="March"/>
</front> </front>
<seriesInfo name='STD' value='13'/> </reference>
<seriesInfo name='RFC' value='1034'/>
<seriesInfo name='DOI' value='10.17487/RFC1034'/>
</reference>
<reference anchor='RFC3261' target='https://www.rfc-editor.org/info/rfc3261'> <reference anchor="Implementing" target="https://eur-lex.europa.eu/legal
<front> -content/EN/TXT/?uri=CELEX%3A32019R0947">
<title>SIP: Session Initiation Protocol</title> <front>
<author fullname='J. Rosenberg' initials='J.' surname='Rosenberg'><organization/ <title>Commission Implementing Regulation (EU) 2019/947 of 24 May 20
></author> 19 on the rules and procedures for the operation of unmanned aircraft (Text with
<author fullname='H. Schulzrinne' initials='H.' surname='Schulzrinne'><organizat EEA relevance.)</title>
ion/></author> <author>
<author fullname='G. Camarillo' initials='G.' surname='Camarillo'><organization/ <organization>European Union Aviation Safety Agency (EASA)</organi
></author> zation>
<author fullname='A. Johnston' initials='A.' surname='Johnston'><organization/>< </author>
/author> <date year="2019" month="May"/>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/>< </front>
/author> </reference>
<author fullname='R. Sparks' initials='R.' surname='Sparks'><organization/></aut
hor>
<author fullname='M. Handley' initials='M.' surname='Handley'><organization/></a
uthor>
<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 appli
cation-layer control (signaling) protocol for creating, modifying, and terminati
ng sessions with one or more participants. These sessions include Internet tele
phone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TR
ACK]</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'> <reference anchor="Implementing_update" target="https://eur-lex.europa.e
<front> u/legal-content/EN/TXT/?uri=CELEX%3A32021R0664">
<title>Cryptographically Generated Addresses (CGA)</title> <front>
<author fullname='T. Aura' initials='T.' surname='Aura'><organization/></author> <title>Commission Implementing Regulation (EU) 2021/664 of 22 April
<date month='March' year='2005'/> 2021 on a regulatory framework for the U-space (Text with EEA relevance)</title>
<abstract><t>This document describes a method for binding a public signature key <author>
to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol. Cryptogra <organization>European Union Aviation Safety Agency (EASA)</organi
phically Generated Addresses (CGA) are IPv6 addresses for which the interface id zation>
entifier is generated by computing a cryptographic one-way hash function from a </author>
public key and auxiliary parameters. The binding between the public key and the <date year="2021" month="April"/>
address can be verified by re-computing the hash value and by comparing the has </front>
h with the interface identifier. Messages sent from an IPv6 address can be prot </reference>
ected by attaching the public key and auxiliary parameters and by signing the me
ssage with the corresponding private key. The protection works without a certif
ication authority or any security infrastructure. [STANDARDS-TRACK]</t></abstra
ct>
</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'> <reference anchor="NPA" target="https://www.easa.europa.eu/downloads/134
<front> 303/en">
<title>Extensible Provisioning Protocol (EPP)</title> <front>
<author fullname='S. Hollenbeck' initials='S.' surname='Hollenbeck'><organizatio <title>Notice of Proposed Amendment 2021-14: Development of acceptab
n/></author> le means of compliance and guidance material to support the U-space regulation</
<date month='August' year='2009'/> title>
<abstract><t>This document describes an application-layer client-server protocol <author>
for the provisioning and management of objects stored in a shared central repos <organization>European Union Aviation Safety Agency (EASA)</organi
itory. Specified in XML, the protocol defines generic object management operati zation>
ons and an extensible framework that maps protocol operations to objects. This </author>
document includes a protocol specification, an object mapping template, and an X <date year="2021" month="December"/>
ML media type registration. This document obsoletes RFC 4930. [STANDARDS-TRACK </front>
]</t></abstract> </reference>
</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'> <reference anchor="LAANC" target="https://www.faa.gov/ air_traffic/
<front> publications/atpubs/foa_html/chap12_section_9.html">
<title>WebFinger</title> <front>
<author fullname='P. Jones' initials='P.' surname='Jones'><organization/></autho <title>Low Altitude Authorization and Notification Capability</title
r> >
<author fullname='G. Salgueiro' initials='G.' surname='Salgueiro'><organization/ <author>
></author> <organization>United States Federal Aviation Administration (FAA)<
<author fullname='M. Jones' initials='M.' surname='Jones'><organization/></autho /organization>
r> </author>
<author fullname='J. Smarr' initials='J.' surname='Smarr'><organization/></autho </front>
r> </reference>
<date month='September' year='2013'/>
<abstract><t>This specification defines the WebFinger protocol, which can be use
d to discover information about people or other entities on the Internet using s
tandard 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'> <reference anchor="NPRM" target="https://www.federalregister.gov/documen
<front> ts/2019/ 12/31/2019-28100/remote-identification-of-unmanned-air
<title>Host Identity Protocol Version 2 (HIPv2)</title> craft-systems">
<author fullname='R. Moskowitz' initials='R.' role='editor' surname='Moskowitz'> <front>
<organization/></author> <title>Remote Identification of Unmanned Aircraft Systems</title>
<author fullname='T. Heer' initials='T.' surname='Heer'><organization/></author> <author>
<author fullname='P. Jokela' initials='P.' surname='Jokela'><organization/></aut <organization>United States Federal Aviation Administration (FAA)<
hor> /organization>
<author fullname='T. Henderson' initials='T.' surname='Henderson'><organization/ </author>
></author> <date month="December" year="2019"/>
<date month='April' year='2015'/> </front>
<abstract><t>This document specifies the details of the Host Identity Protocol ( <refcontent>Notice of proposed rulemaking</refcontent>
HIP). HIP allows consenting hosts to securely establish and maintain shared IP- </reference>
layer state, allowing separation of the identifier and locator roles of IP addre
sses, 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 t
he Encapsulating Security Payload (ESP), it provides integrity protection and op
tional encryption for upper-layer protocols, such as TCP and UDP.</t><t>This doc
ument obsoletes RFC 5201 and addresses the concerns raised by the IESG, particul
arly that of crypto agility. It also incorporates lessons learned from the impl
ementations 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'> <reference anchor="TR-22.825" target="https://portal.3gpp.org/desktopmod
<front> ules/Specifications/SpecificationDetails.aspx?specificationId=3527">
<title>HTTP Usage in the Registration Data Access Protocol (RDAP)</title> <front>
<author fullname='A. Newton' initials='A.' surname='Newton'><organization/></aut <title>Study on Remote Identification of Unmanned Aerial Systems (UA
hor> S)</title>
<author fullname='B. Ellacott' initials='B.' surname='Ellacott'><organization/>< <author>
/author> <organization>3GPP</organization>
<author fullname='N. Kong' initials='N.' surname='Kong'><organization/></author> </author>
<date month='March' year='2015'/> <date month="September" year="2018"/>
<abstract><t>This document is one of a collection that together describes the Re </front>
gistration Data Access Protocol (RDAP). It describes how RDAP is transported us <seriesInfo name="3GPP TR" value="22.825"/>
ing the Hypertext Transfer Protocol (HTTP). RDAP is a successor protocol to the <refcontent>Release 16</refcontent>
very old WHOIS protocol. The purpose of this document is to clarify the use of </reference>
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'> <reference anchor="TR-23.755" target="https://portal.3gpp.org/desktopmod
<front> ules/Specifications/SpecificationDetails.aspx?specificationId=3588">
<title>Host Identity Protocol (HIP) Rendezvous Extension</title> <front>
<author fullname='J. Laganier' initials='J.' surname='Laganier'><organization/>< <title>Study on application layer support for Unmanned Aerial System
/author> s (UAS)</title>
<author fullname='L. Eggert' initials='L.' surname='Eggert'><organization/></aut <author>
hor> <organization>3GPP</organization>
<date month='October' year='2016'/> </author>
<abstract><t>This document defines a rendezvous extension for the Host Identity <date year="2021" month="March"/>
Protocol (HIP). The rendezvous extension extends HIP and the HIP Registration E </front>
xtension for initiating communication between HIP nodes via HIP rendezvous serve <seriesInfo name="3GPP TR" value="23.755"/>
rs. Rendezvous servers improve reachability and operation when HIP nodes are mu <refcontent>Release 17</refcontent>
ltihomed or mobile. This document obsoletes RFC 5204.</t></abstract> </reference>
</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'> <reference anchor="TS-23.255" target="https://portal.3gpp.org/desktopmod
<front> ules/Specifications/SpecificationDetails.aspx?specificationId=3843">
<title>Host Identity Protocol (HIP) Domain Name System (DNS) Extension</title> <front>
<author fullname='J. Laganier' initials='J.' surname='Laganier'><organization/>< <title>Application layer support for Uncrewed Aerial System (UAS); F
/author> unctional architecture and information flows</title>
<date month='October' year='2016'/> <author>
<abstract><t>This document specifies a resource record (RR) for the Domain Name <organization>3GPP</organization>
System (DNS) and how to use it with the Host Identity Protocol (HIP). This RR al </author>
lows a HIP node to store in the DNS its Host Identity (HI), the public component <date year="2021" month="June"/>
of the node public-private key pair; its Host Identity Tag (HIT), a truncated h </front>
ash of its public key (PK); and the domain names of its rendezvous servers (RVSs <seriesInfo name="3GPP TS" value="23.255"/>
). This document obsoletes RFC 5205.</t></abstract> <refcontent>Release 17</refcontent>
</front> </reference>
<seriesInfo name='RFC' value='8005'/>
<seriesInfo name='DOI' value='10.17487/RFC8005'/>
</reference>
<reference anchor='RFC8032' target='https://www.rfc-editor.org/info/rfc8032'> <reference anchor="U-Space" target="https://www.sesarju.eu/sites/default
<front> /files/documents/u-space/CORUS%20ConOps%20vol2.pdf">
<title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title> <front>
<author fullname='S. Josefsson' initials='S.' surname='Josefsson'><organization/ <title>U-space Concept of Operations</title>
></author> <author>
<author fullname='I. Liusvaara' initials='I.' surname='Liusvaara'><organization/ <organization>European Organization for the Safety of Air Navigati
></author> on (EUROCONTROL)</organization>
<date month='January' year='2017'/> </author>
<abstract><t>This document describes elliptic curve signature scheme Edwards-cur <date year="2019" month="October"/>
ve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with reco </front>
mmended parameters for the edwards25519 and edwards448 curves. An example imple </reference>
mentation 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'> <reference anchor="FAA_RID" target="https://www.govinfo.gov/content/pkg/
<front> FR-2021-01-15/pdf/2020-28948.pdf">
<title>Registration Data Access Protocol (RDAP) Query Format</title> <front>
<author fullname='S. Hollenbeck' initials='S.' surname='Hollenbeck'><organizatio <title>Remote Identification of Unmanned Aircraft</title>
n/></author> <author>
<author fullname='A. Newton' initials='A.' surname='Newton'><organization/></aut <organization>United States Federal Aviation Administration (FAA)<
hor> /organization>
<date month='June' year='2021'/> </author>
<abstract><t>This document describes uniform patterns to construct HTTP URLs tha <date year="2021" month="January"/>
t may be used to retrieve registration information from registries (including bo </front>
th Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using <refcontent>Federal Register, Vol. 86, No. 10</refcontent>
&quot;RESTful&quot; web access patterns. These uniform patterns define the quer </reference>
y syntax for the Registration Data Access Protocol (RDAP). This document obsolet
es 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'> <reference anchor="FAA_UAS_Concept_Of_Ops" target="https://www.faa.gov/s
<front> ites/faa.gov/files/2022-08/UTM_ConOps_v2.pdf">
<title>JSON Responses for the Registration Data Access Protocol (RDAP)</title> <front>
<author fullname='S. Hollenbeck' initials='S.' surname='Hollenbeck'><organizatio <title>Unmanned Aircraft System (UAS) Traffic Management (UTM) Conce
n/></author> pt of Operations</title>
<author fullname='A. Newton' initials='A.' surname='Newton'><organization/></aut <author>
hor> <organization>United States Federal Aviation Administration (FAA)<
<date month='June' year='2021'/> /organization>
<abstract><t>This document describes JSON data structures representing registrat </author>
ion information maintained by Regional Internet Registries (RIRs) and Domain Nam <date year="2020" month="March"/>
e Registries (DNRs). These data structures are used to form Registration Data A </front>
ccess Protocol (RDAP) query responses. This document obsoletes RFC 7483.</t></ab <refcontent>v2.0</refcontent>
stract> </reference>
</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'> <reference anchor="MAVLink" target="http://mavlink.io/">
<front> <front>
<title>Finding the Authoritative Registration Data Access Protocol (RDAP) Servic <title>Micro Air Vehicle Communication Protocol</title>
e</title> <author>
<author fullname='M. Blanchet' initials='M.' surname='Blanchet'><organization/>< <organization>MAVLink</organization>
/author> </author>
<date month='March' year='2022'/> </front>
<abstract><t>This document specifies a method to find which Registration Data Ac </reference>
cess Protocol (RDAP) server is authoritative to answer queries for a requested s
cope, such as domain names, IP addresses, or Autonomous System numbers. This doc
ument 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'> <reference anchor="FS_AEUA" target="https://www.3gpp.org/ftp/tsg_sa/WG2_
<front> Arch/TSGS2_147E_Electronic_2021-10/Docs/S2-2107092.zip">
<title>Privacy Considerations for Internet Protocols</title> <front>
<author fullname='A. Cooper' initials='A.' surname='Cooper'><organization/></aut <title>Study of Further Architecture Enhancement for UAV and UAM</ti
hor> tle>
<author fullname='H. Tschofenig' initials='H.' surname='Tschofenig'><organizatio <author>
n/></author> <organization/>
<author fullname='B. Aboba' initials='B.' surname='Aboba'><organization/></autho </author>
r> <date month="October" year="2021"/>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/>< </front>
/author> <refcontent>S2-2107092</refcontent>
<author fullname='J. Morris' initials='J.' surname='Morris'><organization/></aut </reference>
hor>
<author fullname='M. Hansen' initials='M.' surname='Hansen'><organization/></aut
hor>
<author fullname='R. Smith' initials='R.' surname='Smith'><organization/></autho
r>
<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, implement
ers, and users of Internet protocols aware of privacy-related design choices. I
t suggests that whether any individual RFC warrants a specific privacy considera
tions section will depend on the document's content.</t></abstract>
</front>
<seriesInfo name='RFC' value='6973'/>
<seriesInfo name='DOI' value='10.17487/RFC6973'/>
</reference>
<reference anchor="F3586-22" target="https://www.astm.org/f3586-22.html"> <reference anchor="F3411-19" target="https://www.astm.org/f3411-1
<front> 9.html">
<title>Standard Practice for Remote ID Means of Compliance to Federal Aviati <front>
on Administration Regulation 14 CFR Part 89</title> <title>Standard Specification for Remote ID and Tracking</title>
<author > <author>
<organization>ASTM International</organization> <organization>ASTM International</organization>
</author> </author>
<date year="2022" month="July"/> <date year="2022" month="May"/>
</front> </front>
</reference> <seriesInfo name="ASTM" value="F3411-19"/>
<reference anchor="MOC-NOA" target="https://www.regulations.gov/document/FAA-202 <seriesInfo name="DOI" value="10.1520/F3411-19"/>
2-0859-0001"> </reference>
<front>
<title>Accepted Means of Compliance; Remote Identification of Unmanned Aircr
aft</title>
<author >
<organization>United States Federal Aviation Administration (FAA)</organiz
ation>
</author>
<date year="2022" month="August"/>
</front>
</reference>
<reference anchor="CTA2063A" >
<front>
<title>Small Unmanned Aerial Systems Serial Numbers</title>
<author >
<organization>ANSI</organization>
</author>
<date year="2019"/>
</front>
</reference>
<reference anchor="Delegated" target="https://eur-lex.europa.eu/legal-content/EN
/TXT/?uri=CELEX%3A32019R0945">
<front>
<title>EU Commission Delegated Regulation 2019/945 of 12 March 2019 on unman
ned aircraft systems and on third-country operators of unmanned aircraft systems
</title>
<author >
<organization>European Union Aviation Safety Agency (EASA)</organization>
</author>
<date year="2019"/>
</front>
</reference>
<reference anchor="Implementing" target="https://eur-lex.europa.eu/legal-content
/EN/TXT/?uri=CELEX%3A32019R0947">
<front>
<title>EU Commission Implementing Regulation 2019/947 of 24 May 2019 on the
rules and procedures for the operation of unmanned aircraft</title>
<author >
<organization>European Union Aviation Safety Agency (EASA)</organization>
</author>
<date year="2019"/>
</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 (EU) 2021/664 of 22 April 2021
on a regulatory framework for the U-space</title>
<author >
<organization>European Union Aviation Safety Agency (EASA)</organization>
</author>
<date year="2021"/>
</front>
</reference>
<reference anchor="NPA" target="https://www.easa.europa.eu/downloads/134303/en">
<front>
<title>Notice of Proposed Amendment 2021-14 Development of acceptable means
of compliance and guidance material to support the U-space regulation</title>
<author >
<organization>European Union Aviation Safety Agency (EASA)</organization>
</author>
<date year="2021"/>
</front>
</reference>
<reference anchor="LAANC" target="https://www.faa.gov/uas/programs_partnerships/
data_exchange/">
<front>
<title>Low Altitude Authorization and Notification Capability</title>
<author >
<organization>United States Federal Aviation Administration (FAA)</organiz
ation>
</author>
<date year="n.d."/>
</front>
</reference>
<reference anchor="NPRM" >
<front>
<title>Notice of Proposed Rule Making on Remote Identification of Unmanned A
ircraft Systems</title>
<author >
<organization>United States Federal Aviation Administration (FAA)</organiz
ation>
</author>
<date year="2019"/>
</front>
</reference>
<reference anchor="TS-22.825" target="https://portal.3gpp.org/desktopmodules/Spe
cifications/SpecificationDetails.aspx?specificationId=3527">
<front>
<title>Study on Remote Identification of Unmanned Aerial Systems (UAS)</titl
e>
<author >
<organization>3GPP</organization>
</author>
<date year="2018"/>
</front>
</reference>
<reference anchor="TR-23.755" target="https://portal.3gpp.org/desktopmodules/Spe
cifications/SpecificationDetails.aspx?specificationId=3588">
<front>
<title>Study on application layer support for Unmanned Aerial Systems (UAS)
(Release 17)</title>
<author >
<organization>3GPP</organization>
</author>
<date year="2019"/>
</front>
</reference>
<reference anchor="TS-23.255" target="https://portal.3gpp.org/desktopmodules/Spe
cifications/SpecificationDetails.aspx?specificationId=3843">
<front>
<title>Application layer support for Uncrewed Aerial System (UAS) Functional
architecture and information flows; (Release 17)</title>
<author >
<organization>3GPP</organization>
</author>
<date year="2020"/>
</front>
</reference>
<reference anchor="U-Space" target="https://www.sesarju.eu/sites/default/files/d
ocuments/u-space/CORUS%20ConOps%20vol2.pdf">
<front>
<title>U-space Concept of Operations</title>
<author >
<organization>European Organization for the Safety of Air Navigation (EURO
CONTROL)</organization>
</author>
<date year="2019"/>
</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 >
<organization>United States Federal Aviation Administration (FAA)</organiz
ation>
</author>
<date year="2021"/>
</front>
</reference>
<reference anchor="FAA_UAS_Concept_Of_Ops" target="https://www.faa.gov/uas/resea
rch_development/traffic_management/media/UTM_ConOps_v2.pdf">
<front>
<title>Unmanned Aircraft System (UAS) Traffic Management (UTM) Concept of Op
erations (V2.0)</title>
<author >
<organization>United States Federal Aviation Administration (FAA)</organiz
ation>
</author>
<date year="2020"/>
</front>
</reference>
<reference anchor="MAVLink" target="http://mavlink.io/">
<front>
<title>Micro Air Vehicle Communication Protocol</title>
<author >
<organization></organization>
</author>
<date year="2021"/>
</front>
</reference>
<reference anchor="FS_AEUA" target="https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSG
S2_147E_Electronic_2021-10/Docs/S2-2107092.zip">
<front>
<title>Study of Further Architecture Enhancement for UAV and UAM</title>
<author >
<organization></organization>
</author>
<date year="2021"/>
</front>
</reference>
</references>
</references> </references>
<section anchor="appendix-a">
<section anchor="appendix-a"><name>Overview of Unmanned Aircraft Systems (UAS) T <name>Overview of UAS Traffic Management (UTM)</name>
raffic Management (UTM)</name> <section anchor="operation-concept">
<name>Operation Concept</name>
<section anchor="operation-concept"><name>Operation Concept</name> <t>The efforts of the National Aeronautics and Space Administration (NAS
A) and FAA to integrate UAS operations into the national airspace system (NAS) l
<t>The National Aeronautics and Space Administration (NASA) and FAA's effort to ed to the development of the concept of UTM and the ecosystem around it. The UT
integrate UAS operations into the national airspace system (NAS) led to the deve M concept was initially presented in 2013, and version 2.0 was published in 2020
lopment of the concept of UTM and the ecosystem around it. The UTM concept was <xref target="FAA_UAS_Concept_Of_Ops"/>.</t>
initially presented in 2013 and version 2.0 was published in 2020 <xref target=" <t>The eventual concept refinement, initial prototype implementation, an
FAA_UAS_Concept_Of_Ops"/>.</t> d testing were conducted by the joint FAA and NASA UTM research transition team.
World efforts took place afterward. The Single European Sky ATM Research (SESA
<t>The eventual concept refinement, initial prototype implementation, and testin R) started the Concept of Operation for EuRopean UTM Systems (CORUS) project to
g were conducted by the joint FAA and NASA UTM research transition team. World e research its UTM counterpart concept, namely <xref target="U-Space"/>. This eff
fforts took place afterward. The Single European Sky ATM Research (SESAR) start ort is led by the European Organization for the Safety of Air Navigation (EUROCO
ed the CORUS project to research its UTM counterpart concept, namely <xref targe NTROL).</t>
t="U-Space"/>. This effort is led by the European Organization for the Safety o <t>Both NASA and SESAR have published their UTM concepts of operations t
f Air Navigation (Eurocontrol).</t> o guide the development of their future air traffic management (ATM)
<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> system and ensure safe and efficient integration of manned and unmanned aircraft into the national airspace.</t>
<t>UTM comprises UAS operations infrastructure, procedures, and local re
<t>UTM comprises UAS operations infrastructure, procedures and local regulation gulation compliance policies to guarantee safe UAS integration and operation. T
compliance policies to guarantee safe UAS integration and operation. The main f he main functionality of UTM includes, but is not limited to, providing means of
unctionality of UTM includes, but is not limited to, providing means of communic communication between UAS operators and service providers and a platform to fac
ation between UAS operators and service providers and a platform to facilitate c ilitate communication among UAS service providers.</t>
ommunication among UAS service providers.</t> </section>
<section anchor="uas-service-supplier-uss">
</section> <name>UAS Service Supplier (USS)</name>
<section anchor="uas-service-supplier-uss"><name>UAS Service Supplier (USS)</nam <t>A USS plays an important role to fulfill the key performance indicato
e> rs (KPIs) that UTM has to offer. Such an entity acts as a proxy between UAS ope
rators and UTM service providers. It provides services like real-time UAS traff
<t>A USS plays an important role to fulfill the key performance indicators (KPIs ic monitoring and planning, aeronautical data archiving, airspace and violation
) that UTM has to offer. Such an Entity acts as a proxy between UAS operators a control, interacting with other third-party control entities, etc. A USS can co
nd UTM service providers. It provides services like real-time UAS traffic monit exist with other USS to build a large service coverage map that can load-balance
oring and planning, aeronautical data archiving, airspace and violation control, , relay, and share UAS traffic information.</t>
interacting with other third-party control entities, etc. A USS can coexist wi <t>The FAA works with UAS industry shareholders and promotes the Low Alt
th other USS to build a large service coverage map that can load-balance, relay, itude Authorization and Notification Capability <xref target="LAANC"/> program,
and share UAS traffic information.</t> 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
<t>The FAA works with UAS industry shareholders and promotes the Low Altitude Au s and applications for airspace authorization in real time by checking against m
thorization and Notification Capability <xref target="LAANC"/> program, which is ultiple aeronautical databases, such as airspace classification and operating ru
the first system to realize some of the envisioned functionality of UTM. The LA les associated with it, the FAA UAS facility map, special use airspace, Notice t
ANC program can automate UAS operational intent (flight plan) submission and app o Airmen (NOTAM), and Temporary Flight Restriction (TFR).</t>
lication for airspace authorization in real-time by checking against multiple ae </section>
ronautical databases such as airspace classification and operating rules associa <section anchor="utm-use-cases-for-uas-operations">
ted with it, FAA UAS facility map, special use airspace, Notice to Airmen (NOTAM <name>UTM Use Cases for UAS Operations</name>
), and Temporary Flight Restriction (TFR).</t> <t>This section illustrates a couple of use case scenarios where UAS par
ticipation in UTM has significant safety improvement.</t>
</section> <ol spacing="normal" type="1">
<section anchor="utm-use-cases-for-uas-operations"><name>UTM Use Cases for UAS O <li>For a UAS participating in UTM and taking off or landing in control
perations</name> led 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 regist
<t>This section illustrates a couple of use case scenarios where UAS participati ration, authenticating the UAS operational intent (flight plan) by checking agai
on in UTM has significant safety improvement.</t> nst a designated UAS facility map database, obtaining the air traffic control (A
TC) authorization, and monitoring the UAS flight path in order to maintain safe
<t><list style="numbers"> margins and follow the pre-authorized sequence of authorized 4-D volumes (route)
<t>For a UAS participating in UTM and taking off or landing in controlled airs .</li>
pace (e.g., Class Bravo, Charlie, Delta, and Echo in the United States), the USS <li>For a UAS participating in UTM and taking off or landing in uncont
under which the UAS is operating is responsible for verifying UA registration, rolled airspace (e.g., Class Golf in the United States), preflight authorization
authenticating the UAS operational intent (flight plan) by checking against a de must be obtained from a USS when operating BVLOS. The USS either accepts or re
signated UAS facility map database, obtaining the air traffic control (ATC) auth jects the received operational intent (flight plan) from the UAS. An accepted U
orization, and monitoring the UAS flight path in order to maintain safe margins AS operation may, and in some cases must, share its current flight data, such as
and follow the pre-authorized sequence of authorized 4-D volumes (route).</t> GPS position and altitude, to the USS. The USS may maintain (and provide to au
<t>For a UAS participating in UTM and taking off or landing in uncontrolled ai thorized requestors) the UAS operation status near real time in the short term a
rspace (e.g., Class Golf in the United States), pre-flight authorization must be nd may retain at least some of it in the longer term, e.g., for overall airspace
obtained from a USS when operating Beyond Visual Line Of Sight (BVLOS). The US air traffic monitoring.</li>
S either accepts or rejects the received operational intent (flight plan) from t </ol>
he UAS. An accepted UAS operation may, and in some cases must, share its curren </section>
t flight data, such as GPS position and altitude, to the USS. The USS may maint </section>
ain (and provide to authorized requestors) the UAS operation status near real-ti <section anchor="adsb">
me in the short term, and may retain at least some of it in the longer term, e.g <name>Automatic Dependent Surveillance Broadcast (ADS-B)</name>
., for overall airspace air traffic monitoring.</t> <t>ADS-B is the de jure technology used in manned aviation for sharing loc
</list></t> ation information, from the aircraft to ground and satellite-based systems, desi
gned in the early 2000s. Broadcast RID is conceptually similar to ADS-B but with
</section> the receiver target being the general public on generally available devices (e.
</section> g., smartphones).</t>
<section anchor="adsb"><name>Automatic Dependent Surveillance Broadcast (ADS-B)< <t>For numerous technical reasons, ADS-B itself is not suitable for low-fl
/name> ying, small UAS. Technical reasons include, but are not limited to, the followin
g:</t>
<t>The ADS-B is the de jure technology used in manned aviation for sharing locat <ol spacing="normal" type="1">
ion information, from the aircraft to ground and satellite-based systems, design <li>lack of support for the 1090-MHz ADS-B channel on any consumer handhe
ed in the early 2000s. Broadcast RID is conceptually similar to ADS-B, but with ld devices</li>
the receiver target being the general public on generally available devices (e.g <li>Cost, Size, Weight, and Power (CSWaP) requirements of ADS-B transpon
., smartphones).</t> ders on CSWaP-constrained UA</li>
<li>limited bandwidth of both uplink and downlink, which would likely be
<t>For numerous technical reasons, ADS-B itself is not suitable for low-flying s saturated by large numbers of UAS, endangering manned aviation</li>
mall UAS. Technical reasons include but are not limited to the following:</t> </ol>
<t>Understanding these technical shortcomings, regulators worldwide have r
<t><list style="numbers"> uled out the use of ADS-B for the small UAS for which UAS RID and DRIP are inten
<t>Lack of support for the 1090 MHz ADS-B channel on any consumer handheld dev ded.</t>
ices</t> </section>
<t>Cost, Size, Weight and Power (CSWaP) requirements of ADS-B transponders on <section numbered="false" anchor="acknowledgments">
CSWaP constrained UA</t> <name>Acknowledgments</name>
<t>Limited bandwidth of both uplink and downlink, which would likely be satura <t>The work of the FAA's UAS Identification and Tracking (UAS ID) Aviation
ted by large numbers of UAS, endangering manned aviation</t> Rulemaking Committee (ARC) is the foundation of later ASTM and IETF DRIP WG eff
</list></t> orts. The work of ASTM F38.02 in balancing the interests of diverse stakeholder
s is essential to the necessary rapid and widespread deployment of UAS RID. Than
<t>Understanding these technical shortcomings, regulators worldwide have ruled o ks to <contact fullname="Alexandre Petrescu"/>, <contact fullname="Stephan Wenge
ut the use of ADS-B for the small UAS for which UAS RID and DRIP are intended.</ r"/>, <contact fullname="Kyle Rose"/>, <contact fullname="Roni Even"/>, <contact
t> fullname="Thomas Fossati"/>, <contact fullname="Valery Smyslov"/>, <contact ful
lname="Erik Kline"/>, <contact fullname="John Scudder"/>, <contact fullname="Mur
</section> ray Kucheraway"/>, <contact fullname="Robert Wilton"/>, <contact fullname="Roman
<section numbered="no" anchor="acknowledgments"><name>Acknowledgments</name> Daniliw"/>, <contact fullname="Warren Kumari"/>, <contact fullname="Zaheduzzama
n Sarker"/>, and <contact fullname="Dave Thaler"/> for the reviews and helpful p
<t>The work of the FAA's UAS Identification and Tracking (UAS ID) Aviation Rulem ositive comments. Thanks to <contact fullname="Laura Welch"/> for her assistance
aking Committee (ARC) is the foundation of later ASTM and IETF DRIP WG efforts. in greatly improving this document. Thanks to <contact fullname="Dave Thaler"/>
The work of ASTM F38.02 in balancing the interests of diverse stakeholders is e for showing our authors how to leverage the RATS model for attestation in DRIP.
ssential to the necessary rapid and widespread deployment of UAS RID. Thanks to Thanks to chairs <contact fullname="Daniel Migault"/> and <contact fullname="Mo
Alexandre Petrescu, Stephan Wenger, Kyle Rose, Roni Even, Thomas Fossati, Valery hamed Boucadair"/> for direction of our team of authors and editors, some of who
Smyslov, Erik Kline, John Scudder, Murray Kucheraway, Robert Wilton, Roman Dani m are relative newcomers to writing IETF documents. Thanks especially to Intern
liw, Warren Kumari, Zaheduzzaman Sarker and Dave Thaler for the reviews and help et Area Director <contact fullname="Éric Vyncke"/> for guidance and support.</t>
ful positive comments. Thanks to Laura Welch for her assistance greatly improvin </section>
g this document. Thanks to Dave Thaler for showing our authors how to leverage t
he RATS model for attestation in DRIP. Thanks to chairs Daniel Migault and Moham
ed Boucadair for direction of our team of authors and editor, some of whom are r
elative newcomers to writing IETF documents. Thanks especially to Internet Area
Director Eric Vyncke for guidance and support.</t>
</section>
</back> </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> </rfc>
 End of changes. 55 change blocks. 
2149 lines changed or deleted 1240 lines changed or added

This html diff was produced by rfcdiff 1.48.