Subject: [Drip] reqs review: registries

From: "Stuart W. Card" <[email-masked]>
Date: Sun, 4 Oct 2020 07:27:41 -0400

[email-masked] review major issue:

> -  It is quite hard to make a link between the technical description of DRIP and the sections describing the overall context, scope and RID solutions.
> For example, DRIP is about registries, but which registries? The requirements of Section 4 should be included within the UTM / U-space architecture.

Here is something I recently sent to Michael P. about the confusion re:
registries in UAS RID and UTM (with a US perspective):

> (1) registry of UAS operators: currently run by FAA: I suspect they may not be able to scale it up: plus each CAA needs such a registry
> 
> (2) registry of UA: currently does not exist: FAA is talking about running it themselves: I am even less sanguine about them scaling that given its likely data change rate: plus each CAA needs one
> 
> (3) UAS RID registry: currently does not exist as such: need for such is identified in ASTM F3411, but no specs for it therein: I suspect will be same as (2) above or (4) below
> 
> (4) UTM virtual registry distributed across many USS: currently several prototypes...: essentially a subscriber database with information on the UAS operator and all that operator's UA:
> may be loosely or tightly coupled with other information maintained by USS, such as planned, current & past 6 months operations
> (not "registry" information as such, but databases with pointers to & maybe from registry entries)

In the draft, we tried to focus primarily on (3) above, despite it not
yet being clearly (2), (4) or its own unique thing, so abstracted its
two functions of public access (minimal) and private (restricted access,
extended) information.

Perhaps we just need some text along the lines of what I sent Michael,
to clarify that regulations and business models are both moving targets,
but we need to support certain functions regardless of where they land?

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

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 5 Oct 2020 09:39:47 -0400

>> For example, DRIP is about registries, but which registries? The requirements of Section 4 should be included within the UTM / U-space architecture.

In the FAA model, the UAS registration (as Stu points to below) is a 
TBD, but between the UAS and USS.  Not the UTM.  Now a UTM provider may 
also be a USS provider, but there are good business reasons to view them 
as separate entities.  ICAO also seems them as separate.

---

From: "Card, Stu" <[email-masked]>
Date: Mon, 5 Oct 2020 10:14:49 -0400

To clarify a bit re: USS vs UTM --

UTM is a network.

USS are the main servers on that network.

There are also other servers (and obviously clients, gateways to other
networks, routers, switches, etc.).

USS provide some (not necessarily all) of the registration services, in
support of their main job of deconflicting & tracking airspace usage.

I anticipate that USS also will act as HDA for those UAS that use HHIT as
identifiers.

How this works within & outside the scope of GRAIN is TBD.

On Mon, Oct 5, 2020 at 9:40 AM Robert Moskowitz <[email-masked]>
wrote:

> >> -  It is quite hard to make a link between the technical description of
> DRIP and the sections describing the overall context, scope and RID
> solutions.
> >> For example, DRIP is about registries, but which registries? The
> requirements of Section 4 should be included within the UTM / U-space
> architecture.
>
> >> (1) registry of UAS operators: currently run by FAA: I suspect they may
> not be able to scale it up: plus each CAA needs such a registry
> >>
> >> (2) registry of UA: currently does not exist: FAA is talking about
> running it themselves: I am even less sanguine about them scaling that
> given its likely data change rate: plus each CAA needs one
> >>
> >> (3) UAS RID registry: currently does not exist as such: need for such
> is identified in ASTM F3411, but no specs for it therein: I suspect will be
> same as (2) above or (4) below
> >>
> >> (4) UTM virtual registry distributed across many USS: currently several
> prototypes...: essentially a subscriber database with information on the
> UAS operator and all that operator's UA:
> >> may be loosely or tightly coupled with other information maintained by
> USS, such as planned, current & past 6 months operations

---

From: <[email-masked]>
Date: Tue, 6 Oct 2020 08:30:20 +0000

(as individual)

> In the draft, we tried to focus primarily on (3) above, despite it
> not yet being clearly (2), (4) or its own unique thing, so
> abstracted its two functions of public access (minimal) and private
> (restricted access,
> extended) information.
> 
> Perhaps we just need some text along the lines of what I sent
> Michael, to clarify that regulations and business models are both
> moving targets, but we need to support certain functions regardless
> of where they land?

This is useful to capture in the document, indeed.  

Thanks. 

Cheers,
Med

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.