draft-ietf-drip-arch-22.txt   draft-ietf-drip-arch-23.txt 
drip S. Card drip S. Card
Internet-Draft A. Wiethuechter Internet-Draft A. Wiethuechter
Intended status: Informational AX Enterprize Intended status: Informational AX Enterprize
Expires: 22 September 2022 R. Moskowitz Expires: 2 December 2022 R. Moskowitz
HTT Consulting HTT Consulting
S. Zhao (Editor) S. Zhao (Editor)
Tencent Tencent
A. Gurtov A. Gurtov
Linköping University Linköping University
21 March 2022 31 May 2022
Drone Remote Identification Protocol (DRIP) Architecture Drone Remote Identification Protocol (DRIP) Architecture
draft-ietf-drip-arch-22 draft-ietf-drip-arch-23
Abstract Abstract
This document describes an architecture for protocols and services to This document describes an architecture for protocols and services to
support Unmanned Aircraft System (UAS) Remote Identification (RID) support Unmanned Aircraft System (UAS) Remote Identification (RID)
and tracking, plus UAS RID-related communications. This architecture and tracking, plus UAS RID-related communications. This architecture
adheres to the requirements listed in the DRIP Requirements document adheres to the requirements listed in the DRIP Requirements document
(RFC9153). (RFC9153).
Status of This Memo Status of This Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 22 September 2022. This Internet-Draft will expire on 2 December 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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.
skipping to change at page 2, line 43 skipping to change at page 2, line 43
4.2. Private Information Registry . . . . . . . . . . . . . . 15 4.2. Private Information Registry . . . . . . . . . . . . . . 15
4.2.1. Background . . . . . . . . . . . . . . . . . . . . . 15 4.2.1. Background . . . . . . . . . . . . . . . . . . . . . 15
4.2.2. EPP and RDAP as the Private DRIP Identifier 4.2.2. EPP and RDAP as the Private DRIP Identifier
Registry . . . . . . . . . . . . . . . . . . . . . . 16 Registry . . . . . . . . . . . . . . . . . . . . . . 16
4.2.3. Alternative Private DRIP Registry methods . . . . . . 16 4.2.3. Alternative Private DRIP Registry methods . . . . . . 16
5. DRIP Identifier Trust . . . . . . . . . . . . . . . . . . . . 16 5. DRIP Identifier Trust . . . . . . . . . . . . . . . . . . . . 16
6. Harvesting Broadcast Remote ID messages for UTM Inclusion . . 17 6. Harvesting Broadcast Remote ID messages for UTM Inclusion . . 17
6.1. The CS-RID Finder . . . . . . . . . . . . . . . . . . . . 18 6.1. The CS-RID Finder . . . . . . . . . . . . . . . . . . . . 18
6.2. The CS-RID SDSP . . . . . . . . . . . . . . . . . . . . . 18 6.2. The CS-RID SDSP . . . . . . . . . . . . . . . . . . . . . 18
7. DRIP Contact . . . . . . . . . . . . . . . . . . . . . . . . 18 7. DRIP Contact . . . . . . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8.1. Post Quantum Computing out of scope . . . . . . . . . . . 20
10. Privacy & Transparency Considerations . . . . . . . . . . . . 20 9. Privacy & Transparency Considerations . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic
Management (UTM) . . . . . . . . . . . . . . . . . . . . 24 Management (UTM) . . . . . . . . . . . . . . . . . . . . 24
A.1. Operation Concept . . . . . . . . . . . . . . . . . . . . 24 A.1. Operation Concept . . . . . . . . . . . . . . . . . . . . 24
A.2. UAS Service Supplier (USS) . . . . . . . . . . . . . . . 24 A.2. UAS Service Supplier (USS) . . . . . . . . . . . . . . . 25
A.3. UTM Use Cases for UAS Operations . . . . . . . . . . . . 25 A.3. UTM Use Cases for UAS Operations . . . . . . . . . . . . 25
Appendix B. Automatic Dependent Surveillance Broadcast Appendix B. Automatic Dependent Surveillance Broadcast
(ADS-B) . . . . . . . . . . . . . . . . . . . . . . . . . 25 (ADS-B) . . . . . . . . . . . . . . . . . . . . . . . . . 26
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
This document describes an architecture for protocols and services to This document describes an architecture for protocols and services to
support Unmanned Aircraft System (UAS) Remote Identification (RID) support Unmanned Aircraft System (UAS) Remote Identification (RID)
and tracking, plus RID-related communications. The architecture and tracking, plus RID-related communications. The architecture
takes into account both current (including proposed) regulations and takes into account both current (including proposed) regulations and
non-IETF technical standards. non-IETF technical standards.
The architecture adheres to the requirements listed in the DRIP The architecture adheres to the requirements listed in the DRIP
skipping to change at page 3, line 36 skipping to change at page 3, line 36
to be identified by Unmanned Aircraft Systems Traffic Management to be identified by Unmanned Aircraft Systems Traffic Management
(UTM) and UAS Service Supplier (USS) (Appendix A) or third party (UTM) and UAS Service Supplier (USS) (Appendix A) or third party
entities such as law enforcement. Many considerations (e.g., safety) entities such as law enforcement. Many considerations (e.g., safety)
dictate that UAS be remotely identifiable. dictate that UAS be remotely identifiable.
Civil Aviation Authorities (CAAs) worldwide are mandating UAS RID. Civil Aviation Authorities (CAAs) worldwide are mandating UAS RID.
CAAs currently promulgate performance-based regulations that do not CAAs currently promulgate performance-based regulations that do not
specify techniques, but rather cite industry consensus technical specify techniques, but rather cite industry consensus technical
standards as acceptable means of compliance. standards as acceptable means of compliance.
Federal Aviation Administration (FAA) USA Federal Aviation Administration (FAA)
The FAA published a Notice of Proposed Rule Making [NPRM] in 2019 The FAA published a Notice of Proposed Rule Making [NPRM] in 2019
and thereafter published a "Final Rule" in 2021 [FAA_RID], and thereafter published a "Final Rule" in 2021 [FAA_RID],
imposing requirements on UAS manufacturers and operators, both imposing requirements on UAS manufacturers and operators, both
commercial and recreational. The rule clearly states that commercial and recreational. The rule clearly states that
Automatic Dependent Surveillance Broadcast (ADS-B) Out and Automatic Dependent Surveillance Broadcast (ADS-B) Out and
transponders cannot be used to satisfy the UAS RID requirements on transponders cannot be used to satisfy the UAS RID requirements on
UAS to which the rule applies (see Appendix B). UAS to which the rule applies (see Appendix B).
European Union Aviation Safety Agency (EASA) European Union Aviation Safety Agency (EASA)
skipping to change at page 4, line 4 skipping to change at page 3, line 47
The FAA published a Notice of Proposed Rule Making [NPRM] in 2019 The FAA published a Notice of Proposed Rule Making [NPRM] in 2019
and thereafter published a "Final Rule" in 2021 [FAA_RID], and thereafter published a "Final Rule" in 2021 [FAA_RID],
imposing requirements on UAS manufacturers and operators, both imposing requirements on UAS manufacturers and operators, both
commercial and recreational. The rule clearly states that commercial and recreational. The rule clearly states that
Automatic Dependent Surveillance Broadcast (ADS-B) Out and Automatic Dependent Surveillance Broadcast (ADS-B) Out and
transponders cannot be used to satisfy the UAS RID requirements on transponders cannot be used to satisfy the UAS RID requirements on
UAS to which the rule applies (see Appendix B). UAS to which the rule applies (see Appendix B).
European Union Aviation Safety Agency (EASA) European Union Aviation Safety Agency (EASA)
The EASA published a [Delegated] regulation in 2019 imposing The EASA published a [Delegated] regulation in 2019 imposing
requirements on UAS manufacturers and third-country operators, requirements on UAS manufacturers and third-country operators,
including but not limited to UAS RID requirements. The EASA also including but not limited to UAS RID requirements. The same year,
published in 2019 an [Implementing] regulation laying down EASA also published an [Implementing] regulation laying down
detailed rules and procedures for UAS operations and operating detailed rules and procedures for UAS operations and operating
personnel. personnel then was updated in 2021 [Implementing_update]. A
Notice of Proposed Amendment [NPA] was published in 2021 to
provide more information about the development of acceptable means
of compliance and guidance material to support the U-space
regulation.
American Society for Testing and Materials (ASTM) American Society for Testing and Materials (ASTM)
ASTM International, Technical Committee F38 (UAS), Subcommittee ASTM International, Technical Committee F38 (UAS), Subcommittee
F38.02 (Aircraft Operations), Work Item WK65041, developed the F38.02 (Aircraft Operations), Work Item WK65041, developed the
ASTM [F3411] Standard Specification for Remote ID and Tracking. ASTM [F3411] Standard Specification for Remote ID and Tracking.
ASTM defines one set of UAS RID information and two means, MAC- ASTM defines one set of UAS RID information and two means, MAC-
layer broadcast and IP-layer network, of communicating it. If an layer broadcast and IP-layer network, of communicating it. If an
UAS uses both communication methods, the same information must be UAS uses both communication methods, the same information must be
skipping to change at page 10, line 28 skipping to change at page 10, line 28
- Harvesting Broadcast RID messages for UTM inclusion, with the - Harvesting Broadcast RID messages for UTM inclusion, with the
optional DRIP extension of Crowd Sourced Remote ID (CS-RID, optional DRIP extension of Crowd Sourced Remote ID (CS-RID,
Section 6), using the DRIP support for gateways required by Section 6), using the DRIP support for gateways required by
GEN-5 [RFC9153]. GEN-5 [RFC9153].
- Methods for instantly establishing secure communications - Methods for instantly establishing secure communications
between an Observer and the pilot of an observed UAS between an Observer and the pilot of an observed UAS
(Section 7), using the DRIP support for dynamic contact (Section 7), using the DRIP support for dynamic contact
required by GEN-4 [RFC9153]. required by GEN-4 [RFC9153].
- Privacy in UAS RID messages (PII protection) (Section 10). - Privacy in UAS RID messages (PII protection) (Section 9).
2. Terms and Definitions 2. Terms and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
To encourage comprehension necessary for adoption of DRIP by the To encourage comprehension necessary for adoption of DRIP by the
skipping to change at page 13, line 14 skipping to change at page 13, line 14
By construction, the HIT is statistically unique through the By construction, the HIT is statistically unique through the
cryptographic hash feature of second-preimage resistance. The cryptographic hash feature of second-preimage resistance. The
cryptographically-bound addition of the Hierarchy and an HHIT cryptographically-bound addition of the Hierarchy and an HHIT
registration process provide complete, global HHIT uniqueness. This registration process provide complete, global HHIT uniqueness. This
registration forces the attacker to generate the same public key registration forces the attacker to generate the same public key
rather than a public key that generates the same HHIT. This is in rather than a public key that generates the same HHIT. This is in
contrast to general IDs (e.g., a UUID or device serial number) as the contrast to general IDs (e.g., a UUID or device serial number) as the
subject in an X.509 certificate. subject in an X.509 certificate.
A UA equipped for Broadcast RID SHOULD be provisioned not only with A UA equipped for Broadcast RID MUST be provisioned not only with its
its HHIT but also with the HI public key from which the HHIT was HHIT but also with the HI public key from which the HHIT was derived
derived and the corresponding private key, to enable message and the corresponding private key, to enable message signature. A
signature. A UAS equipped for Network RID SHOULD be provisioned UAS equipped for Network RID SHOULD be provisioned likewise; the
likewise; the private key resides only in the ultimate source of private key resides only in the ultimate source of Network RID
Network RID messages (i.e., on the UA itself if the GCS is merely messages (i.e., on the UA itself if the GCS is merely relaying rather
relaying rather than sourcing Network RID messages). Each Observer than sourcing Network RID messages). Each Observer device SHOULD be
device SHOULD be provisioned either with public keys of the DRIP provisioned either with public keys of the DRIP identifier root
identifier root registries or certificates for subordinate registries or certificates for subordinate registries.
registries.
HHITs can also be used throughout the USS/UTM system. Operators and HHITs can also be used throughout the USS/UTM system. Operators and
Private Information Registries, as well as other UTM entities, can Private Information Registries, as well as other UTM entities, can
use HHITs for their IDs. Such HHITs can facilitate DRIP security use HHITs for their IDs. Such HHITs can facilitate DRIP security
functions such as used with HIP to strongly mutually authenticate and functions such as used with HIP to strongly mutually authenticate and
encrypt communications. encrypt communications.
A self-attestation of a HHIT used as a UAS ID can be done in as A self-attestation of a HHIT used as a UAS ID can be done in as
little as 84 bytes when Ed25519 [RFC8032] is used, by avoiding an little as 84 bytes when Ed25519 [RFC8032] is used, by avoiding an
explicit encoding technology like ASN.1 or Concise Binary Object explicit encoding technology like ASN.1 or Concise Binary Object
Representation (CBOR [RFC8949]). This attestation consists of only Representation (CBOR [RFC8949]). This attestation consists of only
the HHIT, a timestamp, and the EdDSA signature on them. the HHIT, a timestamp, and the EdDSA signature on them.
A DRIP identifier can be assigned to a UAS as a static HHIT by its A DRIP identifier can be assigned to a UAS as a static HHIT by its
manufacturer, such as a single HI and derived HHIT encoded as a manufacturer, such as a single HI and derived HHIT encoded as a
hardware serial number per [CTA2063A]. Such a static HHIT SHOULD hardware serial number per [CTA2063A]. Such a static HHIT SHOULD
only be used to bind one-time use DRIP identifiers to the unique UA. only be used to bind one-time use DRIP identifiers to the unique UA.
Depending upon implementation, this may leave a HI private key in the Depending upon implementation, this may leave a HI private key in the
possession of the manufacturer (more details in Section 9). possession of the manufacturer (more details in Section 8).
In general, Internet access may be needed to validate Attestations or In general, Internet access may be needed to validate Attestations or
Certificates. This may be obviated in the most common cases (e.g., Certificates. This may be obviated in the most common cases (e.g.,
attestation of the UAS ID), even in disconnected environments, by attestation of the UAS ID), even in disconnected environments, by
prepopulating small caches on Observer devices with Registry public prepopulating small caches on Observer devices with Registry public
keys and a chain of Attestations or Certificates (tracing a path keys and a chain of Attestations or Certificates (tracing a path
through the Registry tree). This is assuming all parties on the through the Registry tree). This is assuming all parties on the
trust path also use HHITs for their identities. trust path also use HHITs for their identities.
3.3. HHIT for DRIP Identifier Registration and Lookup 3.3. HHIT for DRIP Identifier Registration and Lookup
skipping to change at page 15, line 33 skipping to change at page 15, line 33
A DRIP identifier SHOULD be registered as an Internet domain name (at A DRIP identifier SHOULD be registered as an Internet domain name (at
an arbitrary level in the hierarchy, e.g., in .ip6.arpa). Thus DNS an arbitrary level in the hierarchy, e.g., in .ip6.arpa). Thus DNS
can provide all the needed public DRIP information. A standardized can provide all the needed public DRIP information. A standardized
HHIT FQDN (Fully Qualified Domain Name) can deliver the HI via a HIP HHIT FQDN (Fully Qualified Domain Name) can deliver the HI via a HIP
RR (Resource Record) [RFC8005] and other public information (e.g., RR (Resource Record) [RFC8005] and other public information (e.g.,
RRA and HDA PTRs, and HIP RVS (Rendezvous Servers) [RFC8004]). These RRA and HDA PTRs, and HIP RVS (Rendezvous Servers) [RFC8004]). These
public information registries can use secure DNS transport (e.g., DNS public information registries can use secure DNS transport (e.g., DNS
over TLS) to deliver public information that is not inherently over TLS) to deliver public information that is not inherently
trustable (e.g., everything other than attestations). trustable (e.g., everything other than attestations).
This DNS entry for the HHIT can also provide a revocation service.
For example, instead of returning the HI RR it may return some record
showing that the HI (and thus HHIT) has been revoked.
4.2. Private Information Registry 4.2. Private Information Registry
4.2.1. Background 4.2.1. Background
The private information required for DRIP identifiers is similar to The private information required for DRIP identifiers is similar to
that required for Internet domain name registration. A DRIP that required for Internet domain name registration. A DRIP
identifier solution can leverage existing Internet resources: identifier solution can leverage existing Internet resources:
registration protocols, infrastructure, and business models, by registration protocols, infrastructure, and business models, by
fitting into an UAS ID structure compatible with DNS names. The HHIT fitting into an UAS ID structure compatible with DNS names. The HHIT
hierarchy can provide the needed scalability and management hierarchy can provide the needed scalability and management
skipping to change at page 19, line 30 skipping to change at page 19, line 30
identifier to a currently usable locator (IP address); and there must identifier to a currently usable locator (IP address); and there must
be currently usable bidirectional IP (not necessarily Internet) be currently usable bidirectional IP (not necessarily Internet)
connectivity between the parties. One method directly supported by connectivity between the parties. One method directly supported by
the use of HHITs as DRIP entity identifiers is initiation of a HIP the use of HHITs as DRIP entity identifiers is initiation of a HIP
Base Exchange (BEX) and Bound End-to-End Tunnel (BEET). Base Exchange (BEX) and Bound End-to-End Tunnel (BEET).
This approach satisfies DRIP requirement GEN-6 Contact, supports This approach satisfies DRIP requirement GEN-6 Contact, supports
satisfaction of requirements [RFC9153] GEN-8, GEN-9, PRIV-2, PRIV-5 satisfaction of requirements [RFC9153] GEN-8, GEN-9, PRIV-2, PRIV-5
and REG-3, and is compatible with all other DRIP requirements. and REG-3, and is compatible with all other DRIP requirements.
8. IANA Considerations 8. Security Considerations
This document does not make any IANA request.
9. Security Considerations
The security provided by asymmetric cryptographic techniques depends The security provided by asymmetric cryptographic techniques depends
upon protection of the private keys. It may be necessary for the GCS upon protection of the private keys. It may be necessary for the GCS
to have the key pair to register the HHIT to the USS. Thus it may be to have the key pair to register the HHIT to the USS. Thus it may be
the GCS that generates the key pair and delivers it to the UA, making the GCS that generates the key pair and delivers it to the UA, making
the GCS a part of the key security boundary. Leakage of the private the GCS a part of the key security boundary. Leakage of the private
key either from the UA or GCS to the component manufacturer is a key either from the UA or GCS to the component manufacturer is a
valid concern and steps need to be in place to ensure safe keeping of valid concern and steps need to be in place to ensure safe keeping of
the private key. the private key.
skipping to change at page 20, line 11 skipping to change at page 20, line 11
impersonate a validly registered UA. This attack would only be impersonate a validly registered UA. This attack would only be
exposed when the HI in DRIP authentication message is checked back to exposed when the HI in DRIP authentication message is checked back to
the USS and found not to match. the USS and found not to match.
Finally, the UAS RID sender of a small harmless UA (or the entire UA) Finally, the UAS RID sender of a small harmless UA (or the entire UA)
could be carried by a larger dangerous UA as a "false flag." could be carried by a larger dangerous UA as a "false flag."
Compromise of a registry private key could do widespread harm. Key Compromise of a registry private key could do widespread harm. Key
revocation procedures are as yet to be determined. These risks are revocation procedures are as yet to be determined. These risks are
in addition to those involving Operator key management practices. in addition to those involving Operator key management practices.
10. Privacy & Transparency Considerations 8.1. Post Quantum Computing out of scope
There has been no effort, at this time, to address post quantum
computing cryptography. UAs and Broadcast Remote ID communications
are so constrained that current post quantum computing cryptography
is not applicable. Plus since a UA may use a unique HHIT for each
operation, the attack window could be limited to the duration of the
operation.
Finally, as the HHIT contains the ID for the cryptographic suite used
in its creation, a future post quantum computing safe algorithm that
fits the Remote ID constraints may readily be added.
9. Privacy & Transparency Considerations
Broadcast RID messages can contain Personally Identifiable Broadcast RID messages can contain Personally Identifiable
Information (PII). A viable architecture for PII protection would be Information (PII). A viable architecture for PII protection would be
symmetric encryption of the PII using a session key known to the UAS symmetric encryption of the PII using a session key known to the UAS
and its USS. Authorized Observers could obtain plaintext in either and its USS. Authorized Observers could obtain plaintext in either
of two ways. An Observer can send the UAS ID and the cyphertext to a of two ways. An Observer can send the UAS ID and the cyphertext to a
server that offers decryption as a service. An Observer can send the server that offers decryption as a service. An Observer can send the
UAS ID only to a server that returns the session key, so that UAS ID only to a server that returns the session key, so that
Observer can directly locally decrypt all cyphertext sent by that UA Observer can directly locally decrypt all cyphertext sent by that UA
during that session (UAS operation). In either case, the server can during that session (UAS operation). In either case, the server can
be: a Public Safety USS, the Observer's own USS, or the UA's USS if be: a Public Safety USS, the Observer's own USS, or the UA's USS if
the latter can be determined (which under DRIP it can be, from the the latter can be determined (which under DRIP it can be, from the
UAS ID itself). PII can be protected unless the UAS is informed UAS ID itself). PII can be protected unless the UAS is informed
otherwise. This could come as part of UTM operation authorization. otherwise. This could come as part of UTM operation authorization.
It can be special instructions at the start or during an operation. It can be special instructions at the start or during an operation.
PII protection MUST NOT be used if the UAS loses connectivity to the PII protection MUST NOT be used if the UAS loses connectivity to the
USS. The UAS always has the option to abort the operation if PII USS. The UAS always has the option to abort the operation if PII
protection is disallowed. protection is disallowed.
11. References 10. References
11.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9153] Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A. [RFC9153] Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A.
Gurtov, "Drone Remote Identification Protocol (DRIP) Gurtov, "Drone Remote Identification Protocol (DRIP)
Requirements and Terminology", RFC 9153, Requirements and Terminology", RFC 9153,
DOI 10.17487/RFC9153, February 2022, DOI 10.17487/RFC9153, February 2022,
<https://www.rfc-editor.org/info/rfc9153>. <https://www.rfc-editor.org/info/rfc9153>.
11.2. Informative References 10.2. Informative References
[CTA2063A] ANSI, "Small Unmanned Aerial Systems Serial Numbers", [CTA2063A] ANSI, "Small Unmanned Aerial Systems Serial Numbers",
2019. 2019.
[Delegated] [Delegated]
European Union Aviation Safety Agency (EASA), "EU European Union Aviation Safety Agency (EASA), "EU
Commission Delegated Regulation 2019/945 of 12 March 2019 Commission Delegated Regulation 2019/945 of 12 March 2019
on unmanned aircraft systems and on third-country on unmanned aircraft systems and on third-country
operators of unmanned aircraft systems", 2019. operators of unmanned aircraft systems", 2019,
<https://eur-lex.europa.eu/legal-content/EN/
TXT/?uri=CELEX%3A32019R0945>.
[F3411] ASTM International, "Standard Specification for Remote ID [F3411] ASTM International, "Standard Specification for Remote ID
and Tracking", February 2020, and Tracking", February 2020,
<http://www.astm.org/cgi-bin/resolver.cgi?F3411>. <http://www.astm.org/cgi-bin/resolver.cgi?F3411>.
[FAA_RID] United States Federal Aviation Administration (FAA), [FAA_RID] United States Federal Aviation Administration (FAA),
"Remote Identification of Unmanned Aircraft", 2021, "Remote Identification of Unmanned Aircraft", 2021,
<https://www.govinfo.gov/content/pkg/FR-2021-01-15/ <https://www.govinfo.gov/content/pkg/FR-2021-01-15/
pdf/2020-28948.pdf>. pdf/2020-28948.pdf>.
skipping to change at page 21, line 35 skipping to change at page 22, line 6
"Unmanned Aircraft System (UAS) Traffic Management (UTM) "Unmanned Aircraft System (UAS) Traffic Management (UTM)
Concept of Operations (V2.0)", 2020, Concept of Operations (V2.0)", 2020,
<https://www.faa.gov/uas/research_development/ <https://www.faa.gov/uas/research_development/
traffic_management/media/UTM_ConOps_v2.pdf>. traffic_management/media/UTM_ConOps_v2.pdf>.
[FS_AEUA] "Study of Further Architecture Enhancement for UAV and [FS_AEUA] "Study of Further Architecture Enhancement for UAV and
UAM", 2021, <https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/ UAM", 2021, <https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/
TSGS2_147E_Electronic_2021-10/Docs/S2-2107092.zip>. TSGS2_147E_Electronic_2021-10/Docs/S2-2107092.zip>.
[I-D.ietf-drip-auth] [I-D.ietf-drip-auth]
Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP Entity
Authentication Formats & Protocols for Broadcast Remote Tag Authentication Formats & Protocols for Broadcast
ID", Work in Progress, Internet-Draft, draft-ietf-drip- Remote ID", Work in Progress, Internet-Draft, draft-ietf-
auth-05, 7 March 2022, <https://www.ietf.org/archive/id/ drip-auth-12, 25 May 2022,
draft-ietf-drip-auth-05.txt>. <https://www.ietf.org/archive/id/draft-ietf-drip-auth-
12.txt>.
[Implementing] [Implementing]
European Union Aviation Safety Agency (EASA), "EU European Union Aviation Safety Agency (EASA), "EU
Commission Implementing Regulation 2019/947 of 24 May 2019 Commission Implementing Regulation 2019/947 of 24 May 2019
on the rules and procedures for the operation of unmanned on the rules and procedures for the operation of unmanned
aircraft", 2019. aircraft", 2019, <https://eur-lex.europa.eu/legal-
content/EN/TXT/?uri=CELEX%3A32019R0947>.
[Implementing_update]
European Union Aviation Safety Agency (EASA), "EU
COMMISSION IMPLEMENTING REGULATION (EU) 2021/664 of 22
April 2021 on a regulatory framework for the U-space",
2021, <https://eur-lex.europa.eu/legal-content/EN/
TXT/?uri=CELEX%3A32021R0664>.
[LAANC] United States Federal Aviation Administration (FAA), "Low [LAANC] United States Federal Aviation Administration (FAA), "Low
Altitude Authorization and Notification Capability", n.d., Altitude Authorization and Notification Capability", n.d.,
<https://www.faa.gov/uas/programs_partnerships/ <https://www.faa.gov/uas/programs_partnerships/
data_exchange/>. data_exchange/>.
[MAVLink] "Micro Air Vehicle Communication Protocol", 2021, [MAVLink] "Micro Air Vehicle Communication Protocol", 2021,
<http://mavlink.io/>. <http://mavlink.io/>.
[NPA] European Union Aviation Safety Agency (EASA), "Notice of
Proposed Amendment 2021-14 Development of acceptable means
of compliance and guidance material to support the U-space
regulation", 2021,
<https://www.easa.europa.eu/downloads/134303/en>.
[NPRM] United States Federal Aviation Administration (FAA), [NPRM] United States Federal Aviation Administration (FAA),
"Notice of Proposed Rule Making on Remote Identification "Notice of Proposed Rule Making on Remote Identification
of Unmanned Aircraft Systems", 2019. of Unmanned Aircraft Systems", 2019.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
 End of changes. 24 change blocks. 
46 lines changed or deleted 80 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/