Subject: [Drip] Eating a really big problem - FAA RemoteID Final Rule

From: Robert Moskowitz <[email-masked]>
Date: Wed, 30 Dec 2020 08:33:01 -0500

In my view, FAA has decided to take the easy things first and move 
harder things around.  We might get some clarification on this in the 
coming weeks, but it is a good working model because:

UTM is not going away.

And for UTM there needs to be a number of mechanisms to collect 
information on UAS so tracking and management can happen.

Thus USS is not going away.

So all the terms we have defined in drip-arch and drip-req that are no 
longer in RemoteID FR, should reference UTM ConOps v2, March 2, 2020. 
Which says:

Remote ID: RID capabilities enhance safety and security by allowing the 
public, FAA, law enforcement, and other federal security agencies to 
remotely identify UAS flying in their jurisdiction. Government-qualified 
RID USSs support RID by receiving and processing network publish RID 
messages and responding to RID data queries from the general public and 
authorized officials (e.g., FAA, law enforcement officials).

I.E. Network Remote ID is not specifically defined, but needed.

Now this will probably change some in v3, but "processing network 
publish RID messages" is still needed somehow.  As Stu pointed out FAA 
is will be looking to SDOs for standard ways to meet this.

I will work on changes to drip-arch to adjust to the current realities 
of published rules. But nothing we have set out to do has been 
obviated.  We have a breather on Network ID and a challenge on privacy.

Now about Privacy.  As one of my contacts in FAA is apt to say, "I get it."

I think the big barrier is how will authorized Observers be authorized 
and use said authorization to get the private information in real time?  
Pieces exist, but real work is needed to have it in place to allow for 
protecting PII in a public (NAS) space.  ICAO has its Trust Framework 
that can met this need.  We will need to work with ICAO (which I have 
done and will continue to do) so the technical underpinnings exist for 
the Trust to be deployed to allow for all the rest...

Another part is the concern on encryption.  If you read the FAA 
response, it is concern to encrypting messages to protect some PII. They 
don't seem to see how to only encrypt the PII data and leave everything 
else open.  This is where IETF comes in.  My drip-operator-privacy draft 
IS selective with operational rules.  If we have this moving forward in 
tandem with Observer trust systems, we can work to achieve privacy 
protect where/when appropriate.

This is a case where safety requires it works for all before it can be 
allowed for some.

Now on to writing drafts...

---

From: "Card, Stu" <[email-masked]>
Date: Wed, 30 Dec 2020 09:15:53 -0500

I concur.

Maintain course but reduce speed on DRIP efforts directed specifically
towards Network RID.

For privacy, we must demonstrate _selective_ confidentiality of UAS
operator sensitive information (primarily location of GCS), easily usable
by an operator a couple of sigmas below the mean in crypto/networking
technical competence/motivation.

Once we have done that (and a couple of innocent operators have been beaten
with baseball bats by mobs enraged by harm done by other operators), CAAs
may listen.

BTW, comments in the Final Rule discussion labeled "Ax Enterprize" were
made by me, writing for that employer, reflecting concerns shared by some
of our customers and some DRIP participants.

On Wed, Dec 30, 2020 at 8:33 AM Robert Moskowitz <[email-masked]>
wrote:

> --
> Tm-rid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tm-rid
>