Subject: [Drip] attached: my highlights from & comments on FAA UAS RID "final" rule

From: "Stuart W. Card" <[email-masked]>
Date: Sat, 30 Jan 2021 23:05:09 -0500

I slogged through all 470 pages of the preview of the FAA UAS RID 
"final" rule released the Monday after Christmas. It reflects a major 
reversal vs the earlier Notice of Proposed Rule Making (NPRM).

Then I checked the official version published in the Federal Register 
JAN 15; there were no technically significant differences.

I am participating in the ASTM F38.02 revision of F3411 to support 
compliance with the rule: we have already had several meetings since the 
rule was published; ASTM has recognized our efforts within IETF and is 
considering our requests for tweaks to F3411 to enable DRIP. :-)

Then, based on all the above, I reviewed the DRIP Requirements draft to 
see how it needs to be updated to reflect the rule (vs the NPRM on which 
the draft was partly based).

My highlights from and comments on the rule, followed by my assessment 
of how it affects the DRIP Requirements draft specifically and DRIP 
working group activities generally, are attached.

These are _my_ opinions, neither those of any of my employers nor those 
of any of their sponsors.

If you see anything in the rule that I missed, that should be reflected 
in the DRIP Requirements, please tell me ASAP, as I will be editing that 
draft tomorrow.

Thanks!

-- 
-----------------------------------------
Stuart W. Card, PhD, Principal Engineer
AX Enterprize, LLC  www.axenterprize.com
4947 Commercial Drive, Yorkville NY 13495

---

From: Michael Richardson <[email-masked]>
Date: Sun, 31 Jan 2021 16:26:45 -0500

> JAN 15; there were no technically significant differences.

What I'm reading is that there are contradictory statements/actions.
Did I mis-understand?

    > of any of their sponsors.

As an attachment, they won't make into the list archives.
(But thanks for using ODT!)

Converted to text below. Stu's opinions:

The Federal Aviation Administration (FAA) released its “final” rule for
Unmanned Aircraft Systems (UAS) Remote Identification (RID) 2020 DEC 28. It
was published in the Federal Register 2021 JAN 15. It will become effective
60 days after publication, 2021 MAR 16 TUE (although few significant terms
will take effect upon that date). Manufacturers then have another 18 months
before all new UAS produced in or for sale in the United States must comply,
by 2022 SEP 16. Operators have a still further 12 months before all UAS they
fly must comply, by 2023 SEP 16. Provisions are substantially different from
those in the FAA Notice of Proposed Rule Making (NPRM) issued one year
earlier.

Other than broad exemptions for Federal Government (especially military) UAS,
and waivers, there are 3 ways to comply: “standard remote identification
aircraft”; “remote identification broadcast modules”; and “operations at
FAA-recognized identification areas.” As contemplated in the NPRM, Automatic
Dependent Surveillance – Broadcast (ADS-B Out) & Air Traffic Control (ATC)
transponders are prohibited for UAS operating under the RID rule, but allowed
in some cases for UAS operating under other rules (e.g. large UA with filed
flight plan in controlled airspace). In a major reversal from the NPRM, a
“Limited RID” option was not adopted, as it was to use only Network RID,
which also was not adopted. Only Broadcast RID is acceptable for rule
compliance outside the counter-intuitively named “identification areas.”

The FAA has not given up on Network RID, using words such as "initial"
rule/capability to refer to the Broadcast RID requirement. Also sending via
other means (even the for-now-deprecated Network RID), for purposes other
than rule compliance, is encouraged:  “The FAA notes that this rule does not
preclude industry from establishing Remote ID USS-like networks where
entities can exchange remote identification information to facilitate a safer
and more efficient airspace of the United States. The FAA encourages further
development and maturation of UTM concepts, especially those that consider
aviation safety national security, and law enforcement needs.”

With Network RID gone (for now), there is no longer an assumption that each
UAS will be connected to a UAS Service Supplier (USS) participating in the
UAS Traffic Management (UTM) system over the Internet, so the FAA recognizes
that their contemplated method of assigning single use Session IDs needs
reconsideration. “... the FAA plans to develop an alternative strategy for
assignment of session ID to unmanned aircraft operators. The FAA will
consider existing policies, such as the Privacy ICAO Address (PIA) program
for aircraft equipped with ADS-B Out, when developing the session ID
policy. Pursuant to the Department of Transportation’s procedures regarding
significant guidance documents, FAA will seek public comment on the session
ID policy prior to finalizing it.” Anything like the PIA would be
non-scalable to large numbers of UAS, too slow for an aviation sector that
moves much faster than manned aviation, and would not achieve the privacy
objective of single use Session IDs.

The Internet Engineering Task Force (IETF) Drone Remote Identification
Protocol (DRIP) working group is developing open standards for Trustworthy
Multipurpose Remote Identification and tracking (TM-RID), including but not
limited to the Session ID assignment function. The IETF DRIP approach retains
here the role of RID registries, vetted by the cognizant Civil Aviation
Authority (CAA, e.g. FAA): in the context of UTM, registry functions could be
integrated into USS, bundled with other USS functions but subcontracted by
the USS operator, or contracted separately by the UAS operator; outside of
UTM, registry business aspects would be different, but registry technical
functions would remain the same. A batch of Hierarchical Host Identity Tags
(HHITs) can be self-generated, proposed to a registry / HHIT Domain Authority
(HDA) [/USS], and (if the registry agrees) registered, in advance, no
problem, as Adam Wiethuechter and Bob Moskowitz have outlined.

Immediate actionability of RID information was not addressed in the
rule. Trustworthiness of the RID information transport and the RID
information sender was not addressed. Under the mistaken belief that dropping
Network RID and requiring only Broadcast RID eliminates any vulnerabilities
associated with RID, the final rule drops the NPRM vague requirement for
"cybersecurity".

The FAA also rejected proposals for the protection of the privacy of the
operators of UAS participating in RID, arguing inter alia that the exemption
for Federal and military operators would protect sensitive Government
operations, despite the fact that observing an aircraft that is not
participating in RID itself leaks the information that it may be a sensitive
Government operation, and simply not participating in RID would deprive such
operations from deriving its benefits (e.g. Detect And Avoid [DAA]
self-separation using RID). Some comments relating to this, quoted by the FAA
in the preamble to the final rule, and the FAA’s response, follow.

- "Ax Enterprize noted that that ASTM... has taken the position that remote
  identification is strictly for security, not safety functions, thereby
  excluding detect-and-avoid... They also proposed (TM-RID)... to satisfy
  several requirements including, but not limited to, verifying that messages
  are from the stated sender and the UAS Identification is in a registry,
  looking up public and private information... suggested that UAS operator
  contact information is generally preferable to control station location
  information… suggested a message element to specify which Remote ID USS the
  UAS is connected to."

- "Many commenters suggested the FAA modify the proposed regulation to allow
  for the control station location to only be available to specific entities
  such as the FAA and law enforcement. Though some commenters suggested using
  encryption techniques to accomplish this, the FAA finds that implementation
  of such a nuanced requirement would be highly complex, costly, and
  impractical. The FAA does not intend to limit who can receive the broadcast
  messages, and allowing encryption of certain message elements would limit
  who can receive the broadcast messages only to those with the capability to
  decrypt the messages. Allowing encryption is inconsistent with the FAA’s
  policy that the remote identification message elements should be publicly
  available information. Further, as some commenters suggested, different
  situations may necessitate certain emergency responders or other
  individuals to make contact with a remote pilot. In these situations, a
  privacy or encryption implementation may prohibit the on-scene individuals
  from having the critically needed information. In addition, an encryption
  requirement would present technical challenges leading to increased cost
  and complexity. For example, encryption key management could require
  standard remote identification unmanned aircraft, broadcast modules, and
  authorized receivers to have internet connectivity and specialized
  software, increasing the cost of this rule and potentially creating
  cybersecurity vulnerabilities. Therefore, the FAA adopts the control
  station location requirement as proposed… FAA clarifies that encryption of
  the required message elements is not permitted."

Some important specifics of the 3 means of compliance follow.

Standard RID UA:
- Must send either the UA’s ANSI/CTA-2063-A manufacturer assigned Serial
  Number or a single use Session ID, not the UA’s registration number, but a
  registration able to be looked up from RID is still required, regardless of
  where the UA is registered.

- Correlation of Serial Number or Session ID to the registration database is
  limited exclusively to the FAA! This provision alone probably suffices to
  delay RID information too much for it to be used by defense or security
  operators who must make instant decisions to protect facilities and people.

- “The FAA clarifies that unmanned aircraft without remote identification may
  be upgraded to standard remote identification unmanned aircraft if the
  upgrade enables the unmanned aircraft to meet all of the remote
  identification requirements of this rule.”

RID Broadcast Module:
- “A person may equip an unmanned aircraft with a remote identification
  broadcast module by securing or integrating a remote identification broadcast
  module to the unmanned aircraft or by other means (e.g., software upgrade)…
  unmanned aircraft without remote identification could equip with a remote
  identification broadcast module by either a software upgrade or by securing
  the module to the unmanned aircraft...”

- Must send its own Serial Number, not the UA's Serial Number, not a Session ID.
- Serial Number "must be entered into the registration record for the unmanned aircraft."
- Not being integrated with the UA flight controller, cannot know, thus need
  not send, emergency status.
- Likewise must send takeoff location as a proxy for pilot / Ground Control
  Station (GCS) location.
- UA so equipped must operate within Visual Line Of Sight (VLOS).

FAA-Recognized Identification Areas (FRIA):
- UA not equipped for RID may operate without it, within VLOS of the pilot,
  if both the UA and pilot/GCS are within the boundaries of such an area.
- "Organizations eligible to apply for establishment of a FRIA include:
  community-based organizations recognized by the Administrator, primary and
  secondary educational institutions, trade schools, colleges, and
  universities."

“The rule provides for operators to seek special authorization to operate UA
without remote identification for the purpose of aeronautical research or to
show compliance with regulations.” The narrow exemption for aeronautical
research, as written, would preclude testing surveillance and other systems
external to UAS to ensure they can detect and track UA that are not
effectively sending Broadcast RID (whether due to hardware failure, software
bug, malice or whatever, as will inevitably occur), unless said research is
deemed by the FAA to be in pursuit of UTM or U.S. Government
Counter-UAS. This prohibits private testing in support of e.g. protecting
critical infrastructure not operated by the Government.

Rules for Manufacturers:
- "Under the rule, anyone can create a means of compliance. However, the FAA
  must accept that means of compliance before it can be used for the design or
  production of any standard remote identification UA or remote identification
  broadcast module."

- "Remote ID Broadcast must be sent over unlicensed Radio Frequency spectrum
  (receivable by personal wireless devices, ex: Wi-Fi or Bluetooth)" under 47
  CFR part 15.

- Broadcast RID error correction (not just detection) is required. Of the 3
  Broadcast RID media specified in ASTM F3411: WiFi Neighbor Awareness
  Networking and Bluetooth 5 have it, but Bluetooth 4 lacks it; so Bluetooth
  4 must be dropped from F3411, or FEC must be added to F3411 or DRIP (in the
  latter case, F3411 alone would not suffice for  compliance, but would need
  to be augmented with DRIP).

“FAA encourages consensus standards bodies to develop means of compliance and
submit them to the FAA for acceptance.” The FAA is well aware of the ASTM
F3411 standard and expects to accept it, once it has been revised. The ASTM
F38.02 working group that produced F3411-19 is now working to revise it. Some
but not all cognizant FAA personnel are aware, and the ASTM working group has
acknowledged, that the IETF DRIP working group is working to standardize the
TM-RID extensions to F3411, addressing many of the issues above. Standards
coordination with the International Civil Aviation Organization (ICAO), the
RTCA (formerly the Radio Technical Commission for Aeronautics), RTCA’s
counterpart the European Organisation for Civil Aviation Equipment (EUROCAE),
et al, is also ongoing. Time is of the essence, as manufacturers will need to
develop, test and integrate Application Specific Integrated Circuits (ASICs)
to implement Broadcast RID transmitters within the severe Cost, Size, Weight
and Power ($SWAP) constraints of small UAS, and have them on the shelf in
just over a year and a half, based on standards that are not yet ready for
publication.

The rule now having been published, DRIP drafts should be revised to remove
most references to the NPRM and update them as needed to reflect the
provisions of the “final” rule. References to “Limited RID” should be
removed, but Network RID related content should remain, as it is likely to
return in revisions to the rule, and the function is likely to exist (in some
form and under some other name, probably as part of UTM) even before any such
future revisions; ASTM F38.02 does not intend to remove it from F3411.

The DRIP Requirements draft needs many small revisions, but few to its actual
numbered requirements. ID-4 must have its reference to an FAA proposed
Network RID 6 month data retention period struck. PRIV-2 may require revision
to preclude operators enabling encryption where prohibited.

Session ID assignment/registration should  become an urgent focus of DRIP, to
provide options to the FAA before they issue their policy on and guidance for
it; “blinding” of aircraft registration numbers in registering Session IDs
will be essential, so that only the FAA can unblind them. Other work to
provide operator privacy should continue: encryption of required RID data
elements clearly will not be permitted in the US unless/until the rule is
revised to allow it; but no such revision can be expected without clear
demonstrations that privacy can be protected without endangering safety or
compromising security.

The lack of error correction in Bluetooth 4 must be addressed, either in ASTM
F38.02 or IETF DRIP. Depending on where that occurs, it may or may not be
necessary to propose DRIP to the FAA as a means of compliance: the focus of
DRIP lies beyond the minimum requirements of the rule; also DRIP is
envisioned as a set of extensions to (or protocols that run atop) ASTM F3411,
so when F3411 is accepted as a means of compliance,  DRIP comes along for the
ride, provided it does not break anything in F3411.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Adam Wiethuechter <[email-masked]>
Date: Sun, 31 Jan 2021 22:46:45 +0000

Michael,

Comment inline.

--------
73,
Adam T. Wiethuechter
Software Engineer; AX Enterprize, LLC

________________________________
From: Tm-rid <[email-masked]> on behalf of Michael Richardson <[email-masked]>
Sent: Sunday, January 31, 2021 4:26 PM
To: Stuart W. Card <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Drip] attached: my highlights from & comments on FAA UAS RID "final" rule

<atw>
Incorrect. The final rule was [pre-]published on DEC 28 but did not appear in the Federal Register (thus making it actual law) until JAN 15.
Stu quickly looked at the official document in the Register to confirm no content differences between the pre-published version and the Register version - which there was none (if any just spelling fixes and what not).
</atw>

[atw: text cut for sanity of email chain]

---

From: "Card, Stu" <[email-masked]>
Date: Sun, 31 Jan 2021 18:57:00 -0500

Plus, in the Federal Register version, there was one additional existing
law or regulation cited, and a clarification that requirements were for
standard RID aircraft & Broadcast RID modules as concrete items vs for the
abstract process of RID.

On Sun, Jan 31, 2021, 5:46 PM Adam Wiethuechter <
[email-masked]> wrote:

> ------------------------------
> *From:* Tm-rid <[email-masked]> on behalf of Michael Richardson <
> [email-masked]>
> *Sent:* Sunday, January 31, 2021 4:26 PM
> *To:* Stuart W. Card <[email-masked]>; [email-masked] <
> [email-masked]>
> *Subject:* Re: [Drip] attached: my highlights from & comments on FAA UAS
> RID "final" rule
>
>
> Incorrect. The final rule was [pre-]published on DEC 28 but did not appear
> in the Federal Register (thus making it actual law) until JAN 15.
> Stu quickly looked at the official document in the Register to confirm no
> content differences between the pre-published version and the Register
> version - which there was none (if any just spelling fixes and what not).
> </atw>
>