idnits 2.17.1 draft-card-drip-reqs-01.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 (24 March 2020) is 1494 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DRIP S. Card 3 Internet-Draft A. Wiethuechter 4 Intended status: Informational AX Enterprize 5 Expires: 25 September 2020 R. Moskowitz 6 HTT Consulting 7 24 March 2020 9 Drone Remote Identification Protocol (DRIP) Requirements 10 draft-card-drip-reqs-01 12 Abstract 14 This document defines the requirements for Drone Remote 15 Identification Protocol (DRIP) Working Group protocols and services 16 to support Unmanned Aircraft System Remote Identification (UAS RID). 18 Objectives include: complementing external technical standards as 19 regulator-accepted means of compliance with UAS RID regulations; 20 facilitating use of existing Internet resources to support UAS RID 21 and to enable enhanced related services; and enabling verification 22 that UAS RID information is trustworthy (to some extent, even in the 23 absence of Internet connectivity at the receiving node). 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 25 September 2020. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 4 61 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. UAS RID Problem Space . . . . . . . . . . . . . . . . . . . . 8 63 3.1. Network RID . . . . . . . . . . . . . . . . . . . . . . . 8 64 3.2. Broadcast RID . . . . . . . . . . . . . . . . . . . . . . 9 65 3.3. DRIP Focus . . . . . . . . . . . . . . . . . . . . . . . 10 66 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 11 67 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 4.2. UAS Identifier . . . . . . . . . . . . . . . . . . . . . 11 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 74 8.2. Informative References . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 77 1. Introduction 79 Many safety and other considerations dictate that UAS be remotely 80 identifiable. Civil Aviation Authorities (CAAs) worldwide are 81 mandating UAS RID. The European Union Aviation Safety Agency (EASA) 82 has published [Delegated] and [Implementing] Regulations. The United 83 States (US) Federal Aviation Administration (FAA) has published a 84 Notice of Proposed Rule Making ([NPRM]). CAAs currently promulgate 85 performance-based regulations that do not specify techniques, but 86 rather cite industry consensus technical standards as acceptable 87 means of compliance. 89 ASTM International, Technical Committee F38 (UAS), Subcommittee 90 F38.02 (Aircraft Operations), Work Item WK65041, developed new ASTM 91 F3411-19 [F3411-19] Standard Specification for Remote ID and 92 Tracking. It defines 2 means of UAS RID. Network RID defines a set 93 of information for UAS to make available globally indirectly via the 94 Internet. Broadcast RID defines a set of messages for Unmanned 95 Aircraft (UA) to transmit locally directly one-way over Bluetooth or 96 Wi-Fi. Network RID depends upon Internet connectivity, in several 97 segments, from the UAS to the observer. Broadcast RID should need 98 Internet (or other Wide Area Network) connectivity only for UAS 99 registry information lookup using the directly locally received UAS 100 ID as a key. 102 [F3411-19] specifies 3 UAS ID types. Type 1 is a static, 103 manufacturer assigned, hardware serial number per ANSI/CTA-2063-A 104 "Small Unmanned Aerial System Serial Numbers" [CTA2063A]. Type 2 is 105 a CAA assigned (presumably static) ID. Type 3 is a UAS Traffic 106 Management (UTM) system assigned UUID [RFC4122], which can but need 107 not be dynamic. The EU allows only Type 1; the US allows Types 1 and 108 3, but requires Type 3 IDs (if used) each to be used only once. 109 [F3411-19] Broadcast RID transmits all information in the clear as 110 plaintext, so Type 1 static IDs enable trivial correlation of 111 patterns of use, unacceptable in many applications, e.g. package 112 delivery routes of competitors. 114 An ID is not an end in itself; it exists to enable lookups and 115 provision of services complementing mere identification. 117 Minimal specified information must be made available to the public; 118 access to other data, e.g. UAS operator Personally Identifiable 119 Information (PII), must be limited to strongly authenticated 120 personnel, properly authorized per policy. [F3411-19] specifies only 121 how to get the UAS ID to the observer; how the observer can perform 122 these lookups, and how the registries first can be populated with 123 information, is unspecified. 125 Although using UAS RID to facilitate related services, such as Detect 126 And Avoid (DAA) and other applications of Vehicle to Vehicle or 127 Vehicle to Infrastructure (V2V, V2I, collectively V2X) 128 communications, is an obvious application (explicitly contemplated in 129 the FAA NPRM), it has been omitted from [F3411-19] (explicitly 130 declared out of scope in the ASTM working group discussions based on 131 a distinction between RID as a security standard vs DAA as a safety 132 application). Although dynamic establishment of secure 133 communications between the observer and the UAS pilot seems to have 134 been contemplated by the FAA UAS ID and Tracking Aviation Rulemaking 135 Committee (ARC) in their [Recommendations], it is not addressed in 136 any of the subsequent proposed regulations or technical 137 specifications. 139 The need for near-universal deployment of UAS RID is pressing. This 140 implies the need to support use by observers of already ubiquitous 141 mobile devices (smartphones and tablets). UA onboard RID devices are 142 severely constrained in Size, Weight and Power (SWaP). Cost is a 143 significant impediment to the necessary near-universal adoption of 144 UAS send and observer receive RID capabilities. To accommodate the 145 most severely constrained cases, all these conspire to motivate 146 system design decisions, especially for the Broadcast RID data link, 147 which complicate the protocol design problem: one-way links; 148 extremely short packets; and Internet-disconnected operation of UA 149 onboard devices. Internet-disconnected operation of observer devices 150 has been deemed by ASTM F38.02 too infrequent to address, but for 151 some users is important and presents further challenges. Heavyweight 152 security protocols are infeasible, yet trustworthiness of UAS RID 153 information is essential. Under [F3411-19], even the most basic 154 datum, the UAS ID string (typically number) itself can be merely an 155 unsubstantiated claim. 157 DRIP's goal is to make RID immediately actionable, in both Internet 158 and local-only connected scenarios (especially emergencies), in 159 severely constrained UAS environments, balancing legitimate (e.g. 160 public safety) authorities' Need To Know trustworthy information with 161 UAS operators' privacy. To accomplish this, DRIP WG will liaise with 162 SDOs and complement their standards with IETF work to meet this 163 urgent need. An Applicability Statement RFC for UAS RID, showing how 164 to use IETF standardized technologies for this purpose, will be a 165 central work product. Technical Specification RFCs will address any 166 necessary enhancements of specific supporting protocols. DRIP 167 (originally called Trustworthy Multipurpose Remote Identification, 168 TM-RID) potentially could be applied to verifiably identify other 169 types of registered things reported to be in specified physical 170 locations, but the urgent motivation and clear initial focus is UAS. 171 Existing Internet resources (business models, infrastructure and 172 protocol standards) should be leveraged. A natural Internet 173 architecture for UAS RID conforming to proposed regulations and 174 external technical standards will be described in a companion DRIP 175 Architecture document; this document describes only requirements. 177 2. Terms and Definitions 179 2.1. Requirements Terminology 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 183 "OPTIONAL" in this document are to be interpreted as described in BCP 184 14 [RFC2119] [RFC8174] when, and only when, they appear in all 185 capitals, as shown here. 187 2.2. Definitions 189 $SWaP 190 Cost, Size, Weight and Power. 192 AAA 193 Attestation, Authentication, Authorization, Access Control, 194 Accounting, Attribution, Audit. 196 ABDAA 197 AirBorne DAA. Also known as "self-separation". 199 AGL 200 Above Ground Level. Relative altitude, above the variously 201 defined local ground level, typically of an UA, typically measured 202 in feet. 204 CAA 205 Civil Aviation Authority. An example is the Federal Aviation 206 Administration (FAA) in the United States of America. 208 C2 209 Command and Control. A set of organizational and technical 210 attributes and processes that employs human, physical, and 211 information resources to solve problems and accomplish missions. 212 Mainly used in military contexts. 214 DAA 215 Detect And Avoid, formerly Sense And Avoid (SAA). A means of 216 keeping aircraft "well clear" of each other for safety. 218 E2E 219 End to End. 221 GBDAA 222 Ground Based DAA. 224 GCS 225 Ground Control Station. The part of the UAS that the remote pilot 226 uses to exercise C2 over the UA, whether by remotely exercising UA 227 flight controls to fly the UA, by setting GPS waypoints, or 228 otherwise directing its flight. 230 GPS 231 Global Positioning System. In this context, misused in place of 232 Global Navigation Satellite System (GNSS) or more generally SATNAV 233 to refer generically to satellite based timing and/or positioning. 235 Limited RID 236 Per the FAA NPRM, a mode of operation that must use Network RID, 237 must not use Broadcast RID, and must provide pilot/GCS location 238 only (not UA location). This mode is only allowed for UA that 239 neither require (due to e.g. size) nor are equipped for Standard 240 RID, operated within V-LOS and within 400 feet of the pilot, below 241 400 feet AGL, etc. 243 LOS 244 Line Of Sight. An adjectival phrase describing any information 245 transfer that travels in a nearly straight line (e.g. 246 electromagnetic energy, whether in the visual light, RF or other 247 frequency range) and is subject to blockage. A term to be avoided 248 due to ambiguity, in this context, between RF-LOS and V-LOS. 250 MSL 251 Mean Sea Level. Relative altitude, above the variously defined 252 mean sea level, typically of an UA (but in FAA NPRM Limited RID 253 for a GCS), typically measured in feet. 255 NETDP 256 UAS RID Display Provider. System component that requests data 257 from one or more NETSP and aggregates them to display to a user 258 application on a device. Often an USS. 260 NETSP 261 UAS RID Service Provider. System component that compiles 262 information from various sources (and methods) in its given 263 service area. Usually an USS. 265 Observer 266 Referred to in other UAS RID documents as a "user", but there are 267 also other classes of UAS RID users, so we prefer "observer" to 268 denote an individual who has observed an UA and wishes to know 269 something about it, starting with its ID. 271 PII 272 Personally Identifiable Information. In this context, typically 273 of the UAS operator, Pilot In Command (PIC) or remote pilot, but 274 possibly of an observer or other party. 276 RF 277 Radio Frequency. May be used as an adjective or as a noun; in the 278 latter case, typically means Radio Frequency energy. 280 RF-LOS 281 RF LOS. Typically used in describing operation of a direct radio 282 link between a GCS and the UA under its control, potentially 283 subject to blockage by foliage, structures, terrain or other 284 vehicles, but less so than V-LOS. 286 Standard RID 287 Per the FAA NPRM, a mode of operation that must use both Network 288 RID (if Internet connectivity is available at the time in the 289 operating area) and Broadcast RID (always and everywhere), and 290 must provide both pilot/GCS location and UA location. This mode 291 is required for UAS that exceed the allowed envelope (e.g. size, 292 range) of Limited RID and for all UAS equipped for Standard RID 293 (even if operated within parameters that would otherwise permit 294 Limited RID). 296 UA 297 Unmanned Aircraft. Typically a military or commercial "drone" but 298 can include any and all aircraft that are unmanned. 300 UAS 301 Unmanned Aircraft System. Composed of UA, all required on-board 302 subsystems, payload, control station, other required off-board 303 subsystems, any required launch and recovery equipment, all 304 required crew members, and C2 links between UA and control 305 station. 307 UAS ID 308 Unique UAS identifier. Per [F3411-19], maximum length of 20 309 bytes. 311 UAS ID Type 312 Identifier type index. Per [F3411-19], 4 bits, values 0-3 already 313 specified. 315 UAS RID 316 UAS Remote Identification. System for identifying UA during 317 flight by other parties. 319 UAS RID Verification Service 320 System component designed to handle the authentication 321 requirements of RID by offloading verification to a web hosted 322 service. 324 USS 325 UAS Service Supplier. Provide UTM services to support the UAS 326 community, to connect Operators and other entities to enable 327 information flow across the USS network, and to promote shared 328 situational awareness among UTM participants. (From FAA UTM 329 ConOps V1, May 2018). 331 UTM 332 UAS Traffic Management. A "traffic management" ecosystem for 333 "uncontrolled" UAS operations separate from, but complementary to, 334 the FAA's Air Traffic Management (ATM) system for "controlled" 335 operations of manned aircraft. 337 V-LOS 338 Visual LOS. Typically used in describing operation of an UA by a 339 "remote" pilot who can clearly directly (without video cameras or 340 any other aids other than glasses or under some rules binoculars) 341 see the UA and its immediate flight environment. Potentially 342 subject to blockage by foliage, structures, terrain or other 343 vehicles, more so than RF-LOS. 345 3. UAS RID Problem Space 347 UA may be fixed wing Short Take-Off and Landing (STOL), rotary wing 348 (e.g. helicopter) Vertical Take-Off and Landing (VTOL), or hybrid. 349 They may be single engine or multi engine. The most common today are 350 multicopters: rotary wing, multi engine. The explosion in UAS was 351 enabled by hobbyist development, for multicopters, of advanced flight 352 stability algorithms, enabling even inexperienced pilots to take off, 353 fly to a location of interest, hover, and return to the take-off 354 location or land at a distance. UAS can be remotely piloted by a 355 human (e.g. with a joystick) or programmed to proceed from Global 356 Positioning System (GPS) waypoint to waypoint in a weak form of 357 autonomy; stronger autonomy is coming. UA are "low observable": they 358 typically have a small radar cross section; they make noise quite 359 noticeable at short range but difficult to detect at distances they 360 can quickly close (500 meters in under 17 seconds at 60 knots); they 361 typically fly at low altitudes (for the small UAS to which RID 362 applies in the US, under 400 feet AGL); they are highly maneuverable 363 so can fly under trees and between buildings. 365 UA can carry payloads including sensors, cyber and kinetic weapons, 366 or can be used themselves as weapons by flying them into targets. 367 They can be flown by clueless, careless or criminal operators. Thus 368 the most basic function of UAS RID is "Identification Friend or Foe" 369 (IFF) to mitigate the significant threat they present. Numerous 370 other applications can be enabled or facilitated by RID: consider the 371 importance of identifiers in many Internet protocols and services. 373 Network RID from the UA itself (rather than from its GCS) and 374 Broadcast RID require one or more wireless data links from the UA, 375 but such communications are challenging due to $SWaP constraints and 376 low altitude flight amidst structures and foliage over terrain. 378 3.1. Network RID 380 Network RID has several variants. The UA may have persistent onboard 381 Internet connectivity, in which case it can consistently source RID 382 information directly over the Internet. The UA may have intermittent 383 onboard Internet connectivity, in which case the GCS must source RID 384 information whenever the UA itself is offline. The UA may not have 385 Internet connectivity of its own, but have instead some other form of 386 communications to another node that can relay RID information to the 387 Internet; this would typically be the GCS (which to perform its 388 function must know where the UA is). The UA may have no means of 389 sourcing RID information, in which case the GCS must source it; this 390 is typical in FAA NPRM Limited RID, which only needs to provide the 391 location of the GCS (not that of the UA). In the extreme case, this 392 could be the pilot using a web browser to designate, to an UAS 393 Service Supplier (USS) or other UTM entity, a time-bounded airspace 394 volume in which an operation will be conducted; this may impede 395 disambiguation of ID if multiple UAS operate in the same or 396 overlapping spatio-temporal volumes. 398 In most cases in the near term, if the RID information is fed to the 399 Internet directly by the UA or GCS, the first hop data links will be 400 cellular Long Term Evolution (LTE) or WiFi, but provided the data 401 link can support at least IP and ideally TCP, its type is generally 402 immaterial to the higher layer protocols. An UAS or other ultimate 403 source of Network RID information feeds an USS acting as a Network 404 RID Service Provider (NETSP), which essentially proxies for that and 405 other sources; an observer or other ultimate consumer of Network RID 406 information obtains it from a Network RID Display Provider (NETDP), 407 which aggregates information from multiple NETSPs to offer coverage 408 of an airspace volume of interest. 410 Network RID is the more flexible and less constrained of the defined 411 UAS RID means, but is only partially specified in [F3411-19]. It is 412 presumed that IETF efforts supporting Broadcast RID (see next 413 section) can be easily generalized for Network RID. 415 3.2. Broadcast RID 417 [F3411-19] specifies 3 Broadcast RID data links: Bluetooth 4.X; 418 Bluetooth 5.X Long Range; and WiFi with Neighbor Awareness Networking 419 (NAN). For compliance with this standard, an UA must broadcast 420 (using advertisement mechanisms where no other option supports 421 broadcast) on at least one of these; if broadcasting on Bluetooth 422 5.x, it is also required concurrently to do so on 4.x (referred to in 423 [F3411-19] as Bluetooth Legacy). 425 The selection of the Broadcast media was driven by research into what 426 is commonly available on 'ground' units (smartphones and tablets) and 427 what was found as prevalent or 'affordable' in UA. Further, there 428 must be an Application Programming Interface (API) for the observer's 429 receiving application to have access to these messages. As yet only 430 Bluetooth 4.X support is readily available, thus the current focus is 431 on working within the 26 byte limit of the Bluetooth 4.X "Broadcast 432 Frame" transmitted on beacon channels. 434 Finally, the 26 byte limit of the Bluetooth 4.1 "Broadcast Frame", 435 after nominal overheads, limits the UAS ID string to a maximum length 436 of 20 bytes. 438 3.3. DRIP Focus 440 DRIP WG will focus on making information obtained via UAS RID 441 immediately usable: 443 1. first by making it trustworthy (despite the severe constraints of 444 Broadcast RID); 446 2. second by enabling verification that an UAS is registered, and if 447 so, in which registry (for classification of trusted operators on 448 the basis of known registry vetting, even by observers lacking 449 Internet connectivity at observation time); 451 3. third by enabling instant establishment, by authorized parties, 452 of secure communications with the remote pilot. 454 Any UA can assert any ID using the [F3411-19] required Basic ID 455 message, which lacks any provisions for verification. The Position/ 456 Vector message likewise lacks provisions for verification, and does 457 not contain the ID, so must be correlated somehow with a Basic ID 458 message: the developers of [F3411-19] have suggested using the MAC 459 addresses, but these may be randomized by the operating system stack 460 to avoid the adversarial correlation problems of static identifiers. 461 The [F3411-19] optional Authentication Message specifies framing for 462 authentication data, but does not specify any authentication method, 463 and the maximum length of the specified framing is too short for 464 conventional digital signatures, much less certificates. The one-way 465 nature of Broadcast RID precludes challenge-response security 466 protocols (e.g. observers sending nonces to UA, to be returned in 467 signed messages). An observer would be seriously challenged to 468 validate the asserted UAS ID or any other information about the UAS 469 or its operator looked up therefrom. 471 Further, [F3411-19] provides very limited choices for an observer to 472 communicate with the pilot, e.g. to request further information on 473 the UAS operation or exit from an airspace volume in an emergency. 474 An observer could physically go to the asserted GCS location to look 475 for the remote pilot. An observer with Internet connectivity could 476 look up operator PII in a registry, then call a phone number in hopes 477 someone who can immediately influence the UAS operation will answer 478 promptly during that operation. 480 Thus complementing [F3411-19] with protocols enabling strong 481 authentication, preserving operator privacy while enabling immediate 482 use of information by authorized parties, is critical to achieve 483 widespread adoption of a RID system supporting safe and secure 484 operation of UAS. 486 4. Requirements 488 4.1. General 490 The general DRIP requirements are to: 492 1. verify that messages originated from the claimed sender; 494 2. verify that the UAS ID is in a registry and identify which one; 496 3. lookup, from the UAS ID, public information; 498 4. lookup, with AAA, private information, per policy; 500 5. structure information for both human and machine readability; 502 6. provision registries with static information on the UAS and its 503 operator, dynamic information on its current operation within the 504 UTM, and Internet direct contact information for services related 505 to the foregoing; 507 7. close the AAA-policy registry loop by governing AAA per 508 registered policies and administering policies only via AAA; 510 8. dynamically establish, with AAA, per policy, E2E strongly 511 encrypted communications with the UAS RID sender and entities 512 looked up from the UAS ID, including the remote pilot and USS. 514 It is highly desirable that Broadcast RID receivers be able to stamp 515 messages with accurate date/time received and receiver location, then 516 relay them to a network service (e.g. distributed ledger), inter alia 517 for correlation to assess sender and receiver veracity. 519 4.2. UAS Identifier 521 A DRIP UAS ID MUST be: 523 1. 20 bytes or smaller; 525 2. sufficient to identify a registry in which the UAS is listed; 527 3. sufficient to enable lookup of other data in that registry; 529 4. unique within a to-be-defined scope; 530 5. non-spoofable within the context of Remote ID broadcast messages 531 (some collection of messages provides proof of UA ownership of 532 ID). 534 A DRIP UAS ID MUST NOT facilitate adversarial correlation of UAS 535 operational patterns; this may be accomplished e.g. by limiting each 536 identifier to a single use, but if so, the UAS ID MUST support 537 defined scalable timely registration methods. 539 Mechanisms standardized in DRIP WG MUST be capable of proving 540 ownership of a claimed UAS ID, and SHOULD be capable of doing so 541 immediately on an observer device lacking Internet connectivity at 542 the time of observation. 544 Mechanisms standardized in DRIP WG MUST be capable of verifying that 545 messages claiming to have been sent from a UAS with a given UAS ID 546 indeed came from the claimed sender. 548 5. IANA Considerations 550 It is likely that an IPv6 prefix or other namespace will be needed; 551 this will be specified in other documents. 553 6. Security Considerations 555 DRIP is all about safety and security, so content pertaining to such 556 is not limited to this section. DRIP information must be divided 557 into 2 classes: that which, to achieve the purpose, must be published 558 openly in clear plaintext, for the benefit of any observer; and that 559 which must be protected (e.g. PII of pilots) but made available to 560 properly authorized parties (e.g. public safety personnel who 561 urgently need to contact pilots in emergencies). Details of the 562 protection mechanisms will be provided in other documents. 563 Classifying the information will be addressed primarily in external 564 standards; herein it will be regarded as a matter for CAA, registry 565 and operator policies, for which enforcement mechanisms will be 566 defined within the scope of DRIP WG and offered. Mitigation of 567 adversarial correlation will also be addressed. 569 7. Acknowledgments 571 The work of the FAA's UAS Identification and Tracking (UAS ID) 572 Aviation Rulemaking Committee (ARC) is the foundation of later ASTM 573 [F3411-19] and IETF DRIP WG efforts. The work of ASTM F38.02 in 574 balancing the interests of diverse stakeholders is essential to the 575 necessary rapid and widespread deployment of UAS RID. 577 8. References 578 8.1. Normative References 580 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 581 Requirement Levels", BCP 14, RFC 2119, 582 DOI 10.17487/RFC2119, March 1997, 583 . 585 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 586 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 587 May 2017, . 589 8.2. Informative References 591 [CTA2063A] ANSI, "Small Unmanned Aerial Systems Serial Numbers", 592 September 2019. 594 [Delegated] 595 European Union Aviation Safety Agency (EASA), "Commission 596 Delegated Regulation (EU) 2019/945 of 12 March 2019 on 597 unmanned aircraft systems and on third-country operators 598 of unmanned aircraft systems", March 2019. 600 [F3411-19] ASTM, "Standard Specification for Remote ID and Tracking", 601 December 2019. 603 [Implementing] 604 European Union Aviation Safety Agency (EASA), "Commission 605 Implementing Regulation (EU) 2019/947 of 24 May 2019 on 606 the rules and procedures for the operation of unmanned 607 aircraft", May 2019. 609 [NPRM] United States Federal Aviation Administration (FAA), 610 "Notice of Proposed Rule Making on Remote Identification 611 of Unmanned Aircraft Systems", December 2019. 613 [Recommendations] 614 FAA UAS Identification and Tracking Aviation Rulemaking 615 Committee, "UAS ID and Tracking ARC Recommendations Final 616 Report", September 2017. 618 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 619 Unique IDentifier (UUID) URN Namespace", RFC 4122, 620 DOI 10.17487/RFC4122, July 2005, 621 . 623 Authors' Addresses 624 Stuart W. Card 625 AX Enterprize 626 4947 Commercial Drive 627 Yorkville, NY 13495 628 United States of America 630 Email: stu.card@axenterprize.com 632 Adam Wiethuechter 633 AX Enterprize 634 4947 Commercial Drive 635 Yorkville, NY 13495 636 United States of America 638 Email: adam.wiethuechter@axenterprize.com 640 Robert Moskowitz 641 HTT Consulting 642 Oak Park, MI 48237 643 United States of America 645 Email: rgm@labs.htt-consult.com