Subject: [Drip] my 1st pass through FAA UAS RID 2020DEC28 final rule

From: "Card, Stu" <[email-masked]>
Date: Tue, 29 Dec 2020 14:12:25 -0500

attached

Although there are several points of interest, IMO the top 2 for us are:

- Network RID will not be an acceptable means of satisfying FAA
requirements, only Broadcast;

- with Network RID gone, there is no longer an assumption that each UAS
will be connected to a NetRID Service Provider USS participating in the UTM
over the Internet, so FAA recognizes that their contemplated method of
assigning single use Session IDs needs reconsideration, and they are
soliciting public input on this.

DRIP WG should jump on this!!!

A batch of HHITs can be self-generated, proposed to a registry/HDA[/USS],
and (if the registry agrees) registered, in advance, no problem, as Adam
has outlined.

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 29 Dec 2020 14:28:00 -0500

Stu,

Your attachment is type .txt and won't open,.,,

On 12/29/20 2:12 PM, Card, Stu wrote:
> - with Network RID gone, there is no longer an assumption that each 
> UAS will be connected to a NetRID Service Provider USS participating 
> in the UTM over the Internet, so FAA recognizes that their 
> contemplated method of assigning single use Session IDs needs 
> reconsideration, and they are soliciting public input on this.
>
> A batch of HHITs can be self-generated, proposed to a 
> registry/HDA[/USS], and (if the registry agrees) registered, in 
> advance, no problem, as Adam has outlined.
>
>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[email-masked]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 29 Dec 2020 17:47:27 -0500

Something happened with the mailing list.  trying again,

Oh, it is not System UTF-8, but ISO 8859-14...

Got it opened now.

On 12/29/20 4:56 PM, Michael Richardson wrote:
> Robert Moskowitz<[email-masked]>  wrote:
> Works fine for me:
> from Remote Identification (RID) executive summary --
>
> Standard RID UA:
> must send {SN|SessionID} not registration#
> {SN|SessionID} -> registration database correlation limited exclusively to FAA!
>
> --
>
> RID Broadcast Module:
> - UA so equipped must operate within VLOS
> - need not send emergency status
> - need send only takeoff location, not GCS location
> - must send its own SN, not the UA's SN, not a SessionID!
> - SN "must be entered into the registration record for the unmanned aircraft"
>
> --
>
> FAA-Recognized Identification Areas (FRIA):
> - UA must operate within VLOS & within FRIA boundaries
> - "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."
>
> --
>
> 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."
> - "FAA encourages consensus standards bodies to develop means of compliance and submit them to the FAA for acceptance."
> - "Remote ID Broadcast must be sent over unlicensed Radio Frequency spectrum (receivable by personal wireless devices, ex: Wi-Fi or Bluetooth)"
>
> --
>
> Other Provisions:
> - ADS-B Out & ATC transponders prohibited for RID but allowed for UAS in some cases (e.g. large UA w/a filed flight plan in controlled airspace)
> - "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 rule allows a UA registered in a foreign country to be operated in the United States only if the operator files a notice of identification with the FAA. This enables the FAA and law enforcement to correlate a remote ID broadcast with a person responsible for the operation of a foreign-registered UA."
>
> ==
>
> from 1st brief pass through RID final rule --
>
> - "Ax Enterprize noted that that ASTM F3411-19 Standard Specification for Remote ID and Tracking has taken the position that remote identification is strictly for security, not safety functions, thereby excluding detect-and-avoid. They suggested a prescriptive definition of “real-time” and “near real-time.” They also proposed Trustworthy Multipurpose Remote Identification Protocol which is intended 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, and structuring that information for readability."
>
> - "Ax Enterprize suggested that UAS operator contact information is generally preferable to control station location information."
>
> - "Ax Enterprize suggested a message element to specify which Remote ID USS the UAS is connected to."
>
> - "Ax Enterprize agreed that the monitoring function should notify the remote pilot if remote identification fails."
>
> - "Ax Enterprize mentioned that work testing UAS situation awareness systems should be permitted."
>
> - "The National Public Safety Telecommunications Council, AiRXOS, the Civil Air Patrol/ United States Air Force Auxiliary, the International Association of Fire Fighters, and DRONERESPONDERS Public Safety Alliance, asked for a remote identification solution for “trusted users” such as State and local public safety agencies instead of excepting certain parties (e.g., DOD) from having to comply with the operating requirements."
>
> - "AiRXOS and Motorola supported the session ID concept for most missions, but further recommended developing a “trusted user” process to allow law enforcement to flag missions for which Remote ID USS should not provide information to the general public."
>
> - "The Association for Unmanned Vehicle Systems International broadly supported making operator location publicly available but suggested the FAA consider ways to protect this potentially private or confidential information, such as an opt-out or a trusted operator status that would only reveal the location to law enforcement and government agencies."
>
> - "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."
>
> - "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."
>
> - "The FAA proposed that a session ID would be assigned by a Remote ID USS. Because this rule does not retain the requirement for standard remote identification unmanned aircraft to have an Internet connection to a Remote ID USS, 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,20 FAA will seek public comment on the session ID policy prior to finalizing it."
>
> - Almost no attention paid to the issue of trustworthiness of RID information transport or its sender.

---

From: "Card, Stu" <[email-masked]>
Date: Wed, 30 Dec 2020 23:14:17 -0500

Final rule mandates FEC, which ASTM F3411 over Bluetooth 4 lacks, but Adam
has proposed a few potential schemes for adding it (and prototyped at least
one of them).

Final rule drops NPRM vague requirement for "cybersecurity".

On Tue, Dec 29, 2020, 5:47 PM Robert Moskowitz <[email-masked]>
wrote:

> Robert Moskowitz <[email-masked]> <[email-masked]> wrote:
> Robert Moskowitz
> C:      248-219-2059
> F:      248-968-2824
> E:      [email-masked]
>
> There's no limit to what can be accomplished if it doesn't matter who gets
> the credit
> --
> Tm-rid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tm-rid
>

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 31 Dec 2020 10:51:51 -0500

On 12/30/20 11:14 PM, Card, Stu wrote:
> Final rule mandates FEC, which ASTM F3411 over Bluetooth 4 lacks, but 
> Adam has proposed a few potential schemes for adding it (and 
> prototyped at least one of them).
>

In VIII.B.11 Cybersecurity (pgs 149 - 150)

ii. Public Comments and FAA Response

Comments: The FAA received many comments supporting cybersecurity in 
general, but
that also requested the FAA provide greater specificity or adopt 
specific standards. The vast
majority of these comments related to transmission of message elements 
through the Internet to
the Remote ID USS.

The FPVFC noted that if a radio frequency broadcast remote 
identification system is
used, there are no cybersecurity concerns.

FAA Response: As described in section VII.A of this preamble, this rule 
does not require
transmission of message elements through the Internet to a Remote ID 
USS. In addition, the
FAA agrees with the FPFVC that broadcasting the message elements does 
not raise
cybersecurity concerns. Accordingly, the proposed minimum performance 
requirement related to
cybersecurity is removed from this rule, for the reasons described above.

So at minimum, no cybersecurity requirement.  FPVFC is wrong in that 
cybersecurity over broadcast includes forgery concerns.  But FAA, at 
minimum, is not requiring this be addressed.

IETF is concerned about trust in communications and we will lead the 
way.  Or some such...

>
> On Tue, Dec 29, 2020, 5:47 PM Robert Moskowitz 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>>     Robert Moskowitz<[email-masked]>  <mailto:[email-masked]>  wrote:
>     E: [email-masked] <mailto:[email-masked]>
>
>     There's no limit to what can be accomplished if it doesn't matter
>     who gets the credit
>     -- 
>     Tm-rid mailing list
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/tm-rid>
>
>

---

From: "Card, Stu" <[email-masked]>
Date: Thu, 31 Dec 2020 12:57:06 -0500

+1 Bob

On Thu, Dec 31, 2020 at 10:52 AM Robert Moskowitz <[email-masked]>
wrote:

> that also requested the FAA provide greater specificity or adopt specific
> standards. The vast
> The FPVFC noted that if a radio frequency broadcast remote identification
> system is
> transmission of message elements through the Internet to a Remote ID USS.
> In addition, the
> FAA agrees with the FPFVC that broadcasting the message elements does not
> raise
> IETF is concerned about trust in communications and we will lead the way.
> Or some such...
>
>
>