draft-ietf-drip-reqs-12.txt   draft-ietf-drip-reqs-13.txt 
DRIP S. Card, Ed. DRIP S. Card, Ed.
Internet-Draft A. Wiethuechter Internet-Draft A. Wiethuechter
Intended status: Informational AX Enterprize Intended status: Informational AX Enterprize
Expires: 24 November 2021 R. Moskowitz Expires: 16 December 2021 R. Moskowitz
HTT Consulting HTT Consulting
A. Gurtov A. Gurtov
Linköping University Linköping University
23 May 2021 14 June 2021
Drone Remote Identification Protocol (DRIP) Requirements Drone Remote Identification Protocol (DRIP) Requirements
draft-ietf-drip-reqs-12 draft-ietf-drip-reqs-13
Abstract Abstract
This document defines terminology and requirements for Drone Remote This document defines terminology and requirements for Drone Remote
Identification Protocol (DRIP) Working Group solutions to support Identification Protocol (DRIP) Working Group solutions to support
Unmanned Aircraft System Remote Identification and tracking (UAS RID) Unmanned Aircraft System Remote Identification and tracking (UAS RID)
for security, safety, and other purposes (e.g., initiation of for security, safety, and other purposes (e.g., initiation of
identity based network sessions supporting UAS applications). identity based network sessions supporting UAS applications).
Complementing external technical standards as regulator-accepted Complementing external technical standards as regulator-accepted
means of compliance with UAS RID regulations, DRIP will facilitate means of compliance with UAS RID regulations, DRIP will facilitate
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 24 November 2021. This Internet-Draft will expire on 16 December 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 23 skipping to change at page 2, line 23
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation and External Influences . . . . . . . . . . . 3 1.1. Motivation and External Influences . . . . . . . . . . . 3
1.2. Concerns and Constraints . . . . . . . . . . . . . . . . 8 1.2. Concerns and Constraints . . . . . . . . . . . . . . . . 8
1.3. DRIP Scope . . . . . . . . . . . . . . . . . . . . . . . 10 1.3. DRIP Scope . . . . . . . . . . . . . . . . . . . . . . . 10
1.4. Document Scope . . . . . . . . . . . . . . . . . . . . . 11 1.4. Document Scope . . . . . . . . . . . . . . . . . . . . . 11
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 11 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 11
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 11 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 11
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 11 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 12
3. UAS RID Problem Space . . . . . . . . . . . . . . . . . . . . 19 3. UAS RID Problem Space . . . . . . . . . . . . . . . . . . . . 20
3.1. Network RID . . . . . . . . . . . . . . . . . . . . . . . 21 3.1. Network RID . . . . . . . . . . . . . . . . . . . . . . . 22
3.2. Broadcast RID . . . . . . . . . . . . . . . . . . . . . . 25 3.2. Broadcast RID . . . . . . . . . . . . . . . . . . . . . . 25
3.3. USS in UTM and RID . . . . . . . . . . . . . . . . . . . 28 3.3. USS in UTM and RID . . . . . . . . . . . . . . . . . . . 29
3.4. DRIP Focus . . . . . . . . . . . . . . . . . . . . . . . 29 3.4. DRIP Focus . . . . . . . . . . . . . . . . . . . . . . . 30
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 30 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1.1. Normative Requirements . . . . . . . . . . . . . . . 30 4.1.1. Normative Requirements . . . . . . . . . . . . . . . 31
4.1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 31 4.1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 32
4.2. Identifier . . . . . . . . . . . . . . . . . . . . . . . 32 4.2. Identifier . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.1. Normative Requirements . . . . . . . . . . . . . . . 32 4.2.1. Normative Requirements . . . . . . . . . . . . . . . 33
4.2.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 33 4.2.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 34
4.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3.1. Normative Requirements . . . . . . . . . . . . . . . 34 4.3.1. Normative Requirements . . . . . . . . . . . . . . . 35
4.3.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 35 4.3.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 36
4.4. Registries . . . . . . . . . . . . . . . . . . . . . . . 35 4.4. Registries . . . . . . . . . . . . . . . . . . . . . . . 37
4.4.1. Normative Requirements . . . . . . . . . . . . . . . 35 4.4.1. Normative Requirements . . . . . . . . . . . . . . . 37
4.4.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 36 4.4.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 37
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
6. Security Considerations . . . . . . . . . . . . . . . . . . . 37 6. Security Considerations . . . . . . . . . . . . . . . . . . . 38
7. Privacy and Transparency Considerations . . . . . . . . . . . 38 7. Privacy and Transparency Considerations . . . . . . . . . . . 39
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.1. Normative References . . . . . . . . . . . . . . . . . . 39 8.1. Normative References . . . . . . . . . . . . . . . . . . 40
8.2. Informative References . . . . . . . . . . . . . . . . . 39 8.2. Informative References . . . . . . . . . . . . . . . . . 40
Appendix A. Discussion and Limitations . . . . . . . . . . . . . 43 Appendix A. Discussion and Limitations . . . . . . . . . . . . . 44
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 45 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
1. Introduction 1. Introduction
For any unfamiliar or _a priori_ ambiguous terminology herein, see For any unfamiliar or _a priori_ ambiguous terminology herein, see
Section 2. Section 2.
1.1. Motivation and External Influences 1.1. Motivation and External Influences
Many considerations (especially safety and security) necessitate Many considerations (especially safety and security) necessitate
Unmanned Aircraft Systems (UAS) Remote Identification and tracking Unmanned Aircraft Systems (UAS) Remote Identification and tracking
skipping to change at page 4, line 22 skipping to change at page 4, line 22
Internet family protocols and services to support arbitrary Internet family protocols and services to support arbitrary
applications, beyond the basic security functions of RID. For most applications, beyond the basic security functions of RID. For most
of these, some type of identifier is essential, e.g., Network Access of these, some type of identifier is essential, e.g., Network Access
Identifier (NAI), Digital Object Identifier (DOI), Uniform Resource Identifier (NAI), Digital Object Identifier (DOI), Uniform Resource
Identifier (URI), domain name, or public key. DRIP motivations Identifier (URI), domain name, or public key. DRIP motivations
include both the basic security and the broader application support include both the basic security and the broader application support
functions of RID. functions of RID.
The general UAS RID usage scenario is illustrated in Figure 1. The general UAS RID usage scenario is illustrated in Figure 1.
UA1 UA2 +-----+ +-----+
x x x x | UA1 | | UA2 |
xxxxx xxxxx +-----+ +-----+
+----------+ +----------+
| 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 |
+-----+
General x x Public
Public xxxxx xxxxx Safety
Observer x x Observer
x x
x x ---------+ +---------- x x
x x | | x x
| |
+ +
xxxxxxxxxx
x x
+----------+x Internet x+------------+
| x x |
UA1 x | xxxxxxxxxx | x UA2
Pilot/ xxxxx + + + xxxxx Pilot/
Operator x | | | x Operator
x | | | x
x x | | | x x
x x | | | x x
| | |
+----------+ | | | +----------+
| |------+ | +-------| |
| Public | | | Private |
| Registry | +-----+ | Registry |
| | | DNS | | |
+----------+ +-----+ +----------+
Figure 1: "General UAS RID Usage Scenario" Figure 1: "General UAS RID Usage Scenario"
Figure 1 illustrates a typical case where there may be: multiple Figure 1 illustrates a typical case where there may be: multiple
Observers, some of them members of the general public, others Observers, some of them members of the general public, others
government officers with public safety/security responsibilities; government officers with public safety/security responsibilities;
multiple UA in flight within observation range, each with its own multiple UA in flight within observation range, each with its own
pilot/operator; at least one registry each for lookup of public and pilot/operator; at least one registry each for lookup of public and
(by authorized parties only) private information regarding the UAS (by authorized parties only) private information regarding the UAS
and their pilots/operators; and in the DRIP vision, DNS resolving and their pilots/operators; and in the DRIP vision, DNS resolving
various identifiers and locators of the entities involved. Note the various identifiers and locators of the entities involved. Note the
skipping to change at page 5, line 36 skipping to change at page 5, line 31
xxxxxxx +--------------+ xxxxxxx +--------------+
x x No | | x x No | |
x ID? x+---->| Unidentified | x ID? x+---->| Unidentified |
x x | | x x | |
xxxxxxx +--------------+ xxxxxxx +--------------+
+ +
| Yes | Yes
v v
xxxxxxx xxxxxxx
x x x x
+---------+x Type? x+----------+ /---------+x Type? x+----------\
| x x | | x x |
| xxxxxxx | | xxxxxxx |
| + | | + |
v v v v v v
+--------------+ +--------------+ +--------------+ +--------------+ +--------------+ +--------------+
| | | | | | | | | | | |
| Taskable | | Low Concern | | High Concern | | Taskable | | Low Concern | | High Concern |
| | | | | | | | | | | |
+--------------+ +--------------+ +--------------+ +--------------+ +--------------+ +--------------+
skipping to change at page 6, line 23 skipping to change at page 6, line 17
and provision of other services. and provision of other services.
Using UAS RID to facilitate vehicular (V2X) communications and Using UAS RID to facilitate vehicular (V2X) communications and
applications such as Detect And Avoid (DAA), which would impose applications such as Detect And Avoid (DAA), which would impose
tighter latency bounds than RID itself, is an obvious possibility, tighter latency bounds than RID itself, is an obvious possibility,
explicitly contemplated in the United States (US) Federal Aviation explicitly contemplated in the United States (US) Federal Aviation
Administration (FAA) Remote Identification of Unmanned Aircraft rule Administration (FAA) Remote Identification of Unmanned Aircraft rule
[FRUR]. However, applications of RID beyond RID itself, including [FRUR]. However, applications of RID beyond RID itself, including
DAA, have been declared out of scope in ASTM F38.02 WK65041, based on DAA, have been declared out of scope in ASTM F38.02 WK65041, based on
a distinction between RID as a security standard vs DAA as a safety a distinction between RID as a security standard vs DAA as a safety
application. Each SDO has its own cultural set of connotations of application. Each Standards Development Organization (SDO) has its
safety vs security; ICAO's denotative definitions are cited in own cultural set of connotations of safety vs security; the
Section 2. denotative definitions of the International Civil Aviation
Organization (ICAO) are cited in Section 2.
[Opinion1] and [WG105] cite the Direct Remote Identification (DRI) [Opinion1] and [WG105] cite the Direct Remote Identification (DRI)
previously required and specified, explicitly stating that whereas previously required and specified, explicitly stating that whereas
DRI is primarily for security purposes, the "Network Identification DRI is primarily for security purposes, the "Network Identification
Service" [Opinion1] (in the context of U-space [InitialView]) or Service" [Opinion1] (in the context of U-space [InitialView]) or
"Electronic Identification" [WG105] is primarily for safety purposes "Electronic Identification" [WG105] is primarily for safety purposes
(e.g., Air Traffic Management, especially hazards deconfliction) and (e.g., Air Traffic Management, especially hazards deconfliction) and
also is allowed to be used for other purposes such as support of also is allowed to be used for other purposes such as support of
efficient operations. These emerging standards allow the security efficient operations. These emerging standards allow the security
and safety oriented systems to be separate or merged. In addition to and safety oriented systems to be separate or merged. In addition to
skipping to change at page 7, line 50 skipping to change at page 7, line 44
ASD-STAN also contemplates corresponding Network Remote ASD-STAN also contemplates corresponding Network Remote
Identification (NRI) functionality. The ASD-STAN RID target is to Identification (NRI) functionality. The ASD-STAN RID target is to
revise their current standard with additional functionality (e.g., revise their current standard with additional functionality (e.g.,
DRIP) to be published before 2022 [ASDRI]. DRIP) to be published before 2022 [ASDRI].
Security oriented UAS RID essentially has two goals: enable the Security oriented UAS RID essentially has two goals: enable the
general public to obtain and record an opaque ID for any observed UA, general public to obtain and record an opaque ID for any observed UA,
which they can then report to authorities; enable authorities, from which they can then report to authorities; enable authorities, from
such an ID, to look up information about the UAS and its operator. such an ID, to look up information about the UAS and its operator.
Safety oriented UAS RID has stronger requirements. Aviation Safety oriented UAS RID has stronger requirements. Aviation
community Standards Development Organizations (SDOs) set a higher bar community SDOs set a higher bar for safety than for security,
for safety than for security, especially with respect to reliability. especially with respect to reliability.
Although dynamic establishment of secure communications between the Although dynamic establishment of secure communications between the
Observer and the UAS pilot seems to have been contemplated by the FAA Observer and the UAS pilot seems to have been contemplated by the FAA
UAS ID and Tracking Aviation Rulemaking Committee (ARC) in their UAS ID and Tracking Aviation Rulemaking Committee (ARC) in their
[Recommendations], it is not addressed in any of the [Recommendations], it is not addressed in any of the
subsequent regulations or international SDO technical specifications, subsequent regulations or international SDO technical specifications,
other than DRIP, known to the authors as of early 2021. other than DRIP, known to the authors as of early 2021.
1.2. Concerns and Constraints 1.2. Concerns and Constraints
skipping to change at page 8, line 33 skipping to change at page 8, line 33
be initiated automatically by a process on the UA. Data in the be initiated automatically by a process on the UA. Data in the
reports may come from sensors available to the operator (e.g., radar reports may come from sensors available to the operator (e.g., radar
or cameras), the GCS (e.g., "dead reckoning" UA location, starting or cameras), the GCS (e.g., "dead reckoning" UA location, starting
from the takeoff location and estimating the displacements due to from the takeoff location and estimating the displacements due to
subsequent piloting commands, wind, etc.), or the UA itself (e.g., an subsequent piloting commands, wind, etc.), or the UA itself (e.g., an
on-board GNSS receiver); in Broadcast RID, all the data must be sent on-board GNSS receiver); in Broadcast RID, all the data must be sent
proximately by, and most of the data comes ultimately from, the UA proximately by, and most of the data comes ultimately from, the UA
itself. Whether information comes proximately from the operator, or itself. Whether information comes proximately from the operator, or
from automated systems configured by the operator, there are from automated systems configured by the operator, there are
possibilities not only of unintentional error in but also of possibilities not only of unintentional error in but also of
intentional falsification of this data. intentional falsification of this data. Mandating UAS RID,
specifying data elements required to be sent, monitoring compliance
and enforcing it (or penalizing non-compliance) are matters for Civil
Aviation Authorities (CAAs) et al; specifying message formats, etc.
to carry those data elements has been addressed by other SDOs;
offering technical means, as extensions to external standards, to
facilitate verifiable compliance and enforcement/monitoring, are
opportunities for DRIP.
Minimal specified information must be made available to the public. Minimal specified information must be made available to the public.
Access to other data, e.g., UAS operator Personally Identifiable Access to other data, e.g., UAS operator Personally Identifiable
Information (PII), must be limited to strongly authenticated Information (PII), must be limited to strongly authenticated
personnel, properly authorized in accordance with applicable policy. personnel, properly authorized in accordance with applicable policy.
The balance between privacy and transparency remains a subject for The balance between privacy and transparency remains a subject for
public debate and regulatory action; DRIP can only offer tools to public debate and regulatory action; DRIP can only offer tools to
expand the achievable trade space and enable trade-offs within that expand the achievable trade space and enable trade-offs within that
space. [F3411-19], the basis for most current (2021) thinking about space. [F3411-19], the basis for most current (2021) thinking about
and efforts to provide UAS RID, specifies only how to get the UAS ID 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 to the Observer: how the Observer can perform these lookups and how
the registries first can be populated with information are the registries first can be populated with information are
unspecified therein. unspecified therein.
The need for nearly universal deployment of UAS RID is pressing: The need for nearly universal deployment of UAS RID is pressing:
consider how negligible the value of an automobile license plate consider how negligible the value of an automobile license plate
system would be if only 90% of the cars displayed plates. This system would be if only 90% of the cars displayed plates. This
implies the need to support use by Observers of already ubiquitous implies the need to support use by Observers of already ubiquitous
mobile devices (typically smartphones and tablets). Anticipating mobile devices (typically smartphones and tablets). Anticipating CAA
Civil Aviation Authority (CAA) requirements to support legacy requirements to support legacy devices, especially in light of
devices, especially in light of [Recommendations], [F3411-19] [Recommendations], [F3411-19] specifies that any UAS sending
specifies that any UAS sending Broadcast RID over Bluetooth must do Broadcast RID over Bluetooth must do so over Bluetooth 4, regardless
so over Bluetooth 4, regardless of whether it also does so over newer of whether it also does so over newer versions; as UAS sender devices
versions; as UAS sender devices and Observer receiver devices are and Observer receiver devices are unpaired, this implies extremely
unpaired, this implies extremely short "advertisement" (beacon) short "advertisement" (beacon) frames.
frames.
Wireless data links to or from UA are challenging. Flight is often Wireless data links to or from UA are challenging. Flight is often
amidst structures and foliage at low altitudes over varied terrain. amidst structures and foliage at low altitudes over varied terrain.
UA are constrained in both total energy and instantaneous power by UA are constrained in both total energy and instantaneous power by
their batteries. Small UA imply small antennas. Densely populated their batteries. Small UA imply small antennas. Densely populated
volumes will suffer from link congestion: even if UA in an airspace volumes will suffer from link congestion: even if UA in an airspace
volume are few, other transmitters nearby on the ground, sharing the volume are few, other transmitters nearby on the ground, sharing the
same license free spectral band, may be many. Thus air to air and same license free spectral band, may be many. Thus air to air and
air to ground links will generally be slow and unreliable. air to ground links will generally be slow and unreliable.
skipping to change at page 22, line 4 skipping to change at page 22, line 25
Jurisdictions may relax or waive RID requirements for certain Jurisdictions may relax or waive RID requirements for certain
operators and/or under certain conditions. For example, [FRUR] operators and/or under certain conditions. For example, [FRUR]
allows operators with UAS not equipped for RID to conduct VLOS allows operators with UAS not equipped for RID to conduct VLOS
operations at counter-intuitively named "FAA-recognized operations at counter-intuitively named "FAA-recognized
identification areas" (FRIA); radio controlled model aircraft flying identification areas" (FRIA); radio controlled model aircraft flying
clubs and other eligible organizations can apply to the FAA for such clubs and other eligible organizations can apply to the FAA for such
recognition of their operating areas. recognition of their operating areas.
3.1. Network RID 3.1. Network RID
x x UA
xxxxxxx +-------------+ ******************
| \ | UA | * Internet *
| \ +--o-------o--+ * *
| \ | | * *
| \ ******************** | | * * +------------+
| \* ------*---+------------+ | \--------*--(+)-----------*-----o |
| *\ / * | NET-Rid SP | | * | * | |
| * ------------/ +---*--+------------+ | /--------*--(+)-----------*-----o NET-Rid SP |
| RF */ | * | | * * | |
| / INTERNET | * +------------+ | | * /------*-----o |
| /* +---*--| NET-Rid DP | | | * | * +------------+
| / * +----*--+------------+ | | * | *
+ / * | * | | * | * +------------+
x / ****************|*** x | | * \------*-----o |
xxxxx | xxxxx | | * * | NET-Rid DP |
x +------- x | | * /------*-----o |
x x | | * | * +------------+
x x Operator's GCS Observer x x | | * | *
x x x x | | * | * +------------+
+--o-------o--+ * \------*-----o Observer’s |
| GCS | * * | Device |
+-------------+ ****************** +------------+
Figure 3: "Network RID Information Flow" Figure 3: "Network RID Information Flow"
Figure 3 illustrates Network RID information flows. Only two of the Figure 3 illustrates Network RID information flows. Only two of the
three typically wireless links shown involving the UAS (UA-GCS, UA- three typically wireless links shown involving the UAS (UA-GCS, UA-
Internet, and GCS-Internet) need exist. All three may exist, at the Internet, and GCS-Internet) need exist. All three may exist, at the
same or different times, especially in Beyond Visual Line Of Sight same or different times, especially in Beyond Visual Line Of Sight
(BVLOS) operations. There must be some information flow path (direct (BVLOS) operations. There must be some information flow path (direct
or indirect) between the GCS and the UA, for the former to exercise 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, C2 over the latter. If this path is two-way (as increasingly it is,
skipping to change at page 25, line 6 skipping to change at page 26, line 4
(APIs) and browsers. (APIs) and browsers.
Network RID is the less constrained of the defined UAS RID means. Network RID is the less constrained of the defined UAS RID means.
[F3411-19] specifies only Net-RID SP to Net-RID DP information [F3411-19] specifies only Net-RID SP to Net-RID DP information
exchanges. It is presumed that IETF efforts supporting the more exchanges. It is presumed that IETF efforts supporting the more
constrained Broadcast RID (see next section) can be generalized for constrained Broadcast RID (see next section) can be generalized for
Network RID and potentially also for UAS to USS or other UTM Network RID and potentially also for UAS to USS or other UTM
communications. communications.
3.2. Broadcast RID 3.2. Broadcast RID
+-------------------+
x x UA | Unmanned Aircraft |
xxxxx +---------o---------+
| |
| |
| app messages directly over one-way RF data link |
| | app messages directly over one-way RF data link
| |
+ |
x |
xxxxx +------------------o-------------------+
x | Observer's device (e.g., smartphone) |
x +--------------------------------------+
x x Observer's device (e.g., smartphone)
x x
Figure 4: "Broadcast RID Information Flow" Figure 4: "Broadcast RID Information Flow"
Figure 4 illustrates Broadcast RID information flow. Note the Figure 4 illustrates Broadcast RID information flow. Note the
absence of the Internet from the figure. This is because Broadcast absence of the Internet from the figure. This is because Broadcast
RID is one-way direct transmission of application layer messages over RID is one-way direct transmission of application layer messages over
a RF data link (without IP) from the UA to local Observer devices. a RF data link (without IP) from the UA to local Observer devices.
Internet connectivity is involved only in what the Observer chooses Internet connectivity is involved only in what the Observer chooses
to do with the information received, such as verify signatures using to do with the information received, such as verify signatures using
a web-based Broadcast Authentication Verifier Service and look up a web-based Broadcast Authentication Verifier Service and look up
skipping to change at page 34, line 4 skipping to change at page 35, line 8
Registry ID (which registry the entity is in) and Entity ID (which 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 it is, within that registry) are requirements on a single DRIP
entity identifier, not separate (types of) ID. In the most common 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 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 the UAS ID; however, other entities may also benefit from having DRIP
identifiers, so the entity type is not prescribed here. identifiers, so the entity type is not prescribed here.
Whether a UAS ID is generated by the operator, GCS, UA, USS, Whether a UAS ID is generated by the operator, GCS, UA, USS,
registry, or some collaboration thereamong, is unspecified; however, registry, or some collaboration thereamong, is unspecified; however,
there must be agreement on the UAS ID among these entities. 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.
While "uniqueness" might be considered an implicit requirement for While "uniqueness" might be considered an implicit requirement for
any identifier, here the point of the explicit requirement is not 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 just that it should be unique, but also where and when it should be
unique: global scope within a specified space, from registration to unique: global scope within a specified space, from registration to
deregistration. deregistration.
While "non-spoofability" imposes requirements for and on a DRIP While "non-spoofability" imposes requirements for and on a DRIP
authentication protocol, it also imposes requirements on the authentication protocol, it also imposes requirements on the
properties of the identifier itself. An example of how the nature of properties of the identifier itself. An example of how the nature of
skipping to change at page 36, line 40 skipping to change at page 37, line 45
4.4.2. Rationale 4.4.2. Rationale
Registries are fundamental to RID. Only very limited information can Registries are fundamental to RID. Only very limited information can
be Broadcast, but extended information is sometimes needed. The most be Broadcast, but extended information is sometimes needed. The most
essential element of information sent is the UAS ID itself, the essential element of information sent is the UAS ID itself, the
unique key for lookup of extended information in registries. Beyond unique key for lookup of extended information in registries. Beyond
designating the UAS ID as that unique key, the registry information designating the UAS ID as that unique key, the registry information
model is not specified herein, in part because regulatory model is not specified herein, in part because regulatory
requirements for different registries (UAS operators and their UA, requirements for different registries (UAS operators and their UA,
each narrowly for UAS RID and broadly for U-space/UTM) and business each narrowly for UAS RID and broadly for U-space/UTM) and business
models for meeting those requirements are in flux. However those may models for meeting those requirements are in flux. While it is
evolve, the essential registry functions remain the same, so are expected that registry functions will be integrated with USS, who
specified herein. will provide them is not yet determined in most, and is expected to
vary between, jurisdictions. However this evolves, the essential
registry functions, starting with management of identifiers, are
expected to remain the same, so are specified herein.
While most data to be sent via Broadcast or Network RID is public, While most data to be sent via Broadcast or Network RID is public,
much of the extended information in registries will be private. Thus much of the extended information in registries will be private. Thus
AAA for registries is essential, not just to ensure that access is AAA for registries is essential, not just to ensure that access is
granted only to strongly authenticated, duly authorized parties, but granted only to strongly authenticated, duly authorized parties, but
also to support subsequent attribution of any leaks, audit of who also to support subsequent attribution of any leaks, audit of who
accessed information when and for what purpose, etc. As specific AAA accessed information when and for what purpose, etc. As specific AAA
requirements will vary by jurisdictional regulation, provider requirements will vary by jurisdictional regulation, provider
philosophy, customer demand, etc., they are left to specification in philosophy, customer demand, etc., they are left to specification in
policies, which should be human readable to facilitate analysis and policies, which should be human readable to facilitate analysis and
skipping to change at page 45, line 30 skipping to change at page 46, line 30
The work of the FAA's UAS Identification and Tracking (UAS ID) The work of the FAA's UAS Identification and Tracking (UAS ID)
Aviation Rulemaking Committee (ARC) is the foundation of later ASTM Aviation Rulemaking Committee (ARC) is the foundation of later ASTM
[F3411-19] and IETF DRIP efforts. The work of Gabriel Cox, Intel [F3411-19] and IETF DRIP efforts. The work of Gabriel Cox, Intel
Corp., and their Open Drone ID collaborators opened UAS RID to a Corp., and their Open Drone ID collaborators opened UAS RID to a
wider community. The work of ASTM F38.02 in balancing the interests wider community. The work of ASTM F38.02 in balancing the interests
of diverse stakeholders is essential to the necessary rapid and of diverse stakeholders is essential to the necessary rapid and
widespread deployment of UAS RID. IETF volunteers who have widespread deployment of UAS RID. IETF volunteers who have
extensively reviewed or otherwise contributed to this document extensively reviewed or otherwise contributed to this document
include Amelia Andersdotter, Carsten Bormann, Mohamed Boucadair, include Amelia Andersdotter, Carsten Bormann, Mohamed Boucadair,
Toerless Eckert, Susan Hares, Mika Jarvenpaa, Daniel Migault, Toerless Eckert, Susan Hares, Mika Jarvenpaa, Daniel Migault,
Alexandre Petrescu, Saulo Da Silva and Shuai Zhao. Alexandre Petrescu, Saulo Da Silva and Shuai Zhao. Thanks to Linda
Dunbar for the Secdir review and Nagendra Nainar for the Opsdir
review.
Authors' Addresses Authors' Addresses
Stuart W. Card (editor) Stuart W. Card (editor)
AX Enterprize AX Enterprize
4947 Commercial Drive 4947 Commercial Drive
Yorkville, NY 13495 Yorkville, NY 13495
United States of America United States of America
Email: stu.card@axenterprize.com Email: stu.card@axenterprize.com
 End of changes. 18 change blocks. 
113 lines changed or deleted 127 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/