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

<!-- draft submitted in xml v3 -->

<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?> [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

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

<!-- xml2rfc v2v3 conversion 2.37.1 -->
<front>
	<title abbrev="DRIP Requirements">Drone Remote Identification Protocol (DRIP) Requirements</title> Requirements and Terminology
	</title>

	<seriesInfo name="Internet-Draft" value="draft-ietf-drip-reqs-18"/> name="RFC" value="9153"/>
	<author fullname="Stuart W. Card"
	initials="S." surname="Card" role="editor">
	<organization>AX Enterprize</organization>
	<address>
	  <postal>
		<street>4947 Commercial Drive</street>
		<city>Yorkville</city>
		<region>NY</region>
		<code>13495</code>
		<country>USA</country>
		<country>United States of America</country>
	  </postal>
	  <email>stu.card@axenterprize.com</email>
	</address>
	</author>
	<author fullname="Adam Wiethuechter"
	initials="A." surname="Wiethuechter">
	<organization>AX Enterprize</organization>
	<address>
	  <postal>
		<street>4947 Commercial Drive</street>
		<city>Yorkville</city>
		<region>NY</region>
		<code>13495</code>
		<country>USA</country>
		<country>United States of America</country>
	  </postal>
	  <email>adam.wiethuechter@axenterprize.com</email>
	</address>
	</author>
	<author fullname="Robert Moskowitz"
	initials="R" surname="Moskowitz">
	<organization>HTT Consulting</organization>
	<address>
	  <postal>
		<street/>
		<city>Oak Park</city>
		<region>MI</region>
		<code>48237</code>
		<country>USA</country>
		<country>United States of America</country>
	  </postal>
	  <email>rgm@labs.htt-consult.com</email>
	</address>
	</author>
	<author fullname="Andrei Gurtov" initials="A." surname="Gurtov">
	<organization>Linköping University</organization>
	<address>
	  <postal>
		<street>IDA</street>
        <city>Linköping</city>
        <code>58183</code>
        <country>Sweden</country>
      </postal>
      <email>gurtov@acm.org</email>
    </address>
    </author>
    <date year="2021"/> year="2022" month="February" />
    <area>Internet</area>
    <workgroup>DRIP</workgroup>
    <keyword>RFC</keyword>
    <keyword>Request for Comments</keyword>
    <keyword>I-D</keyword>
    <keyword>Internet-Draft</keyword>
    <keyword>DRIP</keyword>
<abstract>
  <t>
  This document defines terminology and requirements for solutions produced by
  the Drone Remote Identification Protocol (DRIP) Working Group Group. These
  solutions to will support Unmanned Aircraft System Remote Identification and
  tracking (UAS RID) for security, safety, and other purposes (e.g.,
  initiation of
	identity based identity-based network sessions supporting UAS applications).
  DRIP will facilitate use of existing Internet resources to support RID and
  to enable enhanced related services, and it will enable online and offline
  verification that RID information is trustworthy.
</t>
</abstract>
</front>
<middle>
  <section numbered="true" toc="default"> <name>Introduction</name>
  <t>
  This document defines terminology and requirements for solutions produced by
  the Drone Remote Identification Protocol (DRIP) Working Group. These
  solutions will support Unmanned Aircraft System Remote Identification and
  tracking (UAS RID) for security, safety, and other purposes (e.g.,
  initiation of identity-based network sessions supporting UAS applications).
  DRIP will facilitate use of existing Internet resources to support RID and
  to enable enhanced related services, and it will enable online and offline
  verification that RID information is trustworthy.
</t>

<t>
	For any unfamiliar or <em>a priori</em> a priori ambiguous terminology
	herein, see <xref target="terms" format="default"/>.
</t>
<section numbered="true" toc="default"> <name>Motivation and External Influences</name>
<t>
	Many considerations (especially safety and security) necessitate
	Unmanned Aircraft Systems (UAS) System Remote Identification and tracking
	(RID).
	(UAS RID).
</t>

<t>
	Unmanned Aircraft (UA) may be fixed wing, rotary wing fixed-wing, rotary-wing (e.g.,
	helicopter), hybrid, balloon, rocket, etc. Small fixed wing fixed-wing UA
	typically have Short Take-Off and Landing (STOL) capability; rotary
	wing rotary-wing and
	hybrid UA typically have Vertical Take-Off and Landing
	(VTOL) capability. UA may be single- or multi-engine. The most
	common today are multicopters: rotary wing, multi engine. multicopters (rotary-wing, multi-engine). The
	explosion in UAS was enabled by hobbyist development, for
	multicopters, development
        of advanced flight stability algorithms, enabling algorithms for multicopters that enabled even
        inexperienced pilots to take off, fly to a location of interest,
        hover, and return to the take-off takeoff location or land at a
	distance. UAS can be remotely piloted by a human (e.g., with a
	joystick) or programmed to proceed from Global Navigation Satellite
	System (GNSS) waypoint to waypoint in a weak form of autonomy;
	stronger autonomy is coming.
</t>
<t>
	Small UA are "low observable" as they:
</t>
<ul spacing="normal" empty="false">
	<li>
		typically have small radar cross sections;
	</li>
	<li>
		make noise that is quite noticeable at short ranges but difficult to
		detect at distances they can quickly close (500 meters in under
		13 seconds by the fastest consumer mass market mass-market drones available
		in early 2021);
	</li>
	<li>
		typically fly at low altitudes (e.g.,
		under 400 feet Above Ground Level (AGL) for those UA to which RID applies in the US, under 400 feet Above Ground Level (AGL) as
		per <xref target="Part107" format="default"/>); and
	</li>
	<li>
		are highly maneuverable so and thus can fly under trees and between
		buildings.
	</li>
</ul>
<t>
	UA can carry payloads including (including sensors, cyber weapons, and kinetic weapons, weapons)
	or can be used themselves as weapons by flying them into targets.
	They can be flown by clueless, careless, or criminal operators.
	Thus
	Thus, the most basic function of UAS RID is "Identification Friend
	or Foe" (IFF) Foe (IFF)" to mitigate the significant threat they present.
</t>
<t>
        Diverse other applications can be enabled or facilitated by RID.
        Internet protocols typically start out with at least one entity
        already knowing an identifier or locator of another; but an entity
	(e.g., UAS or Observer device) encountering an <em>a priori</em> a priori
	unknown UA in physical space has no identifier or logical space
	locator for that UA, unless and until one is provided somehow. RID
	provides an identifier, which, if well chosen, can facilitate use
	of a variety of Internet family protocols and services to support
	arbitrary applications, applications beyond the basic security functions of RID.
	For most of these, some type of identifier is essential, e.g.,
	Network Access Identifier (NAI), Digital Object Identifier (DOI),
	Uniform Resource Identifier (URI), domain name, or public key. DRIP
	motivations include both the basic security and the broader
	application support functions of RID. The general scenario is
	illustrated in <xref target="Scenario" format="default"/>.
</t>
<figure anchor="Scenario">
<name>"General
<name>General UAS RID Usage Scenario"</name> Scenario</name>
<artwork type="ascii-art">
               +-----+    +-----+
               | UA1 |    | UA2 |
               +-----+    +-----+

   +----------+                   +----------+
   | General  |                   | Public   |
   | Public   |                   | Safety   |
   | Observer o------\     /------o Observer |
   +----------+      |     |      +----------+
                     |     |
                  *************
+----------+      *           *      +----------+
| UA1      |      *           *      | UA2      |
| Pilot/   o------*  Internet *------o Pilot/   |
| Operator |      *           *      | Operator |
+----------+      *           *      +----------+
                  *************
                    |   |   |
     +----------+   |   |   |   +----------+
     | Public   o---/   |   \---o Private  |
     | Registry |       |       | Registry |
     +----------+       |       +----------+
                     +--o--+
                     | DNS |
                     +-----+
</artwork>
</figure>
<t>
	<xref target="Scenario" format="default"/> illustrates a typical
	case where there may be: be the following:
</t>
<ul>
     <li> multiple Observers, some of them members of the general public, public
      and others government officers with public
	safety/security responsibilities; safety and security
      responsibilities,</li>

     <li> multiple UA in flight within observation range, each with its own pilot/operator;
       pilot/operator,</li>

     <li> at least one registry each for lookup of public and (by authorized
       parties only) private information regarding the UAS and their pilots/operators;
	and
       pilots/operators, and</li>

     <li> in the DRIP vision, DNS resolving various identifiers and locators
       of the entities involved.
</t> involved.</li>
</ul>
<t>
	Note the absence of any links to/from the UA in the figure; this is
	because UAS RID and other connectivity involving the UA varies.
	Some connectivity paths do or do not exist depending upon the
	scenario. Command and Control (C2) from the GCS Ground Control Station (GCS) to the UA via the
	Internet (e.g., using LTE cellular) is expected to become much more
	common as Beyond Visual Line Of Sight (BVLOS) operations increase;
	in such a case, there is typically not also a direct wireless link
	between the GCS and UA. Conversely, if C2 is running over a direct
	wireless link, then typically the GCS typically has Internet
	connectivity, but the UA lacks Internet
	connectivity. does not. Further, paths that nominally exist, such as between
	an Observer device and the Internet, may be severely intermittent.
	These connectivity constraints are likely to have an impact, e.g.,
	on how reliably DRIP requirements can be satisfied.
</t>
<t>
	An Observer of UA may need to classify them, as illustrated
	notionally in <xref target="Classification" format="default"/>, for
	basic airspace Situational Awareness (SA).
   An Observer who
	classifies can classify a UAS: UAS as Taskable, one of the following and treat as:
</t>
<ul>
   <li> Taskable: can ask it to do something useful;
	as useful.</li>

   <li> Low Concern, Concern: can reasonably assume it is not
     malicious and would cooperate with requests to modify its flight
     plans for safety concerns that arise; as arise.</li>

   <li> High Concern or Unidentified, Unidentified: can focus surveillance on it.
</t> it.</li>
</ul>

<figure anchor="Classification">
<name>"Notional
<name>Notional UAS Classification"</name> Classification</name>
<artwork type="ascii-art">
                     xxxxxxx
                    x       x   No  +--------------+
                   x   ID?   x+---->| Unidentified |
                    x       x       +--------------+
                     xxxxxxx
                        +
                        | Yes
                        v
                     xxxxxxx
                    x       x
        .---------+x  Type?  x+----------.
        |           x       x            |
        |            xxxxxxx             |
        |               +                |
        v               v                v
+--------------+ +--------------+ +--------------+
|  Taskable    | | Low Concern  | | High Concern |
+--------------+ +--------------+ +--------------+
</artwork>
</figure>

<t>
	The widely cited "Standard Specification for Remote ID and Tracking" <xref
        target="F3411-19" format="default"/> was developed by ASTM International, Technical Committee F38 (UAS), Subcommittee F38.02
	(Aircraft Operations), Work Item WK65041, developed the
	widely cited Standard Specification for Remote ID and Tracking
	<xref target="F3411-19" format="default"/>: the WK65041.
        The published standard is
	available for purchase from ASTM and is also available as an ASTM membership premium;
	early drafts draft versions are freely available as Open Drone ID specifications
	<xref target="OpenDroneID" format="default"/> specifications. format="default"/>. <xref target="F3411-19"
	format="default"/> is frequently referenced in DRIP, where building
	upon its link layers and both enhancing support for and expanding the
	scope of its applications are central foci.
</t>
<t>
	In many applications, including UAS RID, identification and
	identifiers are not ends in themselves; they exist to enable
	lookups and provision of other services.
</t>

<t>
	Using UAS RID to facilitate vehicular (V2X) (i.e., Vehicle-to-Everything (V2X)) communications and
	applications such as Detect And Avoid (DAA), which would impose
	tighter latency bounds than RID itself, is an obvious possibility, possibility; this is
	explicitly contemplated in the United States (US) Federal Aviation
	Administration (FAA) Remote "Remote Identification of Unmanned Aircraft Aircraft"
	rule of the US Federal Aviation
	Administration (FAA) <xref target="FRUR" format="default"/>. However, usage of RID
	systems and information beyond mere identification (primarily to
	hold operators accountable after the fact), including DAA, have
	been were
	declared out of scope in ASTM F38.02 WK65041, based on a
	distinction between RID as a security standard vs versus DAA as a safety
	application. Aviation community Standards Development Organizations
	(SDOs) in the aviation community generally set a higher bar for safety than for security,
	especially with respect to reliability. Each SDO has its own
	cultural set of connotations of safety vs versus security; the denotative
	definitions of the International Civil Aviation Organization (ICAO)
	are cited in <xref target="terms" format="default"/>.
</t>

<t>
	<xref target="Opinion1" format="default"/> and <xref target="WG105"
	format="default"/> cite the Direct Remote Identification (DRI)
	previously required and specified, explicitly stating that whereas
	DRI is primarily for security purposes, the "Network Identification
	Service" <xref target="Opinion1" format="default"/> (in the context
	of U-space <xref target="InitialView" format="default"/>) or
	"Electronic Identification" <xref target="WG105" format="default"/>
	is primarily for safety purposes (e.g., Air Traffic Management,
	especially hazards deconfliction) and also is allowed to be used
	for other purposes such as support of efficient operations. These
	emerging standards allow the security security- and safety oriented safety-oriented systems
	to be separate or merged. In addition to mandating both Broadcast
	and Network RID one-way to Observers, they will use V2V Vehicle-to-Vehicle (V2V) to other UAS
	(also likely to and/or from some manned aircraft). These reflect
	the broad scope of the European Union (EU) U-space concept, as
	being developed in the Single European Sky ATM Research (SESAR)
	Joint Undertaking, the U-space architectural principles of which
	are outlined in <xref target="InitialView" format="default"/>.
</t>

<t>
	ASD-STAN is an Associated Body to CEN (European Committee for
	Standardization) for Aerospace Standards. It is publishing has published an EU
	standard titled "Aerospace series - Unmanned Aircraft Systems - Part 002:
	Direct Remote Identification; English version prEN 4709-002:2020"
	for which Identification" <xref target="ASDSTAN4709-002" format="default"/>;
	a current (early 2021) informal overview is freely
	available in <xref target="ASDRI" format="default"/>. format="default"/> (note that <xref target="ASDRI" format="default"/> may not precisely reflect the final standard as it was published before <xref target="ASDSTAN4709-002" format="default"/>). It will
	provide compliance to cover the identical DRI requirements
	applicable to drones of classes C1 - <xref the following classes:
</t>
<ul>
   <li>C1 (<xref target="Delegated"
	format="default"/> format="default"/>, Part 2, C2 - <xref 2) </li>
   <li>C2 (<xref target="Delegated"
	format="default"/> format="default"/>, Part 3, C3 - <xref 3) </li>
   <li>C3 (<xref target="Delegated"
	format="default"/> format="default"/>, Part 4, C5 - <xref 4) </li>
   <li>C5 (<xref target="Amended"
	format="default"/> format="default"/>, Part 16, and C6 - <xref 16) </li>
   <li>C6 (<xref target="Amended"
	format="default"/> format="default"/>, Part 17.
</t> 17) </li>
</ul>
<t>
	The standard contemplated in <xref target="ASDRI"
	format="default"/> will provide UA capability to be identified in
	real time during the whole duration of the flight, without specific
	connectivity or ground infrastructure link, utilizing existing
	mobile devices within broadcast range. It will use Bluetooth 4,
	Bluetooth 5, Wi-Fi Neighbor Awareness Networking (NAN, also (NAN) (also known
	as Wi-Fi Aware, "Wi-Fi Aware" <xref target="WiFiNAN" format="default"/>) format="default"/>), and/or
	IEEE 802.11 Beacon modes. The emphasis of the EU standard emphasis was is
	compatibility with <xref target="F3411-19" format="default"/>,
	although there are differences in mandatory and optional message
	types and fields.
</t>
<t>
	The DRI system contemplated in <xref target="ASDRI" format="default"/> contemplated DRI system
	will broadcast the following locally:
</t>
<ol spacing="normal" type="1">
	<li>
		the UAS operator registration number;
	</li>
	<li>
		the <xref target="CTA2063A" format="default"/> compliant format="default"/>-compliant unique
		serial number of the UA;
	</li>
	<li>
		a time stamp, the geographical position of the UA, and its
		height AGL or above its take-off takeoff point;
	</li>
	<li>
		the UA ground speed and route course measured clockwise from
		true north;
	</li>
	<li>
		the geographical position of the remote pilot, Remote Pilot, or if that is
		not available, the geographical position of the UA take-off takeoff
		point; and
	</li>
	<li>
		for Classes classes C1, C2, C3, the UAS emergency status.
	</li>
</ol>
<t>
	Under the
	standard contemplated in <xref target="ASDRI" format="default"/> contemplated
	standard, format="default"/>, data will be sent in plain text plaintext, and the UAS operator
	registration number will be represented as a 16-byte string
	including the (European) state code. The corresponding private ID
	part will contain 3 three characters that are not broadcast but used by
	authorities to access regional registration databases for
	verification.
</t>

<t>
	ASD-STAN also contemplates corresponding Network Remote Identification
	(NRI) functionality. The  ASD-STAN RID target is plans to revise their current standard
	with additional functionality (e.g., DRIP) to be published before no later
	than 2022 <xref target="ASDRI" format="default"/>.
</t>
<t>
	Security oriented
	Security-oriented UAS RID essentially has two goals: 1) enable the
	general public to obtain and record an opaque ID for any observed
	UA, which they can then report to authorities; authorities and 2) enable
	authorities, from such an ID, to look up information about the UAS
	and its operator. Safety oriented Safety-oriented UAS RID has stronger
	requirements.
</t>
<t>
	Although dynamic
	Dynamic establishment of secure communications between the Observer
	and the UAS pilot seems to have been contemplated by the FAA UAS ID
	and Tracking Aviation Rulemaking Committee (ARC) in
	their <xref
	target="Recommendations" format="default"/>, format="default"/>; however, aside from DRIP,
	it is not addressed in any of the subsequent regulations subsequent regulations or
	international SDO technical specifications, other than DRIP, specifications known to the authors as of
	early 2021.
</t>
</section>
<section numbered="true" toc="default"> <name>Concerns and Constraints</name>
<t>
	Disambiguation of multiple UA flying in close proximity may be very
	challenging, even if each is reporting its identity, position, and
	velocity as accurately as it can.
</t>
<t>
	The origin of information in UAS RID and UAS Traffic Management
	(UTM) generally is the UAS or its operator. Self-reports may be
	initiated by the remote pilot Remote Pilot at the console of the Ground Control
	Station (GCS, the GCS (the UAS subsystem used to remotely operate the UA), UA)
	or automatically by GCS software; in Broadcast RID, they are typically
	would be
	initiated automatically by a process on the UA. Data in
	the reports may come from sensors available to the operator (e.g.,
	radar or cameras), the GCS (e.g., "dead reckoning" UA location,
	starting from the takeoff location and estimating the displacements
	due to subsequent piloting commands, wind, etc.), or the UA itself
	(e.g., an on-board GNSS receiver); in receiver). In Broadcast RID, all the data
	must be sent proximately by, by the UA, and most of the data comes ultimately
	from, comes
	from the UA itself. UA. Whether information comes proximately from the
	operator,
	operator or from automated systems configured by the operator,
	there are possibilities not only of unintentional error in but also
	of and
	intentional falsification of this data.
	Mandating UAS RID,
	specifying data elements required to be sent, monitoring compliance compliance,
	and enforcing it compliance (or penalizing non-compliance) are matters for
	Civil Aviation Authorities (CAAs) et al; specifying and potentially other authorities. Specifying message
	formats, etc.
	formats and supporting technologies to carry those data elements has been addressed by
	other SDOs; offering SDOs. Offering technical means, as extensions to external
	standards, to facilitate verifiable compliance and
	enforcement/monitoring, are opportunities
	enforcement/monitoring is an opportunity for DRIP.
</t>
<t>
	Minimal specified information must be made available to the public.
	Access to other data, e.g., UAS operator Personally Identifiable
	Information (PII), must be limited to strongly authenticated
	personnel, properly authorized in accordance with applicable
	policy. The balance between privacy and transparency remains a
	subject for public debate and regulatory action; DRIP can only
	offer tools to expand the achievable trade space and enable
	trade-offs within that space. <xref target="F3411-19"
	format="default"/>, the basis for most current (2021) thinking
	about and efforts to provide UAS RID, specifies only how to get the
	UAS ID to the Observer: how the Observer can perform these lookups
	and how the registries first can be populated with information are
	unspecified
	not specified therein.
</t>

<t>
	The need for nearly universal deployment of UAS RID is pressing:
	consider how negligible the value of an automobile license plate
	system would be if only 90% of the cars displayed plates. This
	implies the need to support use by Observers of already ubiquitous already-ubiquitous
	mobile devices (typically smartphones and tablets). Anticipating
        CAA requirements to support legacy devices, especially in light of
        <xref target="Recommendations" format="default"/>, <xref
        target="F3411-19" format="default"/> specifies that any UAS sending
        Broadcast RID over Bluetooth must do so over Bluetooth 4,
        regardless of whether it also does so over newer versions; as versions. As UAS
        sender devices and Observer receiver devices are unpaired, this
	implies
        unpaired state requires use of the extremely short BT4 "advertisement"
        (beacon) frames.
</t>
<t>
	Wireless data links to or from UA are challenging. Flight is often
	amidst structures and foliage at low altitudes over varied terrain.
	UA are constrained in both total energy and instantaneous power by
	their batteries. Small UA imply small antennas. Densely populated
	volumes will suffer from link congestion: even if UA in an airspace
	volume are few, other transmitters nearby on the ground, sharing
	the same license free spectral band, may be many. Thus air to air Thus, air-to-air
	and air to ground air-to-ground links will generally be slow and unreliable.
</t>
<t>
	UAS Cost, Size, Weight, and Power (CSWaP) constraints are severe.
	CSWaP is a burden not only on the designers of new UAS for sale, sale
	but also on owners of existing UAS that must be retrofit. Radio
	Controlled (RC) aircraft modelers, "hams" who use licensed amateur
	radio frequencies to control UAS, drone hobbyists, and others who
	custom build UAS, UAS all need means of participating in UAS RID, RID
	that are sensitive to both generic CSWaP and application-specific
	considerations.
</t>
<t>
  To accommodate the most severely constrained cases, all these of the concerns described above
  conspire to motivate system design decisions that complicate the
  protocol design problem.
</t>
<t>
	Broadcast RID uses one-way local data links. UAS may have Internet
	connectivity only intermittently, or not at all, during flight.
</t>
<t>
	Internet-disconnected operation of Observer devices has been deemed
	by ASTM F38.02 as too infrequent to address. However, the preamble to
	<xref target="FRUR" format="default"/> cites "remote and rural
	areas that do not have reliable Internet access" as a major reason
	for requiring Broadcast rather than Network RID, and states that
	"Personal RID. <xref target="FRUR" format="default"/> also states:</t>
	<blockquote>
	Personal wireless devices that are capable of receiving 47 CFR
	part 15 frequencies, such as smart phones, tablets, or other
	similar commercially available devices, will be able to receive
	broadcast remote identification information directly without
	reliance on an Internet connection". Internet-disconnected connection.
        </blockquote>
	<t>Internet-disconnected
	operation presents challenges, e.g., for Observers needing access
	to the <xref target="F3411-19" format="default"/> web based web-based
	Broadcast Authentication Verifier Service or needing to do external
	lookups.
</t>
<t>
	As RID must often operate within these constraints, heavyweight
	cryptographic security protocols or even simple cryptographic
	handshakes are infeasible, yet trustworthiness of UAS RID
	information is essential. Under <xref target="F3411-19"
	format="default"/>, <em>even the most basic datum, the UAS ID
	itself, can be merely an unsubstantiated claim</em>.
</t>

<t>
	Observer devices being ubiquitous, thus are ubiquitous; thus, they are popular targets for malware
	or other compromise, so they cannot be generally trusted (although the user
	of each device is compelled to trust that device, to some extent);
	a extent).
	A "fair witness" functionality (inspired by <xref target="Stranger"
	format="default"/>) is desirable.
</t>
<t>
	Despite work by regulators and SDOs, there are substantial gaps in
	UAS standards generally and UAS RID specifically. <xref
	target="Roadmap" format="default"/> catalogs UAS related UAS-related standards,
	ongoing standardization activities activities, and gaps (as of 2020); Section
	7.8 catalogs those related specifically to UAS RID. DRIP will
	address the most fundamental of these gaps, as foreshadowed above.
</t>
</section>
<section numbered="true" toc="default"> <name>DRIP Scope</name>

<t>
	DRIP’s
 DRIP's initial charter objective is to make RID immediately actionable,
 especially in
	both Internet and local-only connected scenarios (especially
	emergencies), emergencies, in severely constrained UAS environments, environments
 (both Internet and local-only connected scenarios), balancing legitimate
 (e.g., public safety) authorities’ authorities' Need To Know trustworthy information
 with UAS operators’ operators' privacy. By
	The phrase
	"immediately actionable" is meant means information of sufficient
	precision, accuracy, timeliness, etc. and timeliness for an Observer to use it as
	the basis for immediate decisive action, whether that be to trigger action (e.g., triggering
	a defensive counter-UAS system, to attempt attempting to initiate
	communications with the UAS operator, to accept accepting the presence of the
	UAS in the airspace where/when observed as not requiring further
	action, or whatever, etc.) with potentially severe consequences of any
	action or inaction chosen based on that information. For further
	explanation of the concept of immediate actionability, see <xref
	target="ENISACSIRT" format="default"/>.
</t>
<t>
	Note that UAS RID must achieve nearly universal adoption, but DRIP can
	add value even if only selectively deployed. Authorities with
	jurisdiction over more sensitive airspace volumes may set a higher
	than generally mandated RID requirement
	requirement, for flight in such volumes. volumes, that is higher than generally
	mandated.  Those with a greater need for high-confidence IFF can equip
	with DRIP, enabling strong authentication of their own aircraft and
	allied operators without regard for the weaker (if any) authentication
	of others.
</t>
<t>
	DRIP (originally Trustworthy "Trustworthy Multipurpose Remote Identification,
	TM-RID) potentially Identification
	(TM-RID)") could be applied to verifiably identify other types of
	registered things reported to be in specified physical
	locations, and providing
	locations. Providing timely trustworthy identification data is also
	prerequisite to identity-oriented networking, but networking. Despite the value of
	DRIP to these and other potential applications, UAS RID is the urgent
	motivation and clear initial focus is UAS. of DRIP. Existing Internet
	resources (protocol standards, services, infrastructure, and business
	models) should be leveraged.
</t>
</section>
<section numbered="true" toc="default"> <name>Document Scope</name>
<t>
	This document describes the problem space for UAS RID conforming to
	proposed regulations and external technical standards, defines
	common terminology, specifies numbered requirements for DRIP,
	identifies some important considerations (IANA, security, privacy privacy,
	and transparency), and discusses limitations.
</t>
<t>
	A natural Internet-based approach to meet these requirements is
	described in a companion architecture document <xref
	target="I-D.ietf-drip-arch" format="default"/> and elaborated in
	other DRIP documents.
</t>
</section>
</section>
<section anchor="terms" numbered="true" toc="default"> <name>Terms and Definitions</name>
<section numbered="true" toc="default"> <name>Requirements Terminology</name>

        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119" format="default"/> target="RFC2119"/> <xref
	target="RFC8174" format="default"/> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>

</section>
<section numbered="true" toc="default"> <name>Definitions</name>

<t>
  This section defines a non-comprehensive set of terms expected to be
  used in DRIP documents.  This list is meant to be the DRIP
  terminology reference; as such, some of the terms listed below are
  not used in this document.
</t>
<t>
	<xref target="RFC4949" format="default"/> provides a glossary
	of Internet security terms that should be used where applicable.
</t>
<t>
	In the UAS community, the plural form of acronyms generally is the
	same as the singular form, e.g., Unmanned Aircraft System (singular)
	and Unmanned Aircraft Systems (plural) are both represented as UAS.
	On this and other terminological issues, to
  To encourage comprehension necessary for adoption of DRIP by the
  intended user community, that the UAS community's norms are respected
  herein, and definitions are quoted in cases where they have been
  found in that community's documents.  Most of the listed terms listed
  below are from that community (even if specific source documents
  are not cited); any terms that are DRIP-specific or
	invented defined by the authors of
  this document are marked "(DRIP)".
</t>
<t>
  Note that, in the UAS community, the plural form of an acronym,
  generally, is the same as the singular form, e.g., Unmanned Aircraft
  System (singular) and Unmanned Aircraft Systems (plural) are both
  represented as UAS.
</t>
<t>
	<xref target="RFC4949" format="default"/> provides a glossary
	of Internet security terms that should be used where applicable.
</t>

	<dl newline="true" spacing="normal">
		<dt>4-D</dt>
		<dd>
			Four-dimensional. Latitude, Longitude, Altitude, Time. Used
			especially to delineate an airspace volume in which an
			operation is being or will be conducted.
		</dd>
		<dt>AAA</dt>
		<dd>
			Attestation, Authentication, Authorization, Access Control,
			Accounting, Attribution, Audit, or any subset thereof (uses
			differ by application, author, and context). (DRIP)
		</dd>
		<dt>ABDAA</dt>
		<dd>
			AirBorne DAA. Accomplished using systems onboard the
			aircraft involved. Supports "self-separation" (remaining
			"well clear" of other aircraft) and collision avoidance.
		</dd>
		<dt>ADS-B</dt>
		<dd>
			Automatic Dependent Surveillance - Broadcast. "ADS-B Out"
			equipment obtains aircraft position from other on-board
			systems (typically GNSS) and periodically broadcasts it to
			"ADS-B In" equipped entities, including other aircraft,
			ground stations, and satellite based satellite-based monitoring systems.
		</dd>
		<dt>AGL</dt>
		<dd>
			Above Ground Level. Relative altitude, above the variously
			defined local ground level, typically of a UA, measured in
			feet or meters. Should be explicitly specified as either
			barometric (pressure) or geodetic (GNSS) altitude.
		</dd>
		<dt>ATC</dt>
		<dd>
			Air Traffic Control. Explicit flight direction to pilots
			from ground controllers. Contrast with ATM.
		</dd>
		<dt>ATM</dt>
		<dd>
			Air Traffic Management. A broader functional and geographic
			scope and/or a higher layer of abstraction than ATC.
			<xref
                        target="ICAOATM" format="default"/> defines ATM as the following: "The
			dynamic, integrated management of air traffic and airspace
			including air traffic services, airspace management and air
			traffic flow management - -- safely, economically and
			efficiently - -- through the provision of facilities and
			seamless services in collaboration with all parties and
			involving airborne and ground-based functions" <xref
			target="ICAOATM" format="default"/>. functions".
				</dd>
		<dt>Authentication Message</dt>
		<dd>
			<xref target="F3411-19" format="default"/> Message Type 2.
			Provides framing for authentication data, data only; the only
			message that can be extended in length by segmenting it
			across more than one page.
		</dd>
		<dt>Basic ID Message</dt>
		<dd>
			<xref target="F3411-19" format="default"/> Message Type 0.
			Provides UA Type, UAS ID Type (and Specific Session ID
			subtype if applicable), and UAS ID, ID only.
		</dd>
		<dt>Broadcast Authentication Verifier Service</dt>
		<dd>
			System component designed to handle any authentication of
			Broadcast RID by offloading signature verification to a web
			service <xref target="F3411-19" format="default"/>.
		</dd>
		<dt>BVLOS</dt>
		<dd>
			Beyond Visual Line Of Sight. See VLOS.
		</dd>
		<dt>byte</dt>
		<dd>
			Used here in its now-customary sense as a synonym for
			"octet", as "byte" is used exclusively in definitions of
			data structures specified in <xref target="F3411-19"
			format="default"/>
			format="default"/>.
		</dd>
		<dt>CAA</dt>
		<dd>
			Civil Aviation Authority of a regulatory jurisdiction.
			Often so named, but other examples include the United
			States Federal Aviation Administration (FAA) and the Japan
			Civil Aviation Bureau.
		</dd>
		<dt>CSWaP</dt>
		<dd>
			Cost, Size, Weight, and Power. Power
		</dd>
		<dt>C2</dt>
		<dd>
			Command and Control. Previously mostly used in military
			contexts. Properly refers to a function, function that is exercisable over
			arbitrary communications; communications, but in the small UAS context,
			often refers to the communications (typically RF data link)
			over which the GCS controls the UA.
		</dd>
		<dt>DAA</dt>
		<dd>
			Detect And Avoid, formerly Sense "Sense And Avoid (SAA). (SAA)". A
			means of keeping aircraft "well clear" of each other
			and obstacles for safety. <xref target="ICAOUAS"
			format="default"/> defines DAA as the following: "The
			capability to see, sense or detect conflicting traffic
			or other hazards and take the appropriate action to
			comply with the applicable rules of
			flight" <xref target="ICAOUAS" format="default"/>. flight".
		</dd>

		<dt>DRI (not to be confused with DRIP)</dt>
		<dd>
			Direct Remote Identification. EU regulatory requirement for
			"a system that ensures the local broadcast of information
			about a UA in operation, including the marking of the UA,
			so that this information can be obtained without physical
			access to the UA". UA" <xref target="Delegated"
			format="default"/> that presumably
			format="default"/>. This requirement can presumably be satisfied with
			appropriately configured <xref target="F3411-19"
			format="default"/> Broadcast RID.
		</dd>
		<dt>DSS</dt>
		<dd>
			Discovery and Synchronization Service. The UTM system
			overlay network backbone. Most importantly, it enables one
			USS to learn which other USS have UAS operating in a given
			4-D airspace volume, for strategic deconfliction of planned
			operations and Network RID surveillance of active
			operations. See <xref target="F3411-19" format="default"/> format="default"/>.
		</dd>
		<dt>EUROCAE</dt>
		<dd>
			European Organisation for Civil Aviation Equipment.
			Aviation SDO, originally European, now with broader
			membership. Cooperates extensively with RTCA.
		</dd>
		<dt>GBDAA</dt>
		<dd>
			Ground Based
			Ground-Based DAA. Accomplished with the aid of ground based ground-based
			functions.
		</dd>
		<dt>GCS</dt>
		<dd>
			Ground Control Station. The part of the UAS that the remote
			pilot Remote
			Pilot uses to exercise C2 over the UA, whether by remotely
			exercising UA flight controls to fly the UA, by setting
			GNSS waypoints, or by otherwise directing its flight.
		</dd>
		<dt>GNSS</dt>
		<dd>
			Global Navigation Satellite System. Satellite based Satellite-based timing
			and/or positioning with global coverage, often used to
			support navigation.
		</dd>
		<dt>GPS</dt>
		<dd>
			Global Positioning System. A specific GNSS, but in the UAS
			context, the term is typically misused in place of the more
			generic term GNSS. "GNSS".
		</dd>
		<dt>GRAIN</dt>

		<dd>
			Global Resilient Aviation Interoperable
			Network. ICAO
			managed ICAO-managed IPv6 overlay internetwork based
			on IATF, IATF that is dedicated to aviation (but not just
			aircraft). Currently As currently (2021) in
			design, accommodating designed, it accommodates
			the proposed DRIP identifier.
		</dd>

		<dt>IATF</dt>

		<dd>
			International Aviation Trust Framework. ICAO effort to
			develop a resilient and secure by design framework for
			networking in support of all aspects of aviation.
		</dd>
		<dt>ICAO</dt>
		<dd>
			International Civil Aviation Organization. A United Nations
			specialized agency of the United Nations that develops and harmonizes
			international standards relating to aviation.
		</dd>
		<dt>IFF</dt>
		<dd>
			Identification Friend or Foe. Originally, Foe.&nbsp;Originally, and in its narrow
			sense still, a self-identification broadcast in response to
			interrogation via radar, radar to reduce friendly fire incidents,
			which led to military and commercial transponder systems
			such as ADS-B. In the broader sense used here, any process
			intended to distinguish friendly from potentially hostile
			UA or other entities encountered.
		</dd>
		<dt>LAANC</dt>
		<dd>
			Low Altitude Authorization and Notification Capability.
			Supports ATC authorization requirements for UAS operations:
			remote pilots
			Remote Pilots can apply to receive a near real-time
			authorization for operations under 400 feet in controlled
			airspace near airports. FAA FAA- authorized partial stopgap in
			the US until UTM comes.
		</dd>
		<dt>Location/Vector Message</dt>
		<dd>
			<xref target="F3411-19" format="default"/> Message Type 1.
			Provides UA location, altitude, heading, speed, and status.
		</dd>
		<dt>LOS</dt>
		<dd>
			Line Of Sight. An adjectival phrase describing any
			information transfer that travels in a nearly straight line
			(e.g., electromagnetic energy, whether in the visual light,
			RF, or other frequency range) and is subject to blockage. A
			term to be avoided due to ambiguity, in this context,
			between RF LOS and VLOS.
		</dd>
		<dt>Message Pack</dt>
		<dd>
			<xref target="F3411-19" format="default"/> Message Type 15.
			The framed concatenation, in message type index order, of
			at most one message of each type of any subset of the other
			types. Required to be sent in Wi-Fi NAN and in Bluetooth 5
			Extended Advertisements, if those media are used; cannot be
			sent in Bluetooth 4.
		</dd>

		<dt>MSL</dt>
		<dd>
			Mean Sea Level. Shorthand for relative altitude, above the
			variously defined mean sea level, typically of a UA (but in
			<xref target="FRUR" format="default"/> format="default"/>, also for a GCS),
			measured in feet or meters. Should be explicitly specified
			as either barometric (pressure) or geodetic (e.g., as
			indicated by GNSS, referenced to the WGS84 ellipsoid).
		</dd>

		<dt>Net-RID DP</dt>
		<dd>
			Network RID Display Provider.  <xref target="F3411-19"
			format="default"/> logical entity that aggregates data from
			Net-RID SPs as needed in response to user queries regarding
			UAS operating within specified airspace volumes, volumes to enable
			display by a user application on a user device. Potentially
			could provide not only information sent via UAS RID but
			also information retrieved from UAS RID registries or
			information beyond UAS RID. Under superseded <xref
			target="NPRM" format="default"/>, not recognized as a
			distinct entity, but as a service provided by USS, including
			Public Safety
			public safety USS that may exist primarily for this purpose
			rather than to manage any subscribed UAS.
		</dd>
		<dt>Net-RID SP</dt>

		<dd>
			Network RID Service Provider.  <xref target="F3411-19"
                        format="default"/> logical entity
			that collects RID
			messages from UAS and responds to NetRID-DP Net-RID DP queries for
			information on UAS of which it is aware. Under superseded
			<xref target="NPRM" format="default"/>, the USS to which
			the UAS is subscribed ("Remote (i.e., the "Remote ID USS").
		</dd>

		<dt>Network Identification Service</dt>
		<dd>
			EU regulatory requirement in <xref target="Opinion1"
			format="default"/> and
			format="default"/>, corresponding to the Electronic Identification for which Minimum Operational Performance Standards are specified in <xref target="WG105"
			format="default"/> that
			format="default"/>, which presumably can be satisfied with
			appropriately configured <xref target="F3411-19"
			format="default"/> Network RID.
		</dd>
		<dt>Observer</dt>
		<dd>
			An entity (typically (typically, but not necessarily necessarily, an individual
			human) who has directly or indirectly observed a UA and
			wishes to know something about it, starting with its ID. An
			Observer typically is on the ground and local (within VLOS
			of an observed UA), but could be remote (observing via
			Network RID or other surveillance), operating another UA,
			aboard another aircraft, etc. (DRIP)
		</dd>

		<dt>Operation</dt>
		<dd>
			A flight, or series of flights of the same mission, by the
			same UAS, separated by by, at most most, brief ground intervals.
			(Inferred from UTM usage, usage; no formal definition found) found.)
		</dd>
		<dt>Operator</dt>
		<dd>
			"A person, organization or
			enterprise engaged in or offering to engage in an
			aircraft operation" <xref target="ICAOUAS"
			format="default"/>.
		</dd>
		<dt>Operator ID Message</dt>
		<dd>
			<xref target="F3411-19" format="default"/> Message Type 5.
			Provides CAA issued CAA-issued Operator ID, ID only. Operator ID is
			distinct from UAS ID.
		</dd>

		<dt>page</dt>
		<dd>
			Payload of a frame, containing a chunk of a message that
			has been segmented, to allow that allows transport of a message longer
			than can be encapsulated in a single frame. See <xref
			target="F3411-19" format="default"/> format="default"/>.
		</dd>
		<dt>PIC</dt>
		<dd>
			Pilot In Command. "The pilot designated by the
			operator, or in the case of general aviation, the
			owner, as being in command and charged with the safe
			conduct of a flight" <xref target="ICAOUAS"
			format="default"/>.
		</dd>
		<dt>PII</dt>
		<dd>
			Personally Identifiable Information. In the UAS RID
			context, typically of the UAS Operator, Pilot In Command
			(PIC),
			PIC, or Remote Pilot, but possibly of an Observer or
			other party. This specific term is used primarily in the
			US; other terms with essentially the same meaning are more
			common in other jurisdictions (e.g., "personal data" in the
			EU). Used herein generically to refer to personal
			information, which
			information that the person might wish to keep private, private
			or may have a statutorily recognized right to keep private
			(e.g., under the EU <xref target="GDPR"
			format="default"/>), potentially imposing (legally or
			ethically) a confidentiality requirement on
			protocols/systems.
		</dd>
		<dt>Remote Pilot</dt>
		<dd>
			A pilot using a GCS to exercise proximate control of a UA.
			Either the PIC or under the supervision of the PIC. "The
			person who manipulates the flight controls of a
			remotely-piloted aircraft during flight time" <xref
			target="ICAOUAS" format="default"/>.
		</dd>

		<dt>RF</dt>
		<dd>
			Radio Frequency. Adjective, e.g., Can be used as an adjective (e.g., "RF link", link") or as a noun.
		</dd>
		<dt>RF LOS</dt>
		<dd>
			RF Line Of Sight. Typically used in describing a direct
			radio link between a GCS and the UA under its control,
			potentially subject to blockage by foliage, structures,
			terrain, or other vehicles, but less so than VLOS.
		</dd>
		<dt>RTCA</dt>
		<dd>
			Radio Technical Commission for Aeronautics. US aviation
			SDO. Cooperates extensively with EUROCAE.
		</dd>
		<dt>Safety</dt>
		<dd>
			"The state in which risks associated with aviation
			activities, related to, or in direct support of the
			operation of aircraft, are reduced and controlled to an
			acceptable level." From level" (from Annex 19 of the Chicago Convention,
			quoted in <xref target="ICAODEFS" format="default"/> format="default"/>).
		</dd>
		<dt>Security</dt>
		<dd>
			"Safeguarding civil aviation against acts of unlawful
			interference." From
			interference" (from Annex 17 of the Chicago Convention,
			quoted in <xref target="ICAODEFS" format="default"/> format="default"/>).
		</dd>
		<dt>Self-ID Message</dt>
		<dd>
			<xref target="F3411-19"	format="default"/> Message Type 3.
			Provides a 1 byte 1-byte descriptor and 23 byte 23-byte ASCII free text
			field, only. Expected to be used to provide context on the
			operation, e.g., mission intent.
		</dd>
		<dt>SDO</dt>
		<dd>
			Standards Development Organization. Organization, such as ASTM, IETF, et al. etc.
		</dd>
		<dt>SDSP</dt>
		<dd>
			Supplemental Data Service Provider. An entity that
			participates in the UTM system, system but provides services (e.g.,
			weather data) beyond those specified as basic UTM system functions (e.g.,
			weather data).
			functions. See <xref target="FAACONOPS" format="default"/> format="default"/>.
		</dd>
		<dt>System Message</dt>
		<dd>
			<xref target="F3411-19" format="default"/> Message Type 4.
			Provides general UAS information, including remote pilot Remote Pilot
			location, multiple UA group operational area, etc.
		</dd>

		<dt>U-space</dt>
		<dd>
			 EU concept and emerging framework for integration of
			 UAS into all classes types of airspace, specifically including high
			density but not
			 limited to volumes that are in high-density urban areas, sharing airspace
			 areas and/or shared with manned aircraft <xref
			 target="InitialView" format="default"/>.
		</dd>
		<dt>UA</dt>
		<dd>
			Unmanned Aircraft. In popular parlance, "drone". "An
			aircraft which is intended to operate with no pilot on
			board" <xref target="ICAOUAS" format="default"/>.
		</dd>
		<dt>UAS</dt>
		<dd>
			Unmanned Aircraft System. Composed of UA, all required
			on-board subsystems, payload, control station, other
			required off-board subsystems, any required launch and
			recovery equipment, all required crew members, and C2 links
			between UA and control station <xref target="F3411-19"
			format="default"/>.
		</dd>
		<dt>UAS ID</dt>
		<dd>
			UAS identifier. Although called "UAS ID", it is actually
			unique to the UA, neither to the operator (as some UAS
			registration numbers have been and for exclusively
			recreational purposes are continuing to be assigned), nor
			to the combination of GCS and UA that comprise the UAS.
			<em>Maximum length of 20 bytes</em> <xref target="F3411-19"
			format="default"/>. If the UAS ID Type is 4, the proposed
			Specific Session ID, then the 20 bytes includes the subtype
			index, leaving only 19 bytes for the actual identifier.
		</dd>
		<dt>UAS ID

		<dt>ID Type</dt>
		<dd>
			UAS Identifier identifier type index. 4 bits, see bits. See <xref
			target="IDtypes" format="default"></xref> for currently
			defined current
			standard values 0-3. 0-3 and currently proposed additional
			value 4. See also <xref target="F3411-19"
			format="default"/>
			format="default"/>.
		</dd>
		<dt>UAS RID</dt>
		<dd>
			UAS Remote Identification and tracking. System to enable
			arbitrary Observers to identify UA during flight.
		</dd>

		<dt>USS</dt>
		<dd>
			UAS Service Supplier. "A USS  is  an  entity  that assists
			UAS  Operators with meeting  UTM operational  requirements
			that enable safe and efficient use of airspace" and
			"... <xref
                        target="FAACONOPS" format="default"/>. In addition,
			"USSs provide services to support the UAS community, to
			connect Operators and other entities to enable information
			flow across the USS Network, and to promote shared
			situational awareness among UTM participants" <xref
			target="FAACONOPS" format="default"/>.
		</dd>
		<dt>UTM</dt>
		<dd>
			UAS Traffic Management. "A specific aspect of air traffic
			management which manages UAS operations safely,
			economically and efficiently through the provision of
			facilities and a seamless set of services in collaboration
			with all parties and involving airborne and ground-based
			functions" <xref target="ICAOUTM" format="default"/>. In
			the US, according to the FAA, a "traffic management"
			ecosystem for "uncontrolled" low altitude UAS operations, operations at low altitudes,
			separate from, but complementary to, the FAA's ATC system
			for "controlled" operations of manned aircraft.
		</dd>
		<dt>V2V</dt>
		<dd>
			Vehicle-to-Vehicle. Originally communications between
			automobiles, now extended to apply to communications
			between vehicles generally. Often, together with
			Vehicle-to-Infrastructure (V2I) etc., and similar functions, generalized to V2X.
		</dd>

		<dt>VLOS</dt>
		<dd>
			Visual Line Of Sight. Typically used in describing
			operation of a UA by a "remote" pilot who can clearly and
			directly (without video cameras or any aids other than
			glasses or or, under some rules rules, binoculars) see the UA and its
			immediate flight environment. Potentially subject to
			blockage by foliage, structures, terrain, or other
			vehicles, more so than RF LOS.
		</dd>
	</dl>
</section>
</section>
<section numbered="true" toc="default"> <name>UAS RID Problem Space</name>
<t>
	CAAs worldwide are mandating UAS RID. The European Union Aviation
	Safety Agency (EASA) has published <xref target="Delegated"
	format="default"/> and <xref target="Implementing"
	format="default"/> Regulations. regulations. The US FAA has published a "final"
	rule <xref target="FRUR" format="default"/> and has described the
	key role that UAS RID plays in UAS Traffic Management
   (UTM) in
	<xref target="FAACONOPS" format="default"/> (especially Section
	2.6). At the time of writing, CAAs currently (2021) promulgate performance-based
	regulations that do not specify techniques, techniques but rather cite
	industry consensus technical standards as acceptable means of
	compliance.
</t>
<t>
	The most widely cited such industry consensus technical standard
	for UAS RID is <xref target="F3411-19" format="default"/>, which
	defines two means of UAS RID:
</t>

<ul spacing="normal" empty="true"> spacing="normal">
	<li>
		Network RID defines a set of information for UAS to make
		available globally indirectly via the Internet, through servers
		that can be queried by Observers.
	</li>
	<li>
		Broadcast RID defines a set of messages for UA to transmit
		locally directly one-way over Bluetooth or Wi-Fi (without IP or
		any other protocols between the data link and application
		layers), to be received in real time by local Observers.
	</li>
</ul>

<t>
	UAS using both means must send the same UAS RID application layer application-layer
	information via each <xref target="F3411-19" format="default"/>.
	The presentation may differ, as Network RID defines a data
	dictionary, whereas Broadcast RID defines message formats (which
	carry items from that same data dictionary). The interval (or rate)
	at which it is sent may differ, as Network RID can accommodate
	Observer queries asynchronous to UAS updates (which generally need
	be sent only when information, such as location, changes), whereas
	Broadcast RID depends upon Observers receiving UA messages at the
	time they are transmitted.
</t>

<t>
	Network RID depends upon Internet connectivity in several segments
	from the UAS to each Observer.
  Broadcast RID should need Internet
  (or other Wide Area Network) connectivity only to retrieve UAS registry information using the directly locally received UAS
	Identifier (UAS ID)
  information, using, as the primary unique key for database lookup. lookup,
  the UAS
   Identifier (UAS ID) that was directly locally received.
	Broadcast RID does not assume IP connectivity of UAS; messages are
	encapsulated by the UA <em>without IP</em>, directly in link layer link-layer
	frames (Bluetooth 4, Bluetooth 5, Wi-Fi NAN, IEEE 802.11 Beacon, or
	perhaps others in the future perhaps others). future).
</t>

<t anchor="IDtypes">
	<xref target="F3411-19" format="default"/> specifies three UAS ID
	Type values values, and its currently (August 2021) proposed revision (at the time of writing) adds
	a fourth:
</t>

<ol spacing="normal" type="%d" group="type">
	<li>
		A static, manufacturer assigned, manufacturer-assigned, hardware serial number as
		defined in ANSI/CTA-2063-A "Small Unmanned Aerial System Systems Serial
		Numbers" <xref target="CTA2063A" format="default"/>.
	</li>
	<li>
		A CAA assigned CAA-assigned (generally static) ID, like the registration
		number of a manned aircraft.
	</li>
	<li>
		A UTM system assigned UUID UTM-system-assigned Universally Unique Identifier (UUID) <xref target="RFC4122"
		format="default"/>, which can but need not be dynamic.
	</li>
	<li>
		A Specific Session ID, of any of an 8 bit 8-bit range of subtypes
		defined external to ASTM and registered with ICAO, for which
		subtype 1 has been reserved by ASTM for the DRIP entity ID.
	</li>

</ol>

<t>
	Per <xref target="Delegated" format="default"/>, the EU allows only
	UAS
	ID Type 1. Under <xref target="FRUR" format="default"/>, the US
	allows types ID Type 1 and ID Type 3. <xref target="NPRM" format="default"/>
	proposed that a type 3 "Session ID" would be "e.g., a
	randomly-generated alphanumeric code assigned by a Remote ID UAS
	Service Supplier (USS) on a per-flight basis designed to provide
	additional privacy to the operator", but given the omission of
	Network RID from <xref target="FRUR" format="default"/>, how this
	is to be assigned in the US is still to be determined.
</t>
<t>
	As yet apparently yet, there are apparently no CAA public proposals to use UAS ID
	Type 2. In the preamble of <xref target="FRUR" format="default"/>,
	the FAA argues that registration numbers should not be sent in RID,
	insists that the capability of looking up registration numbers from
	information contained in RID should be restricted to FAA and other
	Government agencies, and implies that Session ID would be linked to
	the registration number only indirectly via the serial number in
	the registration database. The possibility of cryptographically
	blinding registration numbers, such that they can be revealed under
	specified circumstances, does not appear to be mentioned in
	applicable regulations or external technical standards.
</t>
<t>
	Under
	Per <xref target="Delegated" format="default"/>, the EU also
	requires an operator registration number (an additional identifier
	distinct from the UAS ID) that can be carried in an <xref
	target="F3411-19" format="default"/> optional Operator ID message. Message.
</t>

<t>
	<xref target="FRUR" format="default"/> allows RID requirements to
	be met by either by the UA itself, which is then designated a
	"standard remote identification unmanned aircraft", or by an add-on
	"remote identification broadcast module". Relative to a standard
	RID UA, the different

  The requirements for a module are that the
	latter: must different than for a standard RID UA. The
  module:
</t>

<ul>
  <li>must transmit its own serial number (neither the serial number of the UA
  to which it is attached, nor a Session ID); must ID),</li>
  <li>must transmit takeoff location as a proxy for the location of the
	pilot/GCS; need
  pilot/GCS,</li>
  <li>need not transmit UA emergency status; and is status, and</li>
  <li>is allowed to be used only for operations within VLOS of the remote pilot.
</t> Remote
  Pilot.</li>
</ul>

<t>
	Jurisdictions may relax or waive RID requirements for certain
	operators and/or under certain conditions. For example, <xref
	target="FRUR" format="default"/> allows operators with UAS not
	equipped for RID to conduct VLOS operations at counter-intuitively counterintuitively
	named "FAA-recognized identification areas" (FRIA); radio
	controlled "FAA-Recognized Identification Areas (FRIAs)"; radio-controlled model aircraft flying clubs and other eligible
	organizations can apply to the FAA for such recognition of their
	operating areas.
</t>
<section numbered="true" toc="default"> <name>Network RID</name>
<figure anchor="NetRID">
<name>"Network RID Information Flow"</name>
<artwork type="ascii-art">

+-------------+     ******************
|     UA      |     *    Internet    *
+--o-------o--+     *                *
   |       |        *                *
   |       |        *                *     +------------+
   |       '--------*--(+)-----------*-----o            |
   |                *   |            *     |            |
   |       .--------*--(+)-----------*-----o NET-Rid SP |
   |       |        *                *     |            |
   |       |        *         .------*-----o            |
   |       |        *         |      *     +------------+
   |       |        *         |      *
   |       |        *         |      *     +------------+
   |       |        *         '------*-----o            |
   |       |        *                *     | NET-Rid DP |
   |       |        *         .------*-----o            |
   |       |        *         |      *     +------------+
   |       |        *         |      *
   |       |        *         |      *     +------------+
+--o-------o--+     *         '------*-----o Observer's |
|     GCS     |     *                *     | Device     |
+-------------+     ******************     +------------+

</artwork>
</figure>

<t>
  <xref target="NetRID" format="default"/> illustrates Network RID
	information flows. Only two of the three typically wireless links
	shown involving the UAS (UA-GCS, UA-Internet, and GCS-Internet)
	need exist to support C2 and Network RID. All three may exist, at
	the same or different times, especially in BVLOS operations. There
	must be some at least one information flow path (direct or indirect) between the
	GCS and the UA, for the former to exercise C2 over the latter. If
	this path is two-way (as increasingly it is, even for inexpensive small
	UAS), the UA will also send its status (and position, if
	suitably equipped, e.g., with GNSS) to the GCS. There also must be
	some
	a path between at least one subsystem of the UAS (UA or GCS) and
	the Internet, for the former to send status and position updates to
	its USS (serving <em>inter alia</em> inter alia as a Net-RID SP).
</t>

<figure anchor="NetRID">
<name>Network RID Information Flow</name>
<artwork type="ascii-art">
+-------------+     ******************
|     UA      |     *    Internet    *
+--o-------o--+     *                *
   |       |        *                *
   |       |        *                *     +------------+
   |       '--------*--(+)-----------*-----o            |
   |                *   |            *     |            |
   |       .--------*--(+)-----------*-----o Net-RID SP |
   |       |        *                *     |            |
   |       |        *         .------*-----o            |
   |       |        *         |      *     +------------+
   |       |        *         |      *
   |       |        *         |      *     +------------+
   |       |        *         '------*-----o            |
   |       |        *                *     | Net-RID DP |
   |       |        *         .------*-----o            |
   |       |        *         |      *     +------------+
   |       |        *         |      *
   |       |        *         |      *     +------------+
+--o-------o--+     *         '------*-----o Observer's |
|     GCS     |     *                *     | Device     |
+-------------+     ******************     +------------+
</artwork>
</figure>

<t>
	Direct UA-Internet wireless links are expected to become more
	common, especially on larger UAS, but currently (2021) but, at the time of writing, they are rare.
	Instead, the RID data flow typically originates on the UA and
	passes through the GCS, or it originates on the GCS. Network RID data
	makes three trips through the Internet (GCS-SP, SP-DP, DP-Observer,
	unless any of them are colocated), implying use of IP (and other
	middle layer
	middle-layer protocols, e.g., TLS/TCP or DTLS/UDP) on those trips.
	IP is not necessarily used or supported on the UA-GCS link (if
	indeed that direct link exists, as it typically does now, but in
	BVLOS operations often will not).
</t>
<t>
	Network RID is publish-subscribe-query. In the UTM context:
</t>
<ol spacing="normal" type="1">
	<li>
		The UAS operator pushes an "operational intent" (the current
		term in UTM corresponding to a flight plan in manned aviation)
		to the USS (call it USS#1) that will serve that UAS (call it
		UAS#1) for that operation, primarily to enable deconfliction
		with other operations potentially impinging upon that
		operation's 4-D airspace volume (call it Volume#1).
	</li>
	<li>
		Assuming the operation is approved and commences, UAS#1
		periodically pushes location/status updates to USS#1, which
		serves <em>inter alia</em> inter alia as the Network RID Service Provider
		(Net-RID SP) for that operation.
	</li>
	<li>
		When users of any other USS (whether they be other UAS
		operators or Observers) develop an interest in any 4-D airspace
		volume (e.g., because they wish to submit an operational intent
		or because they have observed a UA), they query their own USS
		on the volumes in which they are interested.
	</li>

	<li>
		Their USS query, via the UTM
		Discovery and Synchronization
       Service (DSS), all other USS in the UTM system, system and learn of
		any USS that have operations in those volumes (including any
		volumes intersecting them); thus thus, those USS whose query volumes
		intersect Volume#1 (call them USS#2 through USS#n) learn that
		USS#1 has such operations.
	</li>
	<li>
		Interested parties can then subscribe to track updates on that
		operation of UAS#1, via their own USS, which serve as
		Network RID
       Display Providers (Net-RID DP) DPs) for that operation.
	</li>
	<li>
		USS#1 (as Net-RID SP) will then publish updates of UAS#1 status
		and position to all other subscribed USS in USS#2 through USS#n
		(as Net-RID DP).
	</li>

	<li>
		All Net-RID DP subscribed to that operation of UAS#1 will
		deliver its track information to their users who subscribed to
		that operation of UAS#1 (via means unspecified by <xref
		target="F3411-19" format="default"/> format="default"/>, etc., but generally
		presumed to be web browser based).
	</li>
</ol>
<t>
	Network RID has several connectivity scenarios:
</t>
<ul spacing="normal" empty="true"> spacing="normal">

  <li>
		<em>Persistently Internet connected Internet-connected UA</em> can consistently
		directly source RID information; this requires wireless
		coverage throughout the intended operational airspace volume,
		plus a buffer (e.g., winds may drive the UA out of the volume).
	</li>
	<li>
		<em>Intermittently Internet connected Internet-connected UA</em>, can usually
		directly source RID information, but when offline (e.g., due to
		signal blockage by a large structure being inspected using the
		UAS), need the GCS to proxy source RID information.
	</li>

	<li>
		<em>Indirectly connected UA</em> lack the ability to send IP
		packets that will be forwarded into and across the Internet, Internet
		but instead have some other form of communications to another
		node that can relay or proxy RID information to the Internet;
		typically
		typically, this node would be the GCS (which to perform its
		function must know where the UA is, although C2 link outages do
		occur).
	</li>
	<li>
		<em>Non-connected UA</em> have no means of sourcing RID
		information, in which case the GCS or some other interface
		available to the operator must source it. In the extreme case,
		this could be the pilot or other agent of the operator using a
		web browser/application browser or application to designate, to a USS or other UTM
		entity, a time-bounded airspace volume in which an operation
		will be conducted. This is referred to as a "non-equipped
		network participant" engaging in "area operations". This may
		impede disambiguation of ID if multiple UAS operate in the same
		or overlapping 4-D volumes. In most airspace volumes, most
		classes of UA will not be permitted to fly if non-connected.
	</li>
</ul>

<t>
	In most cases in the near term (2021), the Network RID first hop first-hop
	data link is likely to be cellular, which either cellular (which can also support BVLOS C2
	over existing large coverage areas, areas) or Wi-Fi, which Wi-Fi (which can also
	support Broadcast RID. RID). However, provided the data link can support
	at least UDP/IP and ideally also TCP/IP, its type is generally
	immaterial to higher layer higher-layer protocols. The UAS, as the ultimate
	source of Network RID information, feeds a Net-RID SP (typically
	the USS to which the UAS operator subscribes), which proxies for
	the UAS and other data sources. An Observer or other ultimate
	consumer of Network RID information obtains it from a Net-RID DP
	(also typically a USS), which aggregates information from multiple
	Net-RID SPs to offer airspace Situational Awareness (SA) coverage
	of a volume of interest. Network RID Service and Display providers Providers
	are expected to be implemented as servers in well-connected
	infrastructure, communicating with each other via the Internet, Internet and
	accessible by Observers via means such as web Application
	Programming Interfaces (APIs) and browsers.
</t>
<t>
	Network RID is the less constrained of the defined means of UAS RID means. RID.
	<xref target="F3411-19" format="default"/> specifies only specifies information exchanges from Net-RID
	SP to Net-RID DP information exchanges. DP. It is presumed that IETF
	efforts supporting the more constrained Broadcast RID (see next
	section) can be generalized for Network RID and potentially also
	for UAS to USS UAS-to-USS or other UTM communications.
</t>
</section>
<section anchor="broadcast-rid" numbered="true" toc="default"> <name>Broadcast RID</name>
<figure anchor="B-RID">
<name>"Broadcast RID Information Flow"</name>
<artwork type="ascii-art">

         +-------------------+
         | Unmanned Aircraft |
         +---------o---------+
                   |
                   |
                   |
                   | app messages directly over one-way RF data link
                   |
                   |
                   v
+------------------o-------------------+
| Observer's device (e.g., smartphone) |
+--------------------------------------+

</artwork>
</figure>

<t>
	<xref target="B-RID" format="default"/> illustrates the Broadcast RID
	information flow. Note the absence of the Internet from the figure.
	This is because Broadcast RID is one-way direct transmission of
	application layer
	application-layer messages over a an RF data link (without IP) from
	the UA to local Observer devices. Internet connectivity is involved
	only in what the Observer chooses to do with the information
	received, such as verify signatures using a web-based Broadcast
	Authentication Verifier Service and look up information in
	registries using the UAS ID as the primary unique key.
</t>

<figure anchor="B-RID">
<name>Broadcast RID Information Flow</name>
<artwork type="ascii-art">
         +-------------------+
         | Unmanned Aircraft |
         +---------o---------+
                   |
                   |
                   |
                   | app messages directly over one-way RF data link
                   |
                   |
                   v
+------------------o-------------------+
| Observer's device (e.g., smartphone) |
+--------------------------------------+
</artwork>
</figure>
<t>
	Broadcast RID is conceptually similar to
	Automatic Dependent
   Surveillance - Broadcast (ADS-B). However, for various technical
	and other reasons, regulators including the EASA have not indicated
	intent to allow, and FAA has explicitly prohibited, use of ADS-B
	for UAS RID.
</t>

<t>
	<xref target="F3411-19" format="default"/> specifies four Broadcast
	RID data links: Bluetooth 4.x, Bluetooth 5.x with Extended
	Advertisements and Long Range Long-Range Coded PHY (S=8), Wi-Fi NAN at 2.4
	GHz, and Wi-Fi NAN at 5 GHz. A UA must broadcast (using
	advertisement mechanisms where no other option supports broadcast)
	on at least one of these. If sending on Bluetooth 5.x, it is also
	required concurrently to do so concurrently on 4.x (referred to in <xref
	target="F3411-19" format="default"/> as Bluetooth Legacy); "Bluetooth Legacy"); current
	(2021) discussions in ASTM F38.02 on revising the standard, <xref target="F3411-19" format="default"/>,
	motivated by drafts of European standards drafts, standards, suggest that both Bluetooth
	versions will be required. If broadcasting Wi-Fi NAN at 5 GHz, it
	is also required concurrently to do so concurrently at 2.4 GHz; current
	discussions in ASTM F38.02 include relaxing this. Wi-Fi Beacons are also
	under consideration. Future revisions of <xref target="F3411-19"
	format="default"/> may allow other data links.
</t>
<t>
	The selection of the Broadcast RID media was driven by research into
	what is commonly available on 'ground' "ground" units (smartphones and
	tablets) and what was found as prevalent or 'affordable' "affordable" in UA.
	Further, there must be an API for the Observer's receiving
	application to have access to these messages. As yet yet, only Bluetooth
	4.x support is readily available, thus available; thus, the current focus is on
	working within the 31 byte 31-byte payload limit of the Bluetooth 4.x
	"Broadcast Frame" transmitted as an "advertisement" on beacon
	channels. After overheads, this limits the RID message to 25 bytes
	and the UAS ID string to a maximum length of 20 bytes.
</t>

<t>
	Length constraints also preclude a
  A single Bluetooth 4.x advertisement frame
	carrying not only the can just barely fit any UAS ID long enough to
be sufficiently unique for its purpose.</t>

  <t>
   There is related information, which especially includes, but also position, is not limited to,
   the UA position and velocity, which must be represented by data
   elements long enough to provide precision sufficient for their
   purpose while remaining unambiguous with respect to their reference
  frame.</t>
  <t>
   In order to enable Observer devices to verify that 1) the claimed UAS ID is indeed owned by the sender
and other 2) the related information was indeed sent by the owner of that should same UAS ID, authentication data elements
would typically be bound lengthy with conventional cryptographic signature schemes.  They would be
too long to fit in a single frame, even with the latest schemes currently being standardized.</t>

<t>
Thus, it is infeasible to bundle information related to the UAS ID, much less strong ID and corresponding
authentication data. data elements in a single Bluetooth 4.x frame; yet, somehow all these must
be securely bound together.</t>

<t>
  Messages that cannot be encapsulated in a
   single frame (thus far, only the Authentication Message) must be segmented
   into message "pages" (in the terminology of <xref target="F3411-19"
   format="default"/>). Message pages must somehow be correlated as belonging
   to the same message. Messages carrying position, velocity and other data
   must somehow be correlated with the Basic ID message Message that carries the UAS
   ID.
   This correlation is expected to be done on the basis of MAC address: this Media Access
   Control (MAC) address. This may be complicated by MAC address randomization; not
   randomization. Not all the common devices expected to be used by Observers
   have APIs that make sender MAC addresses available to user space receiver applications; and
   applications. MAC addresses are easily spoofed.
   Data elements are not
   so detached on other media (see Message Pack in the paragraph after next).
</t>

<t>
	<xref target="F3411-19" format="default"/> Broadcast RID specifies
	several message types. types (see Section 5.4.5 and Table 3 of <xref
	target="F3411-19" format="default"/>). The 4 bit table below lists
	these message type types. The 4-bit Message Type field in the header can
	index up to 16 types. Only 7 seven are currently defined. defined at the time of writing. Only 2 two are
	mandatory. All others are optional, unless required by a
	jurisdictional authority, e.g., a CAA. To satisfy both EASA and FAA
	rules, all types are needed, except Self-ID and Authentication, as the
	data elements required by the rules are scattered across several
	message types (along with some data elements not required by the
	rules).
</t>
<t>
	The Message Pack (type 0xF) is not actually a message, message but the
	framed concatenation of at most one message of each type of any
	subset of the other types, in type index order. Some of the
	messages that it can encapsulate are mandatory, mandatory; others are optional.
	The Message Pack itself is mandatory on data links that can
	encapsulate it in a single frame (Bluetooth 5.x and Wi-Fi).
</t>

<table anchor="MsgTypes">
	<name>F3411-19 Message Types</name>
	<name>Message Types Defined in <xref target="F3411-19" format="default"/></name>
	<thead>
		<tr><td>Index</td><td>Name</td><td>Req</td><td>Notes</td></tr>
	</thead>
	<tbody>
		<tr><td>0x0</td><td>Basic ID</td><td>Mandatory</td>
			<td>-</td></tr>
		<tr><td>0x1</td><td>Location/Vector</td><td>Mandatory</td>
			<td>-</td></tr>
		<tr><td>0x2</td><td>Authentication</td><td>Optional</td>
			<td>paged</td></tr>
		<tr><td>0x3</td><td>Self-ID</td><td>Optional</td>
			<td>free text</td></tr>
		<tr><td>0x4</td><td>System</td><td>Optional</td>
			<td>-</td></tr>
		<tr><td>0x5</td><td>Operator</td><td>Optional</td>
		<tr><td>0x5</td><td>Operator ID</td><td>Optional</td>
			<td>-</td></tr>
		<tr><td>0xF</td><td>Message Pack</td><td>-</td>
			<td>BT5 and Wi-Fi</td></tr>
	</tbody>
	<tfoot>
		<tr><td>See Section 5.4.5 and Table 3 of <xref
		target="F3411-19" format="default"/></td>
		<td>-</td><td>-</td><td>-</td></tr>
	</tfoot>

</table>
<t>
	<xref target="F3411-19" format="default"/> Broadcast RID specifies
	very few quantitative performance requirements: static information
	must be transmitted at least once per 3 seconds; three seconds, and dynamic
	information (the Location/Vector message) Message) must be transmitted at
	least once per second and be no older than one second when sent.
	<xref target="FRUR" format="default"/> requires all information be
	sent at least once per second.
</t>
<t>
	<xref target="F3411-19" format="default"/> Broadcast RID transmits
	all information as cleartext (ASCII or binary), so static IDs
	enable trivial correlation of patterns of use, which is unacceptable in many
	applications, e.g., package delivery routes of competitors.
</t>

<t>
	Any UA can assert any ID using the <xref target="F3411-19" format="default"/> required Basic ID message, Message, which lacks any
	provisions for verification. The Position/Vector message Location/Vector Message likewise
	lacks provisions for verification, verification and does not contain the ID, so it
	must be correlated somehow with a Basic ID message: Message: the developers
	of <xref target="F3411-19" format="default"/> have suggested using
	the MAC addresses on the Broadcast RID data link, but these may be
	randomized by the operating system stack to avoid the adversarial
	correlation problems of static identifiers.
</t>
<t>
	The <xref target="F3411-19" format="default"/> optional
	Authentication Message specifies framing for authentication data, data
	but does not specify any authentication method, and the maximum
	length of the specified framing is too short for conventional
	digital signatures and far too short for conventional certificates
	(e.g., X.509). Fetching certificates via the Internet is not always
	possible (e.g., Observers working in remote areas, such as national
	forests), so devising a scheme whereby certificates can be
	transported over Broadcast RID is necessary. The one-way nature of
	Broadcast RID precludes challenge-response security protocols
	(e.g., Observers sending nonces to UA, to be returned in signed
	messages). Without DRIP extensions to  <xref target="F3411-19"
	format="default"/>, an Observer would be seriously challenged to
	validate the asserted UAS ID or any other information about the UAS
	or its operator looked up therefrom.
</t>

<t>
	In
	At the time of writing, the currently (2021) proposed revision to ASTM of <xref target="F3411-19" format="default"/>, format="default"/> defines a new Authentication Type 5
	has been defined, "Specific ("Specific Authentication Method" (SAM), Method (SAM)")
        to enable
	SDOs other than ASTM to define authentication payload formats. The
	first byte of the payload is the SAM Type, used to demultiplex such
	variant formats. All formats (aside from those for other than private experimental
	use
	use) must be registered with ICAO, which assigns the SAM Type. Any
	authentication message
	Authentication Message payload that is to be sent in exactly the
	same form over all currently specified Broadcast RID media is
	limited by lower layer lower-layer constraints to a total length of 201 bytes.
	For Authentication Type 5, which is expected to be used by DRIP, the SAM
	Type byte consumes the first of these, limiting DRIP authentication
	payload formats to a maximum of 200 bytes.
</t>
</section>
<section numbered="true" toc="default"> <name>USS in UTM and RID</name>
<t>

	UAS RID and UTM are complementary; Network RID is a UTM service.
	The backbone of the UTM system is comprised of multiple USS: one or
	several per jurisdiction; jurisdiction with some being limited to a single jurisdiction, jurisdiction while
	others spanning span multiple jurisdictions. USS also serve as the
	principal
	principal, or perhaps the sole sole, interface for operators and UAS into
	the UTM environment. Each operator subscribes to at least one USS.
	Each UAS is registered by its operator in at least one USS. Each
	operational intent is submitted to one USS; if approved, that UAS
	and operator can commence that operation. During the operation,
	status and location of that UAS must be reported to that USS, which which,
	in turn turn, provides information as needed about that operator, UAS,
	and operation into the UTM system and to Observers via Network RID.
</t>
<t>
	USS provide services not limited to Network RID; indeed, the primary
	USS function is deconfliction of airspace usage by between different UAS and other (e.g., (and their
	operators). It will occasionally deconflict UAS from non-UAS operations, such as
	manned aircraft, aircraft and rocket launch)
	operations.
	launch. Most deconfliction involving a given operation is hoped to be
	completed prior to commencing that operation, and operation; this is called "strategic
	deconfliction". If that fails, "tactical deconfliction" comes into
	play; ABDAA AirBorne DAA (ABDAA) may not involve USS, but GBDAA Ground-Based DAA (GBDAA)
	likely will.  Dynamic
	constraints, formerly called UAS "UAS Volume Restrictions (UVR), (UVRs)", can be
	necessitated by circumstances such as local emergencies, emergencies and extreme weather, etc., specified by
	authorities on the ground, and propagated in UTM.
</t>
<t>
	No role for USS in Broadcast RID is currently specified by
	regulators or by <xref target="F3411-19" format="default"/>. However,
	USS are likely to serve as registries (or perhaps registrars) for
	UAS (and perhaps operators); if so, USS will have a role in all
	forms of RID. Supplemental Data Service Providers (SDSP) (SDSPs) are also
	likely to find roles, not only in UTM as such but also in enhancing
	UAS RID and related services. Whether
   RID services are used
   in concert with USS, SDSP, etc. are involved or not, RID services, narrowly other UTM entities (if and as needed and available).
   Narrowly defined, RID services provide regulator specified
   regulator-specified identification information; more broadly defined,
   RID services may leverage identification to facilitate related
   services or functions, likely beginning with V2X.
</t>

</section>
<section numbered="true" toc="default"> <name>DRIP Focus</name>

<t>
	In addition to the gaps described above, there is a fundamental gap
	in almost all current or proposed regulations and technical
	standards for UAS RID. As noted above, ID is not an end in itself,
	but a means. Protocols specified in <xref target="F3411-19"
	format="default"/> etc. provide limited information potentially
	enabling, and
	enabling (but no technical means for, for) an Observer to communicate
	with the pilot, e.g., to request further information on the UAS
	operation or exit from an airspace volume in an emergency. The
	System Message provides the location of the pilot/GCS, so an
	Observer could physically go to the asserted location to look for
	the remote pilot; Remote Pilot; this is slow, at best slow best, and may not be feasible.
	What if the pilot is on the opposite rim of a canyon, or there are
	multiple UAS operators to contact, contact whose GCS all lie in different
	directions from the Observer? An Observer with Internet
	connectivity and access privileges could look up operator PII in a
	registry,
	registry and then call a phone number in hopes that someone who can
	immediately influence the UAS operation will answer promptly during
	that operation; this is unreliable, at best unreliable best, and may not be prudent.
	Should pilots be encouraged to answer phone calls while flying?
	Internet technologies can do much better than this.
</t>

<t>
	Thus complementing <xref target="F3411-19" format="default"/> with
	protocols enabling strong authentication, preserving operator
	privacy while enabling immediate use of information by authorized
	parties, is critical
  Thus, to achieve widespread adoption of a RID system supporting safe and secure
  operation of UAS. UAS, protocols must do the following (despite the intrinsic tension among
   these objectives):
</t>
<ul>
  <li>preserve operator privacy,</li>
  <li>enable strong authentication, and</li>
  <li>enable the immediate use of information by authorized parties.</li>
</ul>

<t>
	Just as <xref
	target="F3411-19" format="default"/> is expected to be approved by
	regulators as a basic means of compliance with UAS RID regulations,
	DRIP is expected likewise expected to be approved to address further issues,
	starting with the creation and registration of Session IDs.
</t>
<t>
	DRIP will focus on making information obtained via UAS RID
	immediately usable:
</t>
<ol spacing="normal" type="1">
	<li>
		by making it trustworthy (despite the severe constraints
		of Broadcast RID);
	</li>
	<li>
		by enabling verification that a UAS is registered for RID, and and,
		if so, in which registry (for classification of trusted
		operators on the basis of known registry vetting, even by
		Observers lacking Internet connectivity at observation time);
	</li>
	<li>
		by facilitating independent reports of UA aeronautical data
		(location, velocity, etc.) to confirm or refute the operator
		self-reports upon which UAS RID and UTM tracking are based;
	</li>
	<li>
		by enabling instant establishment, by authorized parties,
		of secure communications with the remote pilot. Remote Pilot.
	</li>
</ol>
<t>
	The foregoing considerations, beyond those addressed by baseline
	UAS RID standards such as <xref target="F3411-19"
	format="default"/>, imply the following requirements for DRIP. DRIP detailed in <xref target="reqs"/>.
</t>
</section>
</section>
<section numbered="true" toc="default"> toc="default" anchor="reqs"> <name>Requirements</name>
<t>
	The following requirements apply to DRIP as a set of related
	protocols, various subsets of which, in conjunction with other IETF
	and external technical standards, may suffice to comply with the
	regulations in any given jurisdiction or meet any given user need.
	It is not intended that each and every DRIP protocol alone of the DRIP set, alone, satisfy
	each and every requirement. To satisfy these requirements, Internet
	connectivity is required some of the time: e.g., time (e.g., to support DRIP
	entity identifier creation/registration;
	Entity Identifier creation/registration) but not all of the time,
	e.g., time
	(e.g., authentication of an asserted DRIP entity identifier Entity Identifier can be
	achieved by a fully working and provisioned Observer device even
	when that device is off-line so is required at all times. times).
</t>
<section numbered="true" toc="default"> toc="default" anchor="gen-req"> <name>General</name>
<section numbered="true" toc="default"> <name>Normative Requirements</name>
<ol spacing="normal" type="GEN-%d" group="gen"> group="gen" indent="9">

  <li>
    Provable Ownership: DRIP MUST <bcp14>MUST</bcp14> enable verification that the
    asserted entity (typically UAS) ID is that of the actual current sender
    (i.e., the entity Entity ID in the DRIP authenticated message set is not a replay
    attack or other spoof, e.g., by
		verifying an asymmetric cryptographic signature using a sender
		provided public key from which the asserted UAS ID can be at
		least partially derived), spoof), even on an Observer device lacking Internet
    connectivity at the time of observation.
	</li>

	<li>
		Provable Binding: DRIP MUST <bcp14>MUST</bcp14> enable the cryptographic binding of
		all other <xref target="F3411-19" format="default"/> messages
		from the same actual current sender to the UAS ID asserted in
		the Basic ID message. Message.
	</li>
	<li>
		Provable Registration: DRIP MUST <bcp14>MUST</bcp14> enable cryptographically
		secure verification that the UAS ID is in a registry and
		identification of that registry, even on an Observer device
		lacking Internet connectivity at the time of observation; the
		same sender may have multiple IDs, potentially in different
		registries, but each ID must clearly indicate in which registry
		it can be found.
	</li>
	<li>
		Readability: DRIP MUST <bcp14>MUST</bcp14> enable information (regulation required
		elements, whether sent via UAS RID or looked up in registries)
		to be read and utilized by both humans and software.
	</li>

	<li>
		Gateway: DRIP MUST <bcp14>MUST</bcp14> enable
		application-layer gateways from Broadcast RID to Network RID
		application layer gateways to stamp messages with precise
		date/time received and receiver location, then relay them to a
		network service (e.g., SDSP or distributed ledger) whenever the
		gateway has Internet connectivity.
	</li>

	<li>
	  Contact: DRIP MUST <bcp14>MUST</bcp14> enable dynamically establishing, with AAA,
           per policy, strongly mutually authenticated, end-to-end
           strongly encrypted communications with the UAS RID sender and
           entities looked up from the UAS ID, including at least the
           (1) pilot (remote pilot (Remote Pilot or Pilot In Command), (2) the USS (if any)
           under which the operation is being conducted, and (3) registries
           in which data on the UA and pilot are held, held. This requirement applies whenever each
           party to such desired communications has a currently usable
           means of resolving the other party's DRIP entity identifier Entity Identifier
           to a locator (IP address) and currently usable bidirectional
           IP (not necessarily Internet) connectivity with the other
           party.
	</li>
	<li>
		QoS: DRIP MUST <bcp14>MUST</bcp14> enable policy based policy-based specification of performance
		and reliability parameters.
	</li>
	<li>
		Mobility: DRIP MUST <bcp14>MUST</bcp14> support physical and logical mobility of
		UA, GCS GCS, and Observers. DRIP SHOULD <bcp14>SHOULD</bcp14> support mobility of
		essentially all participating nodes (UA, GCS, Observers,
		Net-RID SP, Net-RID DP, Private Registry, Registries, SDSP, and potentially
		others as RID and UTM evolve).
	</li>
	<li>
		Multihoming: DRIP MUST <bcp14>MUST</bcp14> support multihoming of UA and GCS, for
		make-before-break smooth handoff and resiliency against
		path/link
		path or link failure. DRIP SHOULD <bcp14>SHOULD</bcp14> support multihoming of
		essentially all participating nodes.
	</li>
	<li>
		Multicast: DRIP SHOULD <bcp14>SHOULD</bcp14> support multicast for efficient
		and flexible publish-subscribe notifications, e.g., of UAS
		reporting positions in designated airspace volumes.
	</li>
	<li>
		Management: DRIP SHOULD <bcp14>SHOULD</bcp14> support monitoring of the health
		and coverage of Broadcast and Network RID services.
	</li>
</ol>
</section>
<section numbered="true" toc="default"> <name>Rationale</name>

<t>
	Requirements imposed either by regulation or by <xref
	target="F3411-19" format="default"/> are not reiterated here, in this document, but they
	drive many of the numbered requirements listed here. The regulatory performance requirement in <xref
	target="FRUR" format="default"/> regulatory QoS requirement
	currently would be satisfied by ensuring information refresh rates
	of at least 1 Hertz, with latencies no greater than 1 second, at
	least 80% of the time, but these numbers may vary between
	jurisdictions and over time. So instead Instead, the DRIP QoS requirement is
	that performance, reliability, etc. parameters such as performance and reliability be specifiable by user policy
	specifiable, policy,
	which does not imply satisfiable in all cases, cases but
	does imply (especially together with the management Management requirement) implies that
	when specifications are not met, appropriate parties are notified.
</t>

<t>
	The "provable ownership" Provable Ownership requirement addresses the possibility that the
	actual sender is not the claimed sender (i.e., is a spoofer).  DRIP
	could meet this requirement by, for example, verifying an asymmetric
	cryptographic signature using a sender-provided public key from which
	the asserted UAS ID can be at least partially derived.  The "provable binding" Provable
	Binding requirement addresses the problem with MAC address correlation problem of
	<xref target="F3411-19" format="default"/> noted above. in <xref
	target="broadcast-rid" format="default"/>. The "provable registration" Provable Registration
	requirement may impose burdens not only on the UAS sender and the
	Observer's receiver, but also on the registry; yet yet, it cannot depend
	upon the Observer being able to contact the registry at the time of
	observing the UA.  The
	"readability" Readability requirement pertains to the
	structure and format of information at endpoints rather than its
	encoding in transit, so it may involve machine assisted machine-assisted format conversions, e.g.,
	conversions (e.g., from binary
	encodings, encodings) and/or decryption (see <xref
	target="priv" format="default"/>).
</t>
<t>
	The "gateway" Gateway requirement is in pursuit of three objectives: (1)
	mark up a RID message with where and when it was actually received,
	which may agree or disagree with the self-report in the set of
	messages; (2) defend against replay attacks; and (3) support
	optional SDSP services such as multilateration, to complement UAS
	position self-reports with independent measurements. This is the
	only instance in which DRIP transports <xref target="F3411-19" format="default"/> messages; most of DRIP pertains to the
	authentication of such messages and identifiers carried in them.
</t>
<t>
	The "contact" Contact requirement allows any party that learns a UAS ID
	(that is a DRIP entity identifier Entity Identifier rather than another UAS ID Type)
	to request establishment of a communications session with the
	corresponding UAS RID sender and certain entities associated with
	that UAS, but AAA and policy restrictions, <em>inter alia</em> inter alia on
	resolving the identifier to any locators (typically IP addresses),
	should prevent unauthorized parties from distracting or harassing
	pilots. Thus Thus, some but not all Observers of UA, receivers of
	Broadcast RID, clients of Network RID, and other parties can
	become successfully initiating endpoints for these sessions.
</t>
<t>
	The "QoS" QoS requirement is only that performance and reliability
	parameters can be <em>specified</em> by policy, not that any such
	specifications must be guaranteed to be met; any failure to meet
	such would be reported under the "management" Management requirement. Examples
	of such parameters are the maximum time interval at which messages
	carrying required data elements may be transmitted, the maximum
	tolerable rate of loss of such messages, and the maximum tolerable
	latency between a dynamic data element (e.g., GNSS position of UA)
	being provided to the DRIP sender and that element being delivered
	by the DRIP receiver to an application.
</t>
<t>
	The "mobility" Mobility requirement refers to rapid geographic mobility of
	nodes, changes of their points of attachment to networks, and
	changes to their IP addresses; it is not limited to micro-mobility
	within a small geographic area or single Internet access provider.
</t>
</section>
</section>
<section numbered="true" toc="default"> toc="default" anchor="id-req"> <name> Identifier</name>
<section numbered="true" toc="default"> <name>Normative Requirements</name>
<ol spacing="normal" type="ID-%d" group="id"> group="id" indent="9">
	<li>
		Length: The DRIP entity identifier MUST NOT Entity Identifier <bcp14>MUST NOT</bcp14> be longer than 19
		bytes, to fit in the Specific Session ID subfield of the UAS ID
		field of the Basic ID message Message of the currently (August 2021)
		proposed revision of <xref target="F3411-19"
		format="default"/>.
		format="default"/> (at the time of writing).
	</li>

	<li>
		Registry ID: The DRIP identifier MUST <bcp14>MUST</bcp14> be sufficient to identify
		a registry in which the entity identified therewith is listed.
	</li>
	<li>
		Entity ID: The DRIP identifier MUST <bcp14>MUST</bcp14> be sufficient to enable
		lookups of other data associated with the entity identified
		therewith in that registry.
	</li>
	<li>
		Uniqueness: The DRIP identifier MUST <bcp14>MUST</bcp14> be unique within the
		applicable global identifier space from when it is first
		registered therein until it is explicitly de-registered deregistered
		therefrom (due to, e.g., expiration after a specified lifetime,
		revocation by the registry, or surrender by the operator).
	</li>
	<li>
		Non-spoofability: The DRIP identifier MUST NOT <bcp14>MUST NOT</bcp14> be spoofable
		within the context of a minimal Remote ID broadcast message set
		(to be specified within DRIP to be sufficient collectively to
		prove sender ownership of the claimed identifier).
	</li>
	<li>
		Unlinkability: The DRIP identifier MUST NOT <bcp14>MUST NOT</bcp14> facilitate
		adversarial correlation over multiple operations. If this is
		accomplished by limiting each identifier to a single use or
		brief period of usage, the DRIP identifier MUST <bcp14>MUST</bcp14> support
		well-defined, scalable, timely registration methods.
	</li>
</ol>
</section>
<section numbered="true" toc="default"> <name>Rationale</name>
<t>
	The DRIP identifier can refer to various entities. In the primary
	initial use case, the entity to be identified is the UA. Entities to
	be identified in other likely use cases include include, but are not limited to to,
	the operator, USS, and Observer. In all cases, the entity identified
	must own (have the identifier (i.e., have the exclusive capability to use, use
	the identifier, such that receivers can verify its ownership of) the identifier. entity's ownership
	of it).
</t>
<t>
	The DRIP identifier can be used at various layers. In Broadcast RID,
	it would be used by the application running directly over the data
	link. In Network RID, it would be used by the application running over
	HTTPS (not required by DRIP but generally used by Network RID
	implementations) and possibly other protocols. In RID
	initiated RID-initiated V2X
	applications such as DAA and C2, it could be used between the network
	and transport layers, e.g., layers (e.g., with the Host Identity Protocol (HIP, (HIP)
	<xref target="RFC9063" format="default"/>, format="default"/> <xref target="RFC7401" format="default"/>, etc.),
	format="default"/>) or between the transport and application layers, e.g.,
	layers (e.g., with Datagram Transport
	Layer Security (DTLS, DTLS <xref
	target="RFC6347" format="default"/>).
</t>
<t>
	Registry ID (which registry the entity is in) and Entity ID (which
	entity it is, within that registry) are requirements on a single
	DRIP entity identifier, Entity Identifier, not separate (types of) ID. In the most
	common use case, the entity will be the UA, and the DRIP identifier
	will be the UAS ID; however, other entities may also benefit from
	having DRIP identifiers, so the entity type is not prescribed here.
</t>

<t>
	Whether a UAS ID is generated by the operator, GCS, UA, USS,
	registry, or some collaboration thereamong, among them is unspecified;
	however, there must be agreement on the UAS ID among these
	entities. Management of DRIP identifiers is the primary function of
	their registration hierarchies, from the root (presumably IANA),
	through sector-specific and regional authorities (presumably ICAO
	and CAAs), to the identified entities themselves.
</t>
<t>
	While "uniqueness" Uniqueness might be considered an implicit requirement for
	any identifier, here the point of the explicit requirement is not
	just that it should be unique, but also where and when it should be
	unique: global scope within a specified space, from registration to
	deregistration.
</t>
<t>
	While "non-spoofability" Non-spoofability imposes requirements for and on a DRIP
	authentication protocol, it also imposes requirements on the
	properties of the identifier itself. An example of how the nature
	of the identifier can support non-spoofability is embedding a hash
	of both the registry Registry ID and a public key of the entity in the
	entity identifier, thus making it self-authenticating any time the
	entity's corresponding private key is used to sign a message.
</t>
<t>
	While "unlinkability" Unlinkability is a privacy desideratum (see next section), <xref target="priv"/>),
	it imposes requirements on the DRIP identifier itself, as distinct
	from other currently permitted choices for the UAS ID (including
	primarily the static serial number of the UA or RID module).
</t>
</section>
</section>
<section anchor="priv" numbered="true" toc="default"> <name>Privacy</name>
<section numbered="true" toc="default"> <name>Normative Requirements</name>
<ol spacing="normal" type="PRIV-%d" group="priv"> group="priv" indent="9">
	<li>
		Confidential Handling: DRIP MUST <bcp14>MUST</bcp14> enable confidential
		handling of private information (i.e., any and all
            information
		designated by that neither the cognizant authority nor
            the information owner has designated as public, e.g., personal data).
	</li>
	<li>
		Encrypted Transport: DRIP MUST <bcp14>MUST</bcp14> enable selective strong
		encryption of private data in motion in such a manner that only
		authorized actors can recover it. If transport is via IP, then
		encryption MUST <bcp14>MUST</bcp14> be end-to-end, at or above the IP layer. DRIP
		MUST NOT
		<bcp14>MUST NOT</bcp14> encrypt safety critical data to be transmitted over
		Broadcast RID in any situation where it is unlikely that local
		Observers authorized to access the plaintext will be able to
		decrypt it or obtain it from a service able to decrypt it. DRIP
		MUST NOT
		<bcp14>MUST NOT</bcp14> encrypt data when/where doing so would conflict with
		applicable regulations or CAA policies/procedures, i.e., DRIP
		MUST
		<bcp14>MUST</bcp14> support configurable disabling of encryption.
	</li>
	<li>
		Encrypted Storage: DRIP SHOULD <bcp14>SHOULD</bcp14> facilitate selective strong
		encryption of private data at rest in such a manner that only
		authorized actors can recover it.
	</li>
	<li>
		Public/Private Designation: DRIP SHOULD <bcp14>SHOULD</bcp14> facilitate designation,
		by cognizant authorities and information owners, of which
		information is public and which is private. By default, all
		information required to be transmitted via Broadcast RID, even
		when actually sent via Network RID or stored in registries, is
		assumed to be public; all other information held in registries
		for lookup using the UAS ID is assumed to be private.
	</li>

	<li>
		Pseudonymous Rendezvous: DRIP MAY <bcp14>MAY</bcp14> enable mutual discovery of
		and communications among participating UAS operators whose UA
		are in 4-D proximity, using the UAS ID without revealing
		pilot/operator identity or physical location.
	</li>
</ol>
</section>
<section numbered="true" toc="default"> <name>Rationale</name>
<t>
	Most data to be sent via Broadcast RID or Network RID is public,
	thus public;
	thus, the "encrypted transport" Encrypted Transport requirement for private data is
	selective, e.g., for the entire payload of the Operator ID Message,
	but only the pilot/GCS location fields of the System Message.
	Safety critical data includes at least the UA location. Other data
	also may be deemed safety critical, e.g., in some jurisdictions the
	pilot/GCS location is implied to be safety critical.
</t>
<t>
	UAS have several potential means of assessing the likelihood that
	local Observers authorized to access the plaintext will be able to
	decrypt it or obtain it from a service able to decrypt it. If the
	UAS is not participating in UTM, an Observer would have no means of
	obtaining a decryption key or decryption services from a cognizant
	USS. If the UAS is participating in UTM, UTM but has lost connectivity
	with its USS, then an Observer within visual LOS of the UA is also
	unlikely to be able to communicate with that USS (whether due to
	the USS being offline or the UAS and Observer being in an area with
	poor Internet connectivity). Either of these conditions (UTM
	non-participation or USS unreachability) would be known to the UAS.
</t>

<t>
	In some jurisdictions, the configurable enabling and disabling of
	encryption may need to be outside the control of the operator.
	<xref target="FRUR" format="default"/> mandates that manufacturers
	design RID equipment with some degree of tamper resistance; the
	preamble of <xref target="FRUR" format="default"/> and other FAA commentary suggest this is to reduce the
	likelihood that an operator, intentionally or unintentionally,
	might alter the values of the required data elements or	disable
	their transmission in the required manner (e.g., as cleartext).
</t>
<t>
	How information is stored on end systems is out of scope for DRIP.
	Encouraging privacy best practices, including end system storage
	encryption, by facilitating it with protocol design reflecting such
	considerations,
	considerations is in scope. Similar logic applies to methods for
	designating information as public or private.
</t>
<t>
	The privacy Privacy requirements above are for DRIP, neither for <xref
	target="F3411-19" format="default"/> (which (which, in the interest of
	privacy, requires obfuscation of location to any Network RID
	subscriber engaging in wide area surveillance, limits data retention
	periods, etc., in the interests
	of privacy), etc.), nor for UAS RID in any specific jurisdiction (which may
	have its own regulatory requirements). The requirements above are also
	in a sense parameterized: who are the "authorized actors", how are
	they designated, how are they authenticated, etc.?
</t>
</section>
</section>
<section numbered="true" toc="default"> <name>Registries</name>
<section numbered="true" toc="default"> <name>Normative Requirements</name>
<ol spacing="normal" type="REG-%d" group="reg"> group="reg" indent="9">
	<li>
		Public Lookup: DRIP MUST <bcp14>MUST</bcp14> enable lookup, from the UAS ID, of
		information designated by cognizant authority as public, public and
		MUST NOT
		<bcp14>MUST NOT</bcp14> restrict access to this information based on identity
		or role of the party submitting the query.
	</li>
	<li>
		Private Lookup: DRIP MUST <bcp14>MUST</bcp14> enable lookup of private information
		(i.e., any and all information in a registry, associated with
		the UAS ID, that is designated by neither cognizant authority
		nor the information owner as public), and MUST, <bcp14>MUST</bcp14>, according to
		applicable policy, enforce AAA, including restriction of access
		to this information based on identity or role of the party
		submitting the query.
	</li>
	<li>
		Provisioning: DRIP MUST <bcp14>MUST</bcp14> enable provisioning registries with
		static information on the UAS and its operator, dynamic
		information on its current operation within the U-space/UTM
		(including means by which the USS under which the UAS is
		operating may be contacted for further, typically even more
		dynamic, information), and Internet direct contact information
		for services related to the foregoing.
	</li>
	<li>
		AAA Policy: DRIP AAA MUST <bcp14>MUST</bcp14> be specifiable by policies; the
		definitive copies of those policies must be accessible in
		registries; administration of those policies and all DRIP
		registries must be protected by AAA.
	</li>
</ol>
</section>
<section numbered="true" toc="default"> <name>Rationale</name>

<t>
	Registries are fundamental to RID. Only very limited information can
	be Broadcast, transmitted via Broadcast RID, but extended information is sometimes needed. The most
	essential element of information sent is the UAS ID itself, the unique
	key for lookup of extended information in registries.
	Beyond
The regulatory requirements for the registry information models for UAS and
their operators for RID and, more broadly, for U-space/UTM needs are in flux.
Thus, beyond designating the UAS ID as that unique key, the registry information
model is not specified herein, in part because
	regulatory requirements for different registries (UAS operators and
	their UA, each narrowly for UAS RID and broadly for U-space/UTM)
	and business models for meeting those requirements are in flux. this document.
	While it is expected that
	registry functions will be integrated with USS, who will provide them
	is expected to vary between jurisdictions and has not yet been determined in most, and
	is expected to vary between,
	most jurisdictions. However this evolves, the essential registry
	functions, starting with management of identifiers, are expected to
	remain the same, so those are specified herein.
</t>
<t>
	While most data to be sent via Broadcast or Network RID is public,
	much of the extended information in registries will be private.
	Thus
	Thus, AAA for registries is essential, not just to ensure that
	access is granted only to strongly authenticated, duly authorized
	parties, but also to support subsequent attribution of any leaks,
	audit of who accessed information when and for what purpose, etc.
	As specific
	Specific AAA requirements will vary by jurisdictional
	regulation, provider philosophy, customer demand, etc., so they are
	left to specification in policies, which policies. Such policies should be human readable
	to facilitate analysis and discussion, and be machine readable to
	enable automated enforcement, using and use a language amenable to both,
	e.g., XACML. eXtensible Access Control Markup Language (XACML).
</t>
<t>
	The intent of the negative and positive access control requirements
	on registries is to ensure that no member of the public would be
	hindered from accessing public information, while only duly
	authorized parties would be enabled to access private information.
	Mitigation of Denial of Service denial-of-service attacks and refusal to allow
	database mass scraping would be based on those behaviors, not on
	identity or role of the party submitting the query <em>per se</em>,
	but querant identity per se;
	 however,
   information on the identity of the party submitting the query might be
   gathered (by on such misbehavior by security systems protecting DRIP implementations) on such misbehavior.
   implementations.
</t>
<t>
	By
	"Internet direct contact information" is meant means a locator (e.g.,
	IP address), or identifier (e.g., FQDN) that can be resolved to a
	locator, which would enable enables initiation of an end-to-end
	communication session using a well known well-known protocol (e.g., SIP).
</t>
</section>
</section>
</section>
<section anchor="IANA" numbered="true" toc="default"> <name>IANA Considerations</name>
<t>
This document does not make any has no IANA request. actions.
</t>
</section>
<section anchor="Security" numbered="true" toc="default"> <name>Security Considerations</name>
<t>
	DRIP is all about safety and security, so content pertaining to
	such is not limited to this section. This document does not define
	any protocols, so security considerations of such are speculative.
	Potential vulnerabilities of DRIP solutions to these requirements
	include but are not limited to:
</t>
	<ul>
		<li>
			Sybil attacks
		</li>
		<li>
			confusion created by many spoofed unsigned messages
		</li>
		<li>
			processing overload induced by attempting to verify many
			spoofed signed messages (where verification will fail but
			still consume cycles)
		</li>
		<li>
			malicious or malfunctioning registries
		</li>
		<li>
			interception by on-path attacker of (i.e., Man In The
			Middle man-in-the-middle attacks on) registration messages
		</li>
		<li>
			UA impersonation through private key extraction, improper
			key sharing, or carriage of a small (presumably harmless)
			UA, i.e., as a "false flag", by a larger (malicious) UA
		</li>
	</ul>
<t>
	It may be inferred from the general General requirements (Section 4.1) (<xref target="gen-req"/>) for
	provable ownership, provable binding,
	Provable Ownership, Provable Binding, and provable registration, Provable Registration,
	together with the identifier Identifier requirements (Section 4.2), (<xref target="id-req"/>), that DRIP
	must provide:
</t>
	<ul>
		<li>
			message integrity
		</li>
		<li>
			non-repudiation
		</li>
		<li>
			defense against replay attacks
		</li>
		<li>
			defense against spoofing
		</li>
	</ul>
<t>
	One approach to so doing involves verifiably binding the DRIP
	identifier to a public key. Providing these security features,
	whether via this approach or another, is likely to be especially
	challenging for Observers without Internet connectivity at the time
	of observation. For example, checking the signature of a registry
	on a public key certificate received via Broadcast RID in a remote
	area presumably would require that the registry’s registry's public key had
	been previously installed on the Observer’s Observer's device, yet there may
	be many registries and the Observer’s Observer's device may be storage
	constrained, and new registries may come on-line subsequent to
	installation of DRIP software on the Observer’s Observer's device. See also
	<xref target="Scenario" format="default"/> and the associated
	explanatory text, especially the second paragraph after the figure.
	Thus
	Thus, there may be caveats on the extent to which requirements can
	be satisfied in such cases, yet strenuous effort should be made to
	satisfy them, as such cases, cases are important, e.g., firefighting in a national
	forest, are important.
	forest. Each numbered requirement <em>a priori</em> a priori
	expected to suffer from such limitations (General requirements for
	Gateway and Contact functionality) contains language stating when
	it applies.
</t>
</section>
<section anchor="Privacy" numbered="true" toc="default">
<name>Privacy and Transparency Considerations</name>
<t>
	Privacy and transparency are important for legal reasons including
	regulatory consistency. <xref target="EU2018" format="default"/>
	states "harmonised
	states:</t>
	<blockquote>
	harmonised and interoperable national registration
	systems...
	systems ... should comply with the applicable Union and national law
	on privacy and processing of personal data, and the information
	stored in those registration systems should be easily accessible.”
</t> accessible.
        </blockquote>
<t>
	Privacy and transparency
	Transparency (where essential to security or safety) and privacy
	are also ethical and moral imperatives. Even in cases where old
	practices (e.g., automobile registration plates) could be imitated,
	when new applications involving PII (such as UAS RID) are addressed
	and newer technologies could enable improving privacy, such
	opportunities should not be squandered. Thus Thus, it is recommended that
	all DRIP work give due regard to <xref target="RFC6973"
	format="default"/> and and, more broadly broadly, to <xref target="RFC8280"
	format="default"/>.
</t>
<t>
	However, privacy and transparency are often conflicting goals,
	demanding careful attention to their balance.
</t>

<t>
DRIP information falls into two classes: that classes:</t>
<ul spacing="normal" empty="false">
  <li>that which, to achieve the
	purpose, must be published openly as cleartext, for the benefit of
	any Observer (e.g., the basic UAS ID itself); and that </li>
   <li>that which must
	be protected (e.g., PII of pilots) but made available to properly
	authorized parties (e.g., public safety personnel who urgently need
   to contact pilots in emergencies).
</t> emergencies).</li>
</ul>
<t>
	How properly authorized parties are authorized, authenticated, etc.
	are questions that extend beyond the scope of DRIP, but DRIP may be
	able to provide support for such processes. Classification of
	information as public or private must be made explicit and
	reflected with markings, design, etc. Classifying the information
	will be addressed primarily in external standards; herein in this document, it will
	be regarded as a matter for CAA, registry, and operator policies,
	for which enforcement mechanisms will be defined within the scope
	of the DRIP WG and offered. Details of the protection mechanisms will
	be provided in other DRIP documents. Mitigation of adversarial
	correlation will also be addressed.
</t>
</section>
</middle>

<back>

<displayreference target="I-D.ietf-drip-arch" to="drip-architecture"/> to="DRIP-ARCH"/>
<displayreference target="I-D.ietf-raw-ldacs" to="LDACS"/>

<references> <name>References</name>

<references> <name>Normative References</name>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

	<reference anchor="F3411-19" target="http://www.astm.org/cgi-bin/resolver.cgi?F3411">
	<front>
		<title>Standard Specification for Remote ID and Tracking</title>
		<author>
			<organization>ASTM International</organization>
		</author>
		<date month="02" year="2020"/>
	</front>
	<seriesInfo name="ASTM" value="F3411-19"/>
	<seriesInfo name="DOI" value="10.1520/F3411-19"/>
	</reference>
</references>

<references> <name>Informative References</name>

	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4122.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4949.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4122.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6973.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4949.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7401.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8280.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6973.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9063.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7401.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-drip-arch.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8280.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-raw-ldacs.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9063.xml"/>

<!-- [I-D.ietf-drip-arch] IESG state I-D Exists  -->

<reference anchor='I-D.ietf-drip-arch'>
<front>
<title>Drone Remote Identification Protocol (DRIP) Architecture</title>
<author initials='S' surname='Card' fullname='Stuart Card'>
<organization />
</author>
<author initials='A' surname='Wiethuechter' fullname='Adam Wiethuechter'>
<organization />
</author>
<author initials='R' surname='Moskowitz' fullname='Robert Moskowitz'>
<organization />
</author>
<author initials='S' surname='Zhao' fullname='Shuai Zhao' role="editor">
<organization />
</author>
<author initials='A' surname='Gurtov' fullname='Andrei Gurtov'>
<organization />
</author>
<date year='2022' month='January' day="28" />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-drip-arch-20'/>
</reference>

<!-- [I-D.ietf-raw-ldacs] IESG state Publication Requested -->

<reference anchor='I-D.ietf-raw-ldacs'>
<front>
<title>L-band Digital Aeronautical Communications System (LDACS)</title>
<author initials='N' surname='Maeurer' fullname='Nils Maeurer' role="editor">
<organization />
</author>
<author initials='T' surname='Graeupl' fullname='Thomas Graeupl' role="editor">
<organization />
</author>
<author initials='C' surname='Schmitt' fullname='Corinna Schmitt' role="editor">
<organization />
</author>
<date year='2021' month='October' day="22" />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-raw-ldacs-09'/>
</reference>

	<reference anchor="Amended" target="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32020R1058"> target="https://eur-lex.europa.eu/eli/reg_del/2020/1058/oj">
	<front>
		<title>Commission Delegated Regulation (EU) 2020/1058 of 27 April 2020 amending Delegated Regulation (EU) 2019/945</title> 2019/945 as regards the introduction of two new unmanned aircraft systems classes</title>
		<author>
			<organization>European Union Aviation Safety Agency (EASA)</organization> Parliament and Council</organization>
		</author>
		<date month="04" year="2020"/>
	</front>
	</reference>

	<reference anchor="ASDRI" target="https://asd-stan.org/wp-content/uploads/ASD-STAN_DRI_Introduction_to_the_European_digital_RID_UAS_Standard.pdf">
	<front>
		<title>Introduction to the European UAS Digital Remote ID Technical Standard</title>
		<author>
			<organization> ASD-STAN </organization>
		</author>
		<date month="01" year="2021"/>
	</front>
	</reference>

	<reference anchor="ASDSTAN4709-002" target="https://asd-stan.org/downloads/asd-stan-pren-4709-002-p1/">
	<front>
		<title>Aerospace series - Unmanned Aircraft Systems - Part 002: Direct Remote Identification</title>
		<author>
			<organization>ASD-STAN</organization>
		</author>
		<date month="10" year="2021"/>
	</front>
	<seriesInfo name="ASD-STAN prEN" value="4709-002 P1"/>
	<refcontent></refcontent>
	</reference>

	<reference anchor="CPDLC"  target="https://www.mdpi.com/1424-8220/18/5/1636">
	<front>
		<title>Controller-Pilot Data Link Communication Security</title>
		<author initials = "A." surname = "Gurtov">  <organization />   </author>
		<author initials = "T." surname = "Polishchuk">  <organization />   </author>
		<author initials = "M." surname = "Wernberg">  <organization />   </author>
		<date month="" year="2018" />
	</front>
	<seriesInfo name="MDPI Sensors" value="18(5), 1636"/> name="DOI" value="10.3390/s18051636"/>
	<refcontent>Sensors 18, no. 5: 1636</refcontent>
	</reference>

	<reference anchor="CTA2063A" target="https://shop.cta.tech/products/small-unmanned-aerial-systems-serial-numbers">
	<front>
		<title>Small Unmanned Aerial Systems Serial Numbers</title>
		<author>
			<organization>ANSI</organization>
		</author>
		<date month="09" year="2019"/>
	</front>
	<seriesInfo name="ANSI/CTA" value="2063-A"/>
	</reference>

	<reference anchor="Delegated" target="https://eur-lex.europa.eu/eli/reg_del/2019/945/oj">

	<front>
		<title>Commission Delegated Regulation (EU) 2019/945 of 12 March 2019 on unmanned aircraft systems and on third-country operators of unmanned aircraft systems</title>
		<author>
			<organization>European Union Aviation Safety Agency (EASA)</organization> Parliament and Council</organization>
		</author>
		<date month="03" year="2019"/>
	</front>
	</reference>

	<reference anchor="ENISACSIRT" target="https://www.enisa.europa.eu/topics/csirt-cert-services/reactive-services/copy_of_actionable-information"> target="https://www.enisa.europa.eu/topics/csirt-cert-services/reactive-services/copy_of_actionable-information/actionable-information">
	<front>
		<title>Actionable information for Security Incident Response</title>
		<author>
			<organization>European Union Agency for Cybersecurity (ENISA)</organization>
		</author>
		<date month="11" year="2014"/>
	</front>
	</reference>

	<reference anchor="EU2018" target="https://www.consilium.europa.eu/media/35805/easa-regulation-june-2018.pdf">
	<front>
		<title>2015/0277 (COD) PE-CONS 2/18</title>
		<author>
			<organization>European Parliament and Council</organization>
		</author>
		<date month="02" month="June" year="2018"/>
	</front>
	</reference>

	<reference anchor="FAACONOPS" target="https://www.faa.gov/uas/research_development/traffic_management/media/UTM_ConOps_v2.pdf">
	<front>
		<title>UTM Concept of Operations v2.0</title>
		<author>
			<organization>FAA Office of NextGen</organization>
		</author>
		<date month="03" year="2020"/>
	</front>
	</reference>

	<reference anchor="FR24" target="https://www.flightradar24.com/about">
	<front>
		<title>Flightradar24 Live Air Traffic</title>
		<title>About Flightradar24</title>
		<author>
			<organization>Flightradar24 AB</organization>
			<organization>Flightradar24</organization>
		</author>
		<date month="05" year="2021"/>
	</front>
	</reference>

	<reference anchor="FRUR" target="https://www.federalregister.gov/documents/2021/01/15/2020-28948/remote-identification-of-unmanned-aircraft">
	<front>
		<title>Remote Identification of Unmanned Aircraft</title>
		<author>
			<organization>Federal Aviation Administration</organization> Administration (FAA)</organization>
		</author>
		<date month="01" year="2021"/>
	</front>
	</reference>

	<reference anchor="GDPR" target="https://eur-lex.europa.eu/eli/reg/2016/679/oj">
	<front>
		<title>General
		<title>Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation</title> Regulation)</title>
		<author>
			<organization>European Parliament and Council</organization>
		</author>
		<date month="04" year="2016"/>
	</front>
	</reference>

	<reference anchor="ICAOATM" target="https://store.icao.int/en/procedures-for-air-navigation-services-air-traffic-management-doc-4444">
	<front>
		<title>Doc 4444: Procedures
		<title>Procedures for Air Navigation Services: Air Traffic Management</title> <author>
			<organization>International Civil Aviation Organization</organization>
		</author>
		<date month="11" year="2016"/>
	</front>
	<seriesInfo name="Doc" value="4444"/>
	</reference>

	<reference anchor="ICAODEFS" target="https://www.icao.int/safety/cargosafety/Documents/Draft%20Glossary%20of%20terms.docx">
	<front>
		<title>Defined terms from the Annexes to the Chicago Convention and ICAO guidance material</title> <author>
			<organization>International Civil Aviation Organization</organization>
		</author>
		<date month="07" year="2017"/>
	</front>
	</reference>

	<reference anchor="ICAOUAS" target="https://www.icao.int/meetings/uas/documents/circular%20328_en.pdf">
	<front>
		<title>Circular 328: Unmanned
		<title>Unmanned Aircraft Systems</title> <author>
			<organization>International Civil Aviation Organization</organization>
		</author>
		<date month="02" year="2011"/>
	</front>
	<seriesInfo name="Circular" value="328"/>
	</reference>

	<reference anchor="ICAOUTM" target="https://www.icao.int/safety/UA/Documents/UTM%20Framework%20Edition%203.pdf">
	<front>
		<title>Unmanned Aircraft Systems Traffic Management (UTM) - A Common Framework with Core Principles for Global Harmonization, Edition 3</title> <author>
			<organization>International Civil Aviation Organization</organization>
		</author>
		<date month="10" year="2020"/>
	</front>
	</reference>

	<reference anchor="Implementing" target="https://eur-lex.europa.eu/eli/reg_impl/2019/947/oj">
	<front>
		<title>Commission Implementing Regulation (EU) 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> Parliament and Council</organization>
		</author>
		<date month="05" year="2019"/>
	</front>
	</reference>

	<reference anchor="InitialView" target="https://www.sesarju.eu/sites/default/files/documents/u-space/SESAR%20principles%20for%20U-space%20architecture.pdf">
	<front>
		<title>Initial view on Principles for the U-space architecture</title>
		<author>
			<organization>SESAR Joint Undertaking</organization>
		</author>
		<date month="07" year="2019"/>
	</front>
	</reference>

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

	<reference anchor="OpenDroneID" target="https://github.com/opendroneid/specs">
	<front>
		<title>Open
		<title>The Open Drone ID</title> ID specification</title>
		<author>
			<organization>Intel Corp.</organization>
			<organization></organization>
		</author>
		<date month="03" year="2019"/> year="2020"/>
	</front>
	<seriesInfo name="commit" value="c4c8bb8"/>
	</reference>

	<reference anchor="OpenSky" target="https://opensky-network.org/about/about-us">
	<front>
		<title>The
		<title>About the OpenSky Network</title>
		<author>
			<organization>OpenSky Network non-profit association</organization> Network</organization>
		</author>
		<date month="05" year="2021"/>
	</front>
	</reference>

	<reference anchor="Opinion1" target="https://www.easa.europa.eu/document-library/opinions/opinion-012020">
	<front>
		<title>Opinion No 01/2020: High-level
		<title>High-level regulatory framework for the U-space</title>
		<author>
			<organization>European Union Aviation Safety Agency (EASA)</organization>
		</author>
		<date month="03" year="2020"/>
	</front>
	<seriesInfo name="Opinion" value="No 01/2020"/>
	</reference>

	<reference anchor="Part107" target="https://www.ecfr.gov/cgi-bin/text-idx?node=pt14.2.107">
	<front>
		<title>Code of Federal Regulations Part 107</title>
		<title>Part 107 - SMALL UNMANNED AIRCRAFT SYSTEMS</title>
		<author>
			<organization>United States
			<organization>Code of Federal Aviation Administration</organization> Regulations</organization>
		</author>
		<date month="06" year="2016"/>
	</front>
	</reference>

	<reference anchor="Recommendations" target="https://www.faa.gov/regulations_policies/rulemaking/committees/documents/media/UAS%20ID%20ARC%20Final%20Report%20with%20Appendices.pdf">
	<front>
		<title>UAS ID Identification and Tracking (UAS ID) Aviation
		Rulemaking Committee (ARC): ARC Recommendations Final Report</title> Report
		</title>
		<author>
			<organization>FAA UAS Identification and Tracking (UAS ID) Aviation Rulemaking Committee</organization> Committee (ARC)</organization>
		</author>
		<date month="09" year="2017"/>
	</front>
	</reference>

	<reference anchor="Roadmap" target="https://share.ansi.org/Shared Documents/Standards Activities/UASSC/UASSC_20-001_WORKING_DRAFT_ANSI_UASSC_Roadmap_v2.pdf">
	<front>
	  <title>Standardization Roadmap for Unmanned Aircraft Systems draft v2.0</title>
	  </title>
		<author>
			<organization>American National Standards Institute (ANSI)
			<organization>ANSI Unmanned Aircraft Systems Standardization Collaborative (UASSC)</organization>
		</author>
		<date month="04" year="2020"/>
	</front>
        <refcontent>Working
Draft, Version 2.0</refcontent>
	</reference>

	<reference anchor="Stranger" target=""> anchor="Stranger">
	<front>
		<title>Stranger in a Strange Land</title>
		<author surname="Heinlein" initials="R.A."> initials="R.">
		</author>
		<date month="06" year="1961"/>
	</front>
	</reference>

	<reference anchor="WG105" target="">
	<front>
		<title>WG-105 draft ED-282 Minimum
		<title>Minimum Operational Performance Standards (MOPS) for Unmanned Aircraft System (UAS) Electronic Identification</title>
		<author>
			<organization>EUROCAE</organization>
		</author>
		<date month="06" year="2020"/>
	</front>
	<refcontent>WG-105 SG-32 draft ED-282</refcontent>
	</reference>

	<reference anchor="WiFiNAN" target="https://www.wi-fi.org/downloads-registered-guest/Wi-Fi_Aware_Specification_v3.2.pdf/29731"> target="https://www.wi-fi.org/discover-wi-fi/wi-fi-aware">
	<front>
		<title>Wi-Fi Aware™ Specification Version 3.2</title> Aware</title>
		<author>
			<organization>Wi-Fi Alliance</organization>
		</author>
		<date month="10" year="2020"/>
	</front>
	</reference>
</references>
</references>
<section anchor="Discussion" numbered="true" toc="default"> <name>Discussion and Limitations</name>

<t>
	This document is largely based on the process of one SDO, SDO -- ASTM.
	Therefore, it is tailored to specific needs and data formats of
	this standard. Other organizations, ASTM's
	"Standard Specification for example Remote ID and Tracking" <xref
	target="F3411-19" format="default"/>. Other organizations (for
	example, in EU, the EU) do not necessarily follow the same architecture.
</t>
<t>
	The need for drone ID and operator privacy is an open discussion
	topic. For instance, in the ground vehicular domain domain, each car
	carries a publicly visible plate number. In some countries, for
	nominal cost or even for free, anyone can resolve the identity and
	contact information of the owner. Civil commercial aviation and
	maritime industries also have a tradition of broadcasting plane or
	ship ID, coordinates, and even flight plans in plain text. plaintext.
	Community networks such as OpenSky <xref target="OpenSky"
	format="default"/> and Flightradar24 <xref target="FR24"
	format="default"/> use this open information through ADS-B to
	deploy public services of flight tracking. Many researchers also
	use these data to perform optimization of routes and airport
	operations. Such ID information should be integrity protected, but
	not necessarily confidential.
</t>
<t>
	In civil aviation, aircraft identity is broadcast by a device known
	as transponder. It transmits a four octal four-octal digit squawk code, which
	is assigned by a traffic controller to an airplane after approving
	a flight plan. There are several reserved codes codes, such as 7600 which 7600, that
	indicate radio communication failure. The codes are unique in each
	traffic area and can be re-assigned when entering another control
	area. The code is transmitted in plain text plaintext by the transponder and
	also used for collision avoidance by a system known as Traffic
	alert and Collision Avoidance System (TCAS). The system could be
	used for UAS as well initially, but the code space is quite limited
	and likely to be exhausted soon. The number of UAS far exceeds the
	number of civil airplanes in operation.
</t>
<t>
	The ADS-B system is utilized in civil aviation for each “ADS-B Out” "ADS-B Out"
	equipped airplane to broadcast its ID, coordinates, and altitude
	for other airplanes and ground control stations. If this system is
	adopted for drone IDs, it has additional benefit with backward
	compatibility with civil aviation infrastructure; then, pilots and
	dispatchers will be able to see UA on their control screens and
	take those into account. If not, a gateway translation system
	between the proposed drone ID and civil aviation system should be
	implemented. Again, system saturation due to large numbers of UAS
	is a concern.
</t>
<t>
	The Mode S transponders used in all TCAS and most ADS-B Out "ADS-B Out"
	installations are assigned an ICAO 24 bit 24-bit "address" (arguably
	really an identifier rather than a locator) that is associated with
	the aircraft as part of its registration. In the US alone, well
	over 2^20 2<sup>20</sup> UAS are already flying; thus, a 24 bit 24-bit space likely would
	be rapidly exhausted if used for UAS (other than large UAS flying
	in controlled airspace, especially internationally, under rules
	other than those governing small UAS at low altitudes).
</t>

<t>
	Wi-Fi and Bluetooth are two wireless technologies currently
	recommended by ASTM specifications due to their widespread use and
	broadcast nature. However, those have limited range (max 100s of
	meters) and may not reliably deliver UAS ID at high altitude or
	distance. Therefore, a study should be made of alternative
	technologies from the telecom domain (WiMAX (e.g., WiMAX / IEEE 802.16, 5G) or
	sensor networks (Sigfox, (e.g., Sigfox, LoRa). Such transmission technologies can
	impose additional restrictions on packet sizes and frequency of
	transmissions,
	transmissions but could provide better energy efficiency and
	range.
</t>
<t>
	In civil aviation, Controller-Pilot Data Link Communications
	(CPDLC) is used to transmit command and control between the pilots
	and ATC. It could be considered for UAS as well due to long range long-range
	and proven use despite its lack of security <xref target="CPDLC"
	format="default"/>.
</t>
<t>
	L-band Digital Aeronautical Communications System (LDACS) is being
	standardized by ICAO and IETF for use in future civil aviation
	<xref target="I-D.ietf-raw-ldacs" format="default"/>. It LDACS
	provides secure communication, positioning, and control for aircraft
	using a dedicated radio band. It should be analyzed as a potential
	provider for UAS RID as well. This will bring the benefit of a
	global integrated system creating a awareness of global airspace use
	awareness. use.
</t>
</section>
<section numbered="false" toc="default"> <name>Acknowledgments</name>
<t>
	The work of the FAA's UAS Identification and Tracking (UAS ID)
	Aviation Rulemaking Committee (ARC) is the foundation of later ASTM
	<xref target="F3411-19" format="default"/> and IETF DRIP efforts.
	The work of Gabriel Cox, <contact fullname="Gabriel Cox"/>, Intel Corp., and their Open Drone ID
	collaborators opened UAS RID to a wider community. The work of ASTM
	F38.02 in balancing the interests of diverse stakeholders is
	essential to the necessary rapid and widespread deployment of UAS
	RID. IETF volunteers who have extensively reviewed or otherwise
	contributed to this document include Amelia Andersdotter, Carsten
	Bormann, Toerless Eckert, Susan Hares, Mika Jarvenpaa, Alexandre
	Petrescu, Saulo <contact fullname="Amelia Andersdotter"/>, <contact fullname="Carsten
	Bormann"/>, <contact fullname="Toerless Eckert"/>, <contact fullname="Susan Hares"/>, <contact fullname="Mika Jarvenpaa"/>, <contact fullname="Alexandre
	Petrescu"/>, <contact fullname="Saulo Da Silva Silva"/>, and Shuai Zhao. <contact fullname="Shuai Zhao"/>. Thanks to Linda Dunbar <contact fullname="Linda Dunbar"/> for
	the Secdir SECDIR review, Nagendra Nainar <contact fullname="Nagendra Nainar"/> for the Opsdir review OPSDIR review, and Suresh
	Krishnan <contact fullname="Suresh
	Krishnan"/> for the Gen-ART review. Thanks to IESG members Roman
	Danyliw, Erik Kline, Murray Kucherawy <contact fullname="Roman
	Danyliw"/>, <contact fullname="Erik Kline"/>, <contact fullname="Murray Kucherawy"/>, and Robert Wilton <contact fullname="Robert Wilton"/> for helpful
	and positive comments. Thanks to chairs Daniel Migault and Mohamed
	Boucadair <contact fullname="Daniel Migault"/> and <contact fullname="Mohamed
	Boucadair"/> for direction of our team of authors and editor, some of
	whom are newcomers to writing IETF documents. Thanks especially to
	Internet Area Director Eric Vyncke <contact fullname="Éric Vyncke"/> for guidance and support.
	</t><t>This work was partly supported by the EU project AiRMOUR (enabling sustainable air mobility in urban contexts via
emergency and medical services) under grant agreement no. 101006601.
</t>
</section>

</back>

</rfc>