idnits 2.17.1 draft-card-tmrid-uas-arch-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (6 February 2020) is 1541 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7484 (Obsoleted by RFC 9224) == Outdated reference: A later version (-05) exists of draft-moskowitz-hip-hierarchical-hit-03 == Outdated reference: A later version (-10) exists of draft-moskowitz-hip-new-crypto-04 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TMRID S. Card 3 Internet-Draft A. Wiethuechter 4 Intended status: Informational AX Enterprize 5 Expires: 9 August 2020 R. Moskowitz 6 HTT Consulting 7 6 February 2020 9 Unmanned Aircraft System Remote Identification Architecture 10 draft-card-tmrid-uas-arch-00 12 Abstract 14 This document defines an architecture for Trustworthy Multipurpose 15 Remote Identification (tm-rid) protocols and services to support 16 Unmanned Aircraft System Remote Identification (UAS RID), including 17 its building blocks and their interfaces, all to be standardized. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 9 August 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 54 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 4 55 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Entities and their Interfaces . . . . . . . . . . . . . . . . 8 57 3.1. Private Information Registry . . . . . . . . . . . . . . 8 58 3.2. Public Information Registry . . . . . . . . . . . . . . . 9 59 3.3. CS-RID SDSP . . . . . . . . . . . . . . . . . . . . . . . 9 60 3.4. CS-RID Finder . . . . . . . . . . . . . . . . . . . . . . 9 61 4. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 5. Transactions . . . . . . . . . . . . . . . . . . . . . . . . 10 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 65 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 68 9.2. Informative References . . . . . . . . . . . . . . . . . 12 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 71 1. Introduction 73 Many safety and other considerations dictate that UAS be remotely 74 identifiable. Civil Aviation Authorities (CAAs) worldwide are 75 mandating UAS RID. The European Union Aviation Safety Agency (EASA) 76 has published Commision Delegated Regulation 2019/945 and Commission 77 Implementing Regulation 2019/947. The United States (US) Federal 78 Aviation Administration (FAA) has published a Notice of Proposed Rule 79 Making (NPRM). CAAs currently promulgate performance-based 80 regulations that do not specify techniques, but rather cite industry 81 consensus technical standards as acceptable means of compliance. 83 ASTM International, Technical Committee F38 (UAS), Subcommittee 84 F38.02 (Aircraft Operations), Work Item WK65041 (UAS Remote ID and 85 Tracking), is a Proposed New Standard [WK65041]. It defines 2 means 86 of UAS RID. Network RID defines a set of information for UAS to make 87 available globally indirectly via the Internet. Broadcast RID 88 defines a set of messages for Unmanned Aircraft (UA) to transmit 89 locally directly one-way over Bluetooth or Wi-Fi. Network RID 90 depends upon Internet connectivity, in several segments, from the UAS 91 to the observer. Broadcast RID should need Internet (or other Wide 92 Area Network) connectivity only for UAS registry information lookup 93 using the directly locally received UAS ID as a key. 95 [WK65041] specifies 3 UAS ID types. Type 1 is a static, manufacturer 96 assigned, hardware serial number per ANSI/CTA-2063-A "Small Unmanned 97 Aerial System Serial Numbers" [CTA2063A]. Type 2 is a CAA assigned 98 (presumably static) ID. Type 3 is a UAS Traffic Management (UTM) 99 system assigned UUID [RFC4122], which can but need not be dynamic. 100 The EU allows only Type 1; the US allows Types 1 and 3, but requires 101 Type 3 IDs (if used) each to be used only once. [WK65041] Broadcast 102 RID transmits all information in the clear as plaintext, so Type 1 103 static IDs enable trivial correlation of patterns of use, 104 unacceptable in many applications, e.g. package delivery routes of 105 competitors. 107 An ID is not an end in itself; it exists to enable lookups and 108 provision of services complementing mere identification. 110 Minimal specified information must be made available to the public; 111 access to other data, e.g. UAS operator Personally Identifiable 112 Information (PII), must be limited to strongly authenticated 113 personnel, properly authorized per policy. [WK65041] specifies only 114 how to get the UAS ID to the observer; how the observer can perform 115 these lookups, and how the registries first can be populated with 116 information, is unspecified. 118 Although using UAS RID to facilitate related services, such as Detect 119 And Avoid (DAA) and other applications of Vehicle to Vehicle or 120 Vehicle to Infrastructure (V2V, V2I, collectively V2X) 121 communications, is an obvious application (explicitly contemplated in 122 the FAA NPRM), it has been ommitted from [WK65041] (explicitly 123 declared out of scope in the ASTM working group discussions based on 124 a distinction between RID as a security standard vs DAA as a safety 125 application). Although dynamic establishment of secure 126 communications between the observer and the UAS pilot seems to have 127 been contemplated by the FAA Aviation Rulemaking Committee (ARC), it 128 is not addressed in any of the subsequent proposed regulations or 129 technical specifications. 131 The need for near-universal deployment of UAS RID is pressing. This 132 implies the need to support use by observers of already ubiquitous 133 mobile devices (smartphones and tablets). UA onboard RID devices are 134 severely constrained in Size, Weight and Power (SWaP). Cost is a 135 significant impediment to the necessary near-universal adoption of 136 UAS send and observer receive RID capabilities. To accomodate the 137 most severely constrained cases, all these conspire to motivate 138 system design decisions, especially for the Broadcast RID data link, 139 which complicate the protocol design problem: one-way links; 140 extremely short packets; and Internet-disconnected operation of UA 141 onboard devices. Internet-disconnected operation of observer devices 142 has been deemed by ASTM F38.02 too infrequent to address, but for 143 some users is important and presents further challenges. Heavyweight 144 security protocols are infeasible, yet trustworthiness of UAS RID 145 information is essential. Under [WK65041], even the most basic 146 datum, the UAS ID string (typically number) itself can be merely an 147 unsubstantiated claim. 149 IETF can help by providing expertise as well as mature and evolving 150 standards. Existing Internet resources (business models, 151 infrastructure and protocol standards) should be leveraged. Host 152 Identity Protocol (HIPv2) [RFC7401] and its Domain Name System (DNS) 153 extensions [RFC8005], together with the Registry Data Access Protocl 154 (RDAP) and the Extensible Provisioning Protocol (EPP), can complement 155 emerging external standards for UAS RID. This will facilitate 156 utilization of existing and provision of enhanced network services, 157 and enable verification that UAS RID information is trustworthy (to 158 some extent, even in the absence of Internet connectivity at the 159 receiving node). The natural Internet architecture for UAS RID 160 described herein addresses requirements defined in a companion UAS 161 RID Requirements document. 163 2. Terms and Definitions 165 2.1. Requirements Terminology 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 169 "OPTIONAL" in this document are to be interpreted as described in BCP 170 14 [RFC2119] [RFC8174] when, and only when, they appear in all 171 capitals, as shown here. 173 2.2. Definitions 175 $SWaP 176 Cost, Size, Weight and Power. 178 AAA 179 Attestation, Authentication, Authorization, Access Control, 180 Accounting, Attribution, Audit. 182 ABDAA 183 AirBorne DAA. Also known as "self-separation". 185 AGL 186 Above Ground Level. Relative altitude, above the variously 187 defined local ground level, typically of an UA, typically measured 188 in feet. 190 CAA 191 Civil Aviation Authority. An example is the Federal Aviation 192 Administration (FAA) in the United States of America. 194 C2 195 Command and Control. A set of organizational and technical 196 attributes and processes that employs human, physical, and 197 information resources to solve problems and accomplish missions. 198 Mainly used in military contexts. 200 CS-RID 201 Crowd Sourced Remote Identification. An optional TM-RID service 202 that gateways Broadcast RID to Network RID, and supports 203 verification of RID positon/velocity claims with independent 204 measurements (e.g. by multilateration), via a SDSP. 206 DAA 207 Detect And Avoid, formerly Sense And Avoid (SAA). A means of 208 keeping aircraft "well clear" of each other for safety. 210 E2E 211 End to End. 213 GBDAA 214 Ground Based DAA. 216 GCS 217 Ground Control Station. The part of the UAS that the remote pilot 218 uses to exercise C2 over the UA, whether by remotely exercising UA 219 flight controls to fly the UA, by setting GPS waypoints, or 220 otherwise directing its flight. 222 GPS 223 Global Positioning System. In this context, misused in place of 224 Global Navigation Satellite System (GNSS) or more generally SATNAV 225 to refer generically to satellite based timing and/or positioning. 227 HI 228 Host Identity. The public key portion of an asymmetric keypair 229 from HIP. In this document it is assumed that the HI is based on 230 a EdDSA25519 keypair. This is supported by new crypto defined in 231 [I-D.moskowitz-hip-new-crypto]. 233 HIP 234 Host Identity Protocol. The origin of HI, HIT, and HHIT, required 235 for TM-RID. Optional full use of HIP enables additional TM-RID 236 functionality. 238 HHIT 239 Hierarchical Host Identity Tag. A HIT with extra information not 240 found in a standard HIT. Defined in 241 [I-D.moskowitz-hip-hierarchical-hit]. 243 HIT 244 Host Identity Tag. A 128 bit handle on the HI. Defined in HIPv2 245 [RFC7401]. 247 Limited RID 248 Per the FAA NPRM, a mode of operation that must use Network RID, 249 must not use Broadcast RID, and must provide pilot/GCS location 250 only (not UA location). This mode is only allowed for UA that 251 neither require (due to e.g. size) nor are equipped for Standard 252 RID, operated within V-LOS and within 400 feet of the pilor, below 253 400 feet AGL, etc. 255 LOS 256 Line Of Sight. An adjectival phrase describing any information 257 transfer that travels in a nearly straight line (e.g. 258 electromagnetic energy, whether in the visual light, RF or other 259 frequency range) and is subject to blockage. A term to be avoided 260 due to ambiguity, in this context, between RF-LOS and V-LOS. 262 MSL 263 Mean Sea Level. Relative altitude, above the variously defined 264 mean sea level, typically of an UA (but in FAA NPRM Limited RID 265 for a GCS), typically measured in feet. 267 NETDP 268 UAS RID Display Provider. System component that requests data 269 from one or more NETSP and aggregates them to display to a user 270 application on a device. Often an USS. 272 NETSP 273 UAS RID Service Provider. System component that compiles 274 information from various sources (and methods) in its given 275 service area. Usually an USS. 277 Observer 278 Referred to in other UAS RID documents as a "user", but there are 279 also other classes of UAS RID users, so we prefer "observer" to 280 denote an individual who has observed an UA and wishes to know 281 something about it, starting with its ID. 283 PII 284 Personally Identifiable Information. In this context, typically 285 of the UAS operator, Pilot In Command (PIC) or remote pilot, but 286 possibly of an observer or other party. 288 RF 289 Radio Frequency. May be used as an adjective or as a noun; in the 290 latter case, typically means Radio Frequency energy. 292 RF-LOS 293 RF LOS. Typically used in describing operation of a direct radio 294 link between a GCS and the UA under its control, potentially 295 subject to blockage by foliage, structures, terrain or other 296 vehicles, but less so than V-LOS. 298 SDSP 299 Supplemental Data Service Provider. Entity that provides data 300 allowed and presumed useful but neither required nor standardized 301 as an option in UTM, such as weather. Here used to enable CS-RID. 303 Standard RID 304 Per the FAA NPRM, a mode of operation that must use both Network 305 RID (if Internet connectivity is available at the time in the 306 operating area) and Broadcast RID (always and everywhere), and 307 must provide both pilot/GCS location and UA location. This mode 308 is required for UAS that exceed the allowed envelope (e.g. size, 309 range) of Limited RID and for all UAS equipped for Standard RID 310 (even if operated within parameters that would otherwise permit 311 Limited RID). 313 UA 314 Unmanned Aircraft. Typically a military or commercial "drone" but 315 can include any and all aircraft that are unmanned. 317 UAS 318 Unmanned Aircraft System. Composed of UA, all required on-board 319 subsystems, payload, control station, other required off-board 320 subsystems, any required launch and recovery equipment, all 321 required crew members, and C2 links between UA and control 322 station. 324 UAS ID 325 Unique UAS identifier. Per [WK65041], maximum length of 20 bytes. 327 UAS ID Type 328 Identifier type index. Per [WK65041], 4 bits, values 0-3 already 329 specified. 331 UAS RID 332 UAS Remote Identification. System for identifying UA during 333 flight by other parties. 335 UAS RID Verification Service 336 System component designed to handle the authentication 337 requirements of RID by offloading verification to a web hosted 338 service. 340 USS 341 UAS Service Supplier. Provide UTM services to support the UAS 342 community, to connect Operators and other entities to enable 343 information flow across the USS network, and to promote shared 344 situational awareness among UTM participants. (From FAA UTM 345 ConOps V1, May 2018). 347 UTM 348 UAS Traffic Management. A "traffic management" ecosystem for 349 "uncontrolled" UAS operations separate from, but complementary to, 350 the FAA's Air Traffic Management (ATM) system for "controlled" 351 operations of manned aircraft. 353 V-LOS 354 Visual LOS. Typically used in describing operation of an UA by a 355 "remote" pilot who can clearly directly (without video cameras or 356 any other aids other than glasses or under some rules binoculars) 357 see the UA and its immediate flight environment. Potentially 358 subject to blockage by foliage, structures, terrain or other 359 vehicles, more so than RF-LOS. 361 3. Entities and their Interfaces 363 Any tm-rid solutions for UAS RID must fit into the UTM system. This 364 implies interaction with entities including UA, GCS, USS, NETSP, 365 NETDP, Observers, Operators, Pilots In Command, Remote Pilots, etc. 366 The only additional entities introduced by tm-rid are registries, 367 required but not specified by the regulations and [RFC7401], and 368 optionally CS-RID SDSP and Finder nodes. 370 UAS RID registries hold both public and private information. The 371 public information is primarily pointers to the repositories of, and 372 keys for looking up, the private information. Given these different 373 uses, and to improve scalability, security and simplicity of 374 administration, the public and private information can be stored in 375 different registries, indeed different types of registry. 377 3.1. Private Information Registry 379 The private information required for UAS RID is similar to that 380 required for Internet domain name registration. This facilitates 381 leveraging existing Internet resources, including domain name 382 registration protocols, infrastructure and business models. This 383 implies a further derived requirement: a tm-rid UAS ID MUST be 384 amenable to handling as an Internet domain name (at an arbitrary 385 level in the heirarchy), MUST be registered in at least a pseudo- 386 domain (e.g. .ip6 for reverse lookup), and MAY be registered as a 387 sub-domain (for forward lookup). 389 A tm-rid private information registry MUST support essential Internet 390 domain name registry operations (e.g. add, delete, update, query) 391 using interoperable open standard protocols. It SHOULD support the 392 Extensible Provisioning Protocol (EPP) and the Registry Data Access 393 Protocol (RDAP) with access controls. It MAY use XACML to specify 394 those access controls. It MUST be listed in a DNS: that DNS MAY be 395 private; but absent any compelling reasons for use of private DNS, 396 SHOULD be the definitive public Internet DNS heirarchy. The tm-rid 397 private information registry in which a given UAS is registered MUST 398 be locatable, starting from the UAS ID, using the methods specified 399 in [RFC7484]. 401 3.2. Public Information Registry 403 The public information required to be made available by UAS RID is 404 transmitted as clear plaintext to local observers in Broadcast RID 405 and is served to a client by a NETDP in Network RID. Therefore, 406 while IETF can offer e.g. [RFC6280] as one way to implement Network 407 RID, the only public information required to support essential tm-rid 408 functions for UAS RID is that required to look up Internet domain 409 hosts, services, etc. 411 A tm-rid public information registry MUST be a standard DNS server, 412 in the definitive public Internet DNS heirarchy. It MUST support NS, 413 MX, SRV, TXT, AAAA, PTR, CNAME and HIP RR types. 415 3.3. CS-RID SDSP 417 A CS-RID SDSP MUST appear (i.e. present the same interface) to a 418 NETSP as a NETDP. A CS-RID SDSP MUST appear to a NETDP as a NETSP. 419 A CS-RID SDSP MUST NOT present a standard GCS-facing interface as if 420 it were a NETSP. A CS-RID SDSP MUST NOT present a standard client- 421 facing interface as if it were a NETDP. A CS-RID SDSP MUST present a 422 TBD interface to a CS-RID Finder; this interface SHOULD be based upon 423 but readily distinguishable from that between a GCS and a NETSP. 425 3.4. CS-RID Finder 427 A CS-RID Finder MUST present a TBD interface to a CS-RID SDSP; this 428 interface SHOULD be based upon but readily distinguishable from that 429 between a GCS and a NETSP. A CS-RID Finder must implement, integrate 430 or accept outputs from a Broadcast RID receiver. A CS-RID Finder 431 MUST NOT interface directly with a GCS, NETSP, NETDP or Network RID 432 client. 434 4. Identifiers 436 A tm-rid UAS ID MUST be a HHIT. It SHOULD be self-generated by the 437 UAS (either UA or GCS) and MUST be registered with the Private 438 Information Registry identified in its heirarchy fields. Each UAS ID 439 HHIT MUST NOT be used more than once, with one exception as follows. 441 Each UA MAY be assigned, by its manufacturer, a single HI and derived 442 HHIT encoded as a hardware serial number per [CTA2063A]. Such a 443 static HHIT SHOULD be used only to bind one-time use UAS IDs (other 444 HHITs) to the unique UA. Depending upon implementation, this may 445 leave a HI private key in the posession of the manufacturer (see 446 Security Considerations). 448 Each UA equipped for Broadcast RID MUST be provisioned not only with 449 its HHIT but also with the HI public key from which the HHIT was 450 derived and the corresponding private key, to enable message 451 signature. Each UAS equipped for Network RID MUST be provisioned 452 likewise; the private key SHOULD reside only in the ultimate source 453 of Network RID messages (i.e. on the UA itself if the GCS is merely 454 relaying rather than sourcing Network RID messages). Each observer 455 device MUST be provisioned with public keys of the UAS RID root 456 registries and MAY be provisioned with public keys or certificates 457 for subordinate registries. 459 Operators and Private Information Registries MUST possess and other 460 UTM entities MAY possess UAS ID style HHITs. When present, such 461 HHITs SHOULD be used with HIP to strongly mutually authenticate and 462 optionally encrypt communications. 464 5. Transactions 466 Each Operator MUST generate a "HIo" and derived "HHITo", register 467 them with a Private Information Registry along with whatever Operator 468 data (inc. PII) is required by the cognizant CAA and the registry, 469 and obtain a certificate "Cro" signed with "HIr(priv)" proving such 470 registration. 472 To add an UA, an Operator MUST generate a "HIa" and derived "HHITa", 473 create a certificate "Coa" signed with "HIo(priv)" to associate the 474 UA with its Operator, register them with a Private Information 475 Registry along with whatever UAS data is required by the cognizant 476 CAA and the registry, obtain a certificate "Croa" signed with 477 "HIr(priv)" proving such registration, and obtain a certificate "Cra" 478 signed with "HIr(priv)" proving UA registration in that specific 479 registry while preserving Operator privacy. The operator then MUST 480 provision the UA with "HIa", "HIa(priv)", "HHITa" and "Cra". 482 UA engaging in Broadcast RID MUST use "HIa(priv)" to sign Auth 483 Messages and MUST periodically broadcast "Cra". UAS engaging in 484 Network RID MUST use "HIa(priv)" to sign Auth Messages. Observers 485 MUST use "HIa" from received "Cra" to verify received Broadcast RID 486 Auth messages. Observers without Internet connectivity MAY use "Cra" 487 to identify the trust class of the UAS based on known registry 488 vetting. Observers with Internet connectivity MAY use "HHITa" to 489 perform lookups in the Public Information Registry and MAY then query 490 the Private Information Registry, which MUST enforce access control 491 policy on Operator PII and other sensitive information. 493 6. IANA Considerations 495 It is likely that an IPv6 prefix will be needed for the HHIT (or 496 other identifier) space; this will be specified in other drafts. 498 7. Security Considerations 500 UAS RID is all about safety and security, so content pertaining to 501 such is not limited to this section. The security provided by 502 asymmetric cryptographic techniques depends upon protection of the 503 private keys. A manufacturer that embeds a private key in an UA may 504 have retained a copy. A manufacturer whose UA are configured by a 505 closed source application on the GCS which communicates over the 506 Internet with the factory may be sending a copy of a UA or GCS self- 507 generated key back to the factory. Compromise of a registry private 508 key could do widespread harm. Key revocation procedures are as yet 509 to be determined. These risks are in addition to those involving 510 Operator key management practices. 512 8. Acknowledgments 514 The work of the FAA's UAS Identification and Tracking (UAS ID) 515 Aviation Rulemaking Committee (ARC) is the foundation of later ASTM 516 and proposed IETF efforts. The work of ASTM F38.02 in balancing the 517 interests of diverse stakeholders is essential to the necessary rapid 518 and widespread deployment of UAS RID. 520 9. References 522 9.1. Normative References 524 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 525 Requirement Levels", BCP 14, RFC 2119, 526 DOI 10.17487/RFC2119, March 1997, 527 . 529 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 530 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 531 RFC 7401, DOI 10.17487/RFC7401, April 2015, 532 . 534 [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data 535 (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March 536 2015, . 538 [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name 539 System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, 540 October 2016, . 542 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 543 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 544 May 2017, . 546 9.2. Informative References 548 [CTA2063A] ANSI, "Small Unmanned Aerial Systems Serial Numbers", 549 September 2019. 551 [I-D.moskowitz-hip-hierarchical-hit] 552 Moskowitz, R., Card, S., and A. Wiethuechter, 553 "Hierarchical HITs for HIPv2", Work in Progress, Internet- 554 Draft, draft-moskowitz-hip-hierarchical-hit-03, 16 555 December 2019, . 558 [I-D.moskowitz-hip-new-crypto] 559 Moskowitz, R., Card, S., and A. Wiethuechter, "New 560 Cryptographic Algorithms for HIP", Work in Progress, 561 Internet-Draft, draft-moskowitz-hip-new-crypto-04, 23 562 January 2020, . 565 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 566 Unique IDentifier (UUID) URN Namespace", RFC 4122, 567 DOI 10.17487/RFC4122, July 2005, 568 . 570 [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., 571 Tschofenig, H., and H. Schulzrinne, "An Architecture for 572 Location and Location Privacy in Internet Applications", 573 BCP 160, RFC 6280, DOI 10.17487/RFC6280, July 2011, 574 . 576 [WK65041] ASTM, "Standard Specification for Remote ID and Tracking", 577 September 2019. 579 Authors' Addresses 581 Stuart W. Card 582 AX Enterprize 583 4947 Commercial Drive 584 Yorkville, NY 13495 585 United States of America 587 Email: stu.card@axenterprize.com 589 Adam Wiethuechter 590 AX Enterprize 591 4947 Commercial Drive 592 Yorkville, NY 13495 593 United States of America 595 Email: adam.wiethuechter@axenterprize.com 597 Robert Moskowitz 598 HTT Consulting 599 Oak Park, MI 48237 600 United States of America 602 Email: rgm@labs.htt-consult.com