draft-ietf-drip-reqs-13.txt		draft-ietf-drip-reqs-14.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: 16 December 2021 R. Moskowitz		Expires: 27 December 2021 R. Moskowitz
	HTT Consulting		HTT Consulting
	A. Gurtov		A. Gurtov
	Linköping University		Linköping University
	14 June 2021		25 June 2021
	Drone Remote Identification Protocol (DRIP) Requirements		Drone Remote Identification Protocol (DRIP) Requirements
	draft-ietf-drip-reqs-13		draft-ietf-drip-reqs-14
	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 16 December 2021.		This Internet-Draft will expire on 27 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 . . . . . . . . . . . . . . . . . . . . . . . 12		2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 11
	3. UAS RID Problem Space . . . . . . . . . . . . . . . . . . . . 20		3. UAS RID Problem Space . . . . . . . . . . . . . . . . . . . . 20
	3.1. Network RID . . . . . . . . . . . . . . . . . . . . . . . 22		3.1. Network RID . . . . . . . . . . . . . . . . . . . . . . . 22
	3.2. Broadcast RID . . . . . . . . . . . . . . . . . . . . . . 25		3.2. Broadcast RID . . . . . . . . . . . . . . . . . . . . . . 25
	3.3. USS in UTM and RID . . . . . . . . . . . . . . . . . . . 29		3.3. USS in UTM and RID . . . . . . . . . . . . . . . . . . . 28
	3.4. DRIP Focus . . . . . . . . . . . . . . . . . . . . . . . 30		3.4. DRIP Focus . . . . . . . . . . . . . . . . . . . . . . . 29
	4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 31		4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 30
	4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 31		4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 30
	4.1.1. Normative Requirements . . . . . . . . . . . . . . . 31		4.1.1. Normative Requirements . . . . . . . . . . . . . . . 30
	4.1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 32		4.1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 32
	4.2. Identifier . . . . . . . . . . . . . . . . . . . . . . . 33		4.2. Identifier . . . . . . . . . . . . . . . . . . . . . . . 33
	4.2.1. Normative Requirements . . . . . . . . . . . . . . . 33		4.2.1. Normative Requirements . . . . . . . . . . . . . . . 33
	4.2.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 34		4.2.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 33
	4.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 35		4.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 34
	4.3.1. Normative Requirements . . . . . . . . . . . . . . . 35		4.3.1. Normative Requirements . . . . . . . . . . . . . . . 34
	4.3.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 36		4.3.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 35
	4.4. Registries . . . . . . . . . . . . . . . . . . . . . . . 37		4.4. Registries . . . . . . . . . . . . . . . . . . . . . . . 36
	4.4.1. Normative Requirements . . . . . . . . . . . . . . . 37		4.4.1. Normative Requirements . . . . . . . . . . . . . . . 36
	4.4.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 37		4.4.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 37
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 38		6. Security Considerations . . . . . . . . . . . . . . . . . . . 37
	7. Privacy and Transparency Considerations . . . . . . . . . . . 39		7. Privacy and Transparency Considerations . . . . . . . . . . . 38
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 40		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
	8.1. Normative References . . . . . . . . . . . . . . . . . . 40		8.1. Normative References . . . . . . . . . . . . . . . . . . 39
	8.2. Informative References . . . . . . . . . . . . . . . . . 40		8.2. Informative References . . . . . . . . . . . . . . . . . 40
	Appendix A. Discussion and Limitations . . . . . . . . . . . . . 44		Appendix A. Discussion and Limitations . . . . . . . . . . . . . 44
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 46		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 45
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
	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 18 ¶		skipping to change at page 4, line 18 ¶
	(e.g., UAS or Observer device) encountering an _a priori_ unknown UA		(e.g., UAS or Observer device) encountering an _a priori_ unknown UA
	in physical space has no identifier or logical space locator for that		in physical space has no identifier or logical space locator for that
	UA, unless and until one is provided somehow. RID provides an		UA, unless and until one is provided somehow. RID provides an
	identifier, which, if well chosen, can facilitate use of a variety of		identifier, which, if well chosen, can facilitate use of a variety of
	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 scenario is illustrated in Figure 1.
	The general UAS RID usage scenario is illustrated in Figure 1.
	+-----+ +-----+		*************** ***************
	| UA1 | | UA2 |		* UAS1 * * UAS2 *
	+-----+ +-----+		* * * *
			* +--------+ * DAA/V2V * +--------+ *
			* | UA o--*----------------------------------------*--o UA | *
			* +--o--o--+ * * +--o--o--+ *
			* | | * +------+ Lookups +------+ * | | *
			* | | * | GPOD o------. .------o PSOD | * | | *
			* | | * +------+ | | +------+ * | | *
			* | | * | | * | | *
			* C2 | | * V2I ************ V2I * | | C2 *
			* | '-----*--------------* *--------------*-----' | *
			* | * * * * | *
			* | o====NetRID====* *====NetRID====o | *
			* +--o--+ * * Internet * * +--o--+ *
			* | GCS o-----*--------------* *--------------*-----o GCS | *
			* +-----+ * Registration * * Registration * +-----+ *
			* * (and UTM) * * (and UTM) * *
			*************** ************ ***************
			| | |
			+----------+ | | | +----------+
			| Public o---' | '---o Private |
			| Registry | | | Registry |
			+----------+ | +----------+
			+--o--+
			| DNS |
			+-----+
	+----------+ +----------+		GPOD: General Public Observer Device (used only to fit this figure)
	| General | | Public |		PSOD: Public Safety Observer Device (used only to fit this figure)
	| Public | | Safety |
	| Observer o------\ /------o Observer |
	+----------+ | | +----------+
	| |
	*************
	+----------+ * * +----------+
	| UA1 | * * | UA2 |
	| Pilot/ o------* Internet *------o Pilot/ |
	| Operator | * * | Operator |
	+----------+ * * +----------+
	*************
	| | |
	+----------+ | | | +----------+
	| Public o---/ | \---o Private |
	| Registry | | | Registry |
	+----------+ | +----------+
	+--o--+
	| 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 that
	absence of any links to/from the UA in the figure; this is because		Broadcast RID direct RF links are not shown, as they are indeed
	UAS RID and other connectivity involving the UA varies as described		broadcast, so reach anywhere within range; they do not connect
	below.		specific entity pairings, as edges do vertices in a graph. Further,
			RID and other connectivity involving the UA varies, as described
			subsequently herein under Figure 3. Not all the links shown in
			Figure 1 above necessarily exist in all scenarios (e.g., UA support
			for direct connectivity to the Internet is very rare as of 2021), and
			even those links that exist sometimes in a given scenario are not
			necessarily up at all times in that same scenario (e.g., remote
			Observer connectivity to the Internet may be very intermittent).
	An Observer of UA may need to classify them, as illustrated		An Observer of UA may need to classify them, as illustrated
	notionally in Figure 2, for basic airspace Situational Awareness		notionally in Figure 2, for basic airspace Situational Awareness
	(SA). An Observer who classifies a UAS: as Taskable, can ask it to		(SA). An Observer who classifies a UAS: as Taskable, can ask it to
	do something useful; as Low Concern, can reasonably assume it is not		do something useful; as Low Concern, can reasonably assume it is not
	malicious and would cooperate with requests to modify its flight		malicious and would cooperate with requests to modify its flight
	plans for safety concerns that arise; as High Concern or		plans for safety concerns that arise; as High Concern or
	Unidentified, can focus surveillance on it.		Unidentified, can focus surveillance on it.
	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 |
	| | | | | |
	+--------------+ +--------------+ +--------------+		+--------------+ +--------------+ +--------------+
	Figure 2: "Notional UAS Classification"		Figure 2: "Notional UAS Classification"
	ASTM International, Technical Committee F38 (UAS), Subcommittee		ASTM International, Technical Committee F38 (UAS), Subcommittee
	F38.02 (Aircraft Operations), Work Item WK65041, developed the widely		F38.02 (Aircraft Operations), Work Item WK65041, developed the widely
	cited Standard Specification for Remote ID and Tracking [F3411-19]:		cited Standard Specification for Remote ID and Tracking [F3411-19]:
	the published standard is available for purchase from ASTM and as an		the published standard is available for purchase from ASTM and as an
	ASTM membership premium; early drafts are freely available as		ASTM membership premium; early drafts are freely available as
	[OpenDroneID] specifications. [F3411-19] is frequently referenced in		[OpenDroneID] specifications. [F3411-19] is frequently referenced in
	skipping to change at page 6, line 14 ¶		skipping to change at page 6, line 23 ¶
	In many applications, including UAS RID, identification and		In many applications, including UAS RID, identification and
	identifiers are not ends in themselves; they exist to enable lookups		identifiers are not ends in themselves; they exist to enable lookups
	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, usage of RID systems and information beyond mere
	DAA, have been declared out of scope in ASTM F38.02 WK65041, based on		identification (primarily to hold operators accountable after the
	a distinction between RID as a security standard vs DAA as a safety		fact), including DAA, have been declared out of scope in ASTM F38.02
	application. Each Standards Development Organization (SDO) has its		WK65041, based on a distinction between RID as a security standard vs
	own cultural set of connotations of safety vs security; the		DAA as a safety application. Aviation community Standards
	denotative definitions of the International Civil Aviation		Development Organizations (SDOs) generally set a higher bar for
	Organization (ICAO) are cited in Section 2.		safety than for security, especially with respect to reliability.
			Each SDO has its own cultural set of connotations of safety vs
			security; the 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 43 ¶		skipping to change at page 8, line 9 ¶
	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.
	community SDOs set a higher bar for safety than for security,
	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 22, line 31 ¶		skipping to change at page 22, line 12 ¶
	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
	+-------------+ ******************		+-------------+ ******************
	| UA | * Internet *		| UA | * Internet *
	+--o-------o--+ * *		+--o-------o--+ * *
	| | * *		| | * *
	| | * * +------------+		| | * * +------------+
	| \--------*--(+)-----------*-----o |		| '--------*--(+)-----------*-----o |
	| * | * | |		| * | * | |
	| /--------*--(+)-----------*-----o NET-Rid SP |		| .--------*--(+)-----------*-----o NET-Rid SP |
	| | * * | |		| | * * | |
	| | * /------*-----o |		| | * .------*-----o |
	| | * | * +------------+		| | * | * +------------+
	| | * | *		| | * | *
	| | * | * +------------+		| | * | * +------------+
	| | * \------*-----o |		| | * '------*-----o |
	| | * * | NET-Rid DP |		| | * * | NET-Rid DP |
	| | * /------*-----o |		| | * .------*-----o |
	| | * | * +------------+		| | * | * +------------+
	| | * | *		| | * | *
	| | * | * +------------+		| | * | * +------------+
	+--o-------o--+ * \------*-----o Observer’s |		+--o-------o--+ * '------*-----o Observer's |
	| GCS | * * | Device |		| 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
	skipping to change at page 26, line 4 ¶		skipping to change at page 25, line 19 ¶
	(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
	+-------------------+		+-------------------+
	| Unmanned Aircraft |		| Unmanned Aircraft |
	+---------o---------+		+---------o---------+
	|		|
	|		|
	|		|
	| app messages directly over one-way RF data link		| app messages directly over one-way RF data link
	|		|
	|		|
	|		v
	+------------------o-------------------+		+------------------o-------------------+
	| Observer's device (e.g., smartphone) |		| Observer's device (e.g., smartphone) |
	+--------------------------------------+		+--------------------------------------+
	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.
	skipping to change at page 31, line 36 ¶		skipping to change at page 30, line 51 ¶
	verifying an asymmetric cryptographic signature using a		verifying an asymmetric cryptographic signature using a
	sender provided public key from which the asserted ID can be		sender provided public key from which the asserted ID can be
	at least partially derived), even on an Observer device		at least partially derived), even on an Observer device
	lacking Internet connectivity at the time of observation.		lacking Internet connectivity at the time of observation.
	GEN-2 Provable Binding: DRIP MUST enable binding all other		GEN-2 Provable Binding: DRIP MUST enable binding all other
	[F3411-19] messages from the same actual current sender to		[F3411-19] messages from the same actual current sender to
	the UAS ID asserted in the Basic ID message.		the UAS ID asserted in the Basic ID message.
	GEN-3 Provable Registration: DRIP MUST enable verification that the		GEN-3 Provable Registration: DRIP MUST enable verification that the
	UAS ID is in a registry and identification of which one, even		UAS ID is in a registry and identification of that registry,
	on an Observer device lacking Internet connectivity at the		even on an Observer device lacking Internet connectivity at
	time of observation; with UAS ID Type 3, the same sender may		the time of observation; with UAS ID Type 3, the same sender
	have multiple IDs, potentially in different registries, but		may have multiple IDs, potentially in different registries,
	each ID must clearly indicate in which registry it can be		but each ID must clearly indicate in which registry it can be
	found.		found.
	GEN-4 Readability: DRIP MUST enable information (regulation		GEN-4 Readability: DRIP MUST enable information (regulation
	required elements, whether sent via UAS RID or looked up in		required elements, whether sent via UAS RID or looked up in
	registries) to be read and utilized by both humans and		registries) to be read and utilized by both humans and
	software.		software.
	GEN-5 Gateway: DRIP MUST enable Broadcast RID to Network RID		GEN-5 Gateway: DRIP MUST enable Broadcast RID to Network RID
	application layer gateways to stamp messages with precise		application layer gateways to stamp messages with precise
	date/time received and receiver location, then relay them to		date/time received and receiver location, then relay them to
	a network service (e.g., SDSP or distributed ledger).		a network service (e.g., SDSP or distributed ledger).
	GEN-6 Finger: DRIP MUST enable dynamically establishing, with AAA,		GEN-6 Contact: DRIP MUST enable dynamically establishing, with AAA,
	per policy, strongly mutually authenticated, end-to-end		per policy, strongly mutually authenticated, end-to-end
	strongly encrypted communications with the UAS RID sender and		strongly encrypted communications with the UAS RID sender and
	entities looked up from the UAS ID, including at least the		entities looked up from the UAS ID, including at least the
	remote pilot and USS.		pilot (remote pilot or Pilot In Command), the USS (if any)
			under which the operation is being conducted, and registries
			in which data on the UA and pilot are held.
	GEN-7 QoS: DRIP MUST enable policy based specification of		GEN-7 QoS: DRIP MUST enable policy based specification of
	performance and reliability parameters.		performance and reliability parameters.
	GEN-8 Mobility: DRIP MUST support physical and logical mobility of		GEN-8 Mobility: DRIP MUST support physical and logical mobility of
	UA, GCS and Observers. DRIP SHOULD support mobility of		UA, GCS and Observers. DRIP SHOULD support mobility of
	essentially all participating nodes (UA, GCS, Observers, Net-		essentially all participating nodes (UA, GCS, Observers, Net-
	RID SP, Net-RID DP, Private Registry, SDSP, and potentially		RID SP, Net-RID DP, Private Registry, SDSP, and potentially
	others as RID and UTM evolve).		others as RID and UTM evolve).
End of changes. 32 change blocks.
	86 lines changed or deleted		98 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/