Subject: [Tm-rid] Review of draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and other

From: Amelia Andersdotter <[email-masked]>
Date: Mon, 6 Jul 2020 20:15:42 +0200

Dear all,

Having recently read Jane Jacob's Nature of Economies, I was inspired to
write this review in the form of a platonic dialogue. It's based on my
personal, professional judgement and RFC6973 as well as RFC8280, and the
discussants will indicate which source materials are referenced when
appropriate. I'm hoping this will also make the review a bit lighter
than the human rights reviews based on RFC8280 that I produced back in
2018, as well as remove ambiguities w.r.t. the obligations to take any
of these notes into account in further drafting.

Scene I. The Scholar and the Apprentice are on a journey to the capital.

- In some European languages, there is no language-inherent ways to
express the difference between safety and security, said the Scholar. In
some Scandinavian languages, for instance, the closest translation of
"safety" rather brings the mind to a state of personal comfort. It is
easy to get lost in translation when operating in fields that rely a lot
on the distinction.

- Oh, you mean that restrictions in the source language might make
localization [RFC8280, 6.2.12] as well as internationalization [RFC8280,
6.2.5] more difficult? said the Apprentice.

- Indeed, and also accessibility [RFC8280, 6.2.11] and outcome
transparency [RFC8280, 6.2.19], the Scholar replied. It concerns not
only the direct encoding of an issue into an alphabet, abugida or abjad
that is in use in a place, but also the concepts given voice in target
communities.

- In a heavily regulated field, such as airspace, there must be many
pitfalls, mused the Apprentice. I had actually already reflected along
these lines, perhaps since I myself speak such a language natively, when
reading [draft-drip-arch-02, 3.1.2]. The public internet DNS hierarchy
relies a lot on a single jurisdiction for guaranteeing, ultimately,
integrity [RFC8280, 6.2.16], authenticity [RFC8280, 6.2.17] and
confidentiality [RFC8280, 6.2.15] - so at least with safety features
such as DNSSEC, the trustworthiness of which intrinsically relies on a
process dependent on the entry visas into a single jurisdiction. Was
this the type of ambiguity you wanted to avoid?

- Ah, security features, safety features, and trade-offs, especially
with privacy [RFC6973, 7.4] - and it doesn't even obviously map to any
of the requirements in [draft-drip-reqs-02] where the only guidance
contained in [draft-drip-reqs-02, 4.4] concerns the public nature of the
registry itself, said the Scholar. They're barely touched upon, but
within the understanding that safety and security must be different and
perceived differently. Does control over an airspace identifier or the
ability to provision it imply control over an airspace as such [RFC8280
6.2.6]? And who may have preferences in these matters? And why?

- Indeed, continues the Scholar. It is advisable to steer clear of such
waters, and maybe this ontological ambiguity is not the only troubled
stream. Many endeavours exist, like DiNS in France (AFNIC) or SHG in
Canada (CIRA), which rather than building DNS-based technology
registries into the global internet architecture, build them in parallel
using the same open standards [RFC8280 6.2.7]. But this is optional in
[draft-drip-arch-02, 3.1.2], even receommended against! And a similar
recommendation occurs in [draft-drip-arch-02, 3.2.2] - why not leave the
door more open to private registries? [draft-drip-arch-02, 7] would have
us think that architectural implications mostly impact the content of
the identifiers in [draft-drip-arch-02, 4]. Indeed, even
[draft-drip-arch-02, 4] would have us think that the ASTM requirements
mostly relate to ID bit sizes and the special adaptions required to fit
what must be fit in a constrained space.  [draft-drip-arch-02, 6] even
leads our thoughts down this path! Although I'll have to return to the
subject of  [draft-drip-arch-02, 6] later...

- Size matters, said the Apprentice cheerfully. And maps unspokedly to
[draft-drip-reqs-01, 4.2 ID-1].

The two stood in silence for a few moments as the wind picked up.

- While it's true that centralization sometimes suffers an unnecessarily
bad name, continued the Scholar, it is equally true that
decentralization [RFC8280, 6.2.13] affords a certain adaptability
[RFC8280, 6.2.18]. Was there not a private registry in figure 1 of
section 1 Introduction anyway?

- What is it that you normally say? said the Apprentice, grasping for a
words.

- Every country needs a flag, an anthem and airline, said the Scholar.
But the figure, the figure.

- I have it here, said the Apprentice. There is a private registry. It's
also in [draft-drip-reqs-01, 4.4 REG-2]. I did not easily see the
connection at first, but it is there. And then there is the...

- Yes? said the Scholar.

- Well, said the Apprentice. Why is there an illustration of Net-RID in
figure 2, but not of Broadcast RID? I could not work it out. It actually
did not seem sensible to me to re-iterate from [draft-drip-reqs-02] the
RID classifications from ASTM [F3411-19] at all.

- Maybe it was included for extra clarity? said the Scholar. Personally,
I found myself objecting more strongly to the second paragraph of the
Introduction - it does not seem to me an architectural issue that "many
considerations" dictate anything in particular, nor do I see the need to
clarify that "CAAs worldwide" without further qualification request some
thing. Maybe it could be removed. Similarly, I did not immediately see
the usefulness of speculating on the work of other SDOs, such as 3GPP.

- "Network and Broadcast RIDs are expected to be similarly constrained
irrespective of the methods used to transmit them"? said the Apprentice.

- Your rephrasing makes it more digestible, indeed, responded the
Scholar. I suppose in either case it counts as an example of upholding
heterogeneity [RFC8280, 6.2.8].

- And I was worried about some aspects of [draft-drip-arch-02, 7] too,
said the Apprentice. Like whether the UAS registration number and the
unique physical serial numbers are both permanent, or whether they could
be transiently linkable as suggested in [draft-drip-arch-02, 5]?

- Who knows? said the Scholar. In the capital, they may have better
knowledge on these topics. As far as I have understood the architectural
descriptions of U-space, federation, modularity and privacy are sought
after features in any ID carrying scheme for UAS under EASA regulations
and indeed the broader corpus of EU regulations - whether it be GOF or
SAFIR or something else. It even seems to me that these are topics
better left for a requirements document and not an architecture document!

- It was already said, said the Apprentice. Hold on, I have the e-mail
here somewhere...

- To the point, said the Scholar. It remains to be seen if any submodule
of the short-listed U-Space architecture, such as the FIMS, is equally
under assumptions of federation, modularity and privacy as the entirety
of the architecture. Some internet standards would appear to have a big
advantage if these federation requirements apply to sub-modules such as
the FIMS too. [draft-drip-arch-02, 7] does not yet resolve it, and maybe
even can't. The [draft-drip-reqs-01, 4] does a good job of laying down
requirements on identifiers to be transmitted.

- What I did miss too, said the Scholar, was the more direct references
to the benefits of using this system in terms of data, persistence of
identifiers and control over information sharing. What if the
registration number were transient [RFC6973, 7.1, RFC8280 6.2.10]? We
see the effort to reduce the risk of mis-attributions and intrusions
[RFC6973, 7.3], yes [draft-drip-arch-02, 4 and 5]. But the architecture
makes no mention of data minimization [RFC6973, 7.1, RFC8280 6.2.2,
6.2.9] - and it could otherwise be seen as quite natural to have a
regulatory mandated minimum set of data provided, with options for
additional data provision should the user so prefer [RFC6973, 7.2]?
Maybe some cross-referencing to the [draft-drip-reqs-01 4] requirements
would facilitate understanding the motivation for the choices made.

- How would such additional bits be included [RFC8280, 6.2.3]? asks the
Apprentice, but the Scholar is already off into their own rabbit hole.

- One wonders, says the Scholar, in the end, if there are lessons to be
learned from the LPWAN or IPWAVE. And one wonders, if
[draft-drip-arch-02, 6] adds anything, really. The second paragraph of
[draft-drip-arch-02, 6] should surely be in [draft-drip-arch-02, 1] if
it were a high-level architectural point. I think I'd prefer such a change.

- One wonders if it is the identifier message as such, or the method for
its provisioning [RFC8280, 6.2.1], which is the primary subject matter
of this architecture, the Apprentice chimes in.

- One wonders, says the Scholar, what the specific connections are
between the requirements in the requirements document and the specific
proposed approaches in [draft-drip-arch-02, 3].

The two walk off into the field, ready to reflect on other drafts,
identifiers and checklists.

End Scene I.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 6 Jul 2020 20:57:18 +0200

> easy to get lost in translation when operating in fields that rely a lot

Indeed.  E.g., in German, both are called “Sicherheit”.
In practice, we help ourselves by simply using the English terms when we need a more selective term.  If we are ever forced to actually speak German, we invent compound terms such as “Angriffssicherheit” (Security) and “Betriebssicherheit” (Safety).  The difference is presence or absence of the human mind to effect the degradation of freedom from dangers.  (Of course, the terms are not used as selectively in practice in English either, e.g., “social security” is mostly about safety.)

Grüße, Carsten

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 7 Jul 2020 16:36:23 +0200

Le 06/07/2020 à 20:57, Carsten Bormann a écrit :
>> - In some European languages, there is no language-inherent ways
>> to express the difference between safety and security, said the 
>> Scholar. In some Scandinavian languages, for instance, the closest
>>  translation of "safety" rather brings the mind to a state of 
>> personal comfort. It is easy to get lost in translation when 
>> operating in fields that rely a lot on the distinction.
> 
> Indeed.  E.g., in German, both are called “Sicherheit”. In practice,
>  we help ourselves by simply using the English terms when we need a 
> more selective term.  If we are ever forced to actually speak German,
> we invent compound terms such as “Angriffssicherheit” (Security) and
> “Betriebssicherheit” (Safety).

Platon would have probably said something about Σωτηρία
(ancient Greek for the name of a goddess of salvation), especially
because he cared about that, as he found the defenders to be very useful.

That aside,

I wonder why the choice of encoding an identifier in one domainname was
made, and not that of set of them?

There could be two domainnames in an onboard network of a flying taxi:
one dedicated to the hosts on the onboard safety network and one for the
  hosts on the entertainment network, for the traveller's smartphone wifi.

When that is so, one would still want one domainname to be advertised to
the outside, like there is just one text painted on the outside.

This makes me wonder if it would not be easier to just take that
conventional name painted on the outside frame and encode it in an
identifier, and why not putting it in an IPv6 address.

If we do so, the privacy question would be easier: the painted text is
there mandatory anyways so anyone can see it with a pair of binoculars.

Alex

   The difference is presence or absence
> of the human mind to effect the degradation of freedom from dangers.
>  (Of course, the terms are not used as selectively in practice in 
> English either, e.g., “social security” is mostly about safety.)
> 
> Grüße, Carsten
>

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 7 Jul 2020 11:15:18 -0400

> made, and not that of set of them?

Nothing prevents a UA from having multiple IDs to use where needed. Just 
the caveat that the Basic ID Message only has room for one ID and it is 
expected that that ID be used for a whole Operation.

>  hosts on the entertainment network, for the traveller's smartphone wifi.

UAM provides some other interesting considerations.  I suspect that a 
UAM will still be required to Broadcast Remote ID messages.  In theory 
it could have 2 radios sending out different set of messages with 
different MAC addresses (Note that many Brd-RID messages do NOT have the 
Remote ID, the receiver MUST be able to correlate messages to RID based 
on MAC).

> identifier, and why not putting it in an IPv6 address.

CAAs REQUIRE a tail number for all commercial and almost all civil 
aircraft to be displayed clearly.  For your hobby drone, you are 
expected to register it with the FAA (or EASA in EU) and be assigned a 
tail number.

Thus for 'starters' a UA has THREE IDs:  Manufacturer Serial Number, CAA 
registration, Remote ID.  Now the ASTM and FAA and EASA proposals offer 
to use Serial # or Tail # as RID (see text about ASTM RID types 
currently defined).

But each CAA has its own rules on what is a tail number, thus encoding 
into an IPv6 address is interesting.  Actually that IS being discussed 
in IATF GRAIN study group (yet another weekly call).

> there mandatory anyways so anyone can see it with a pair of binoculars.

Yes, but that is not even VLOS as you can't always see where the number 
is.  With RID, it is RLOS.

Oh, and I have been told there are 'perfect' replica model planes. For 
example it LOOKs just like a 737 even with binoculars.  But it is only 
1000' feet away, not 30000'.

The whole privacy/safety issue is complex.

Bob

-- 
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: Amelia Andersdotter <[email-masked]>
Date: Tue, 7 Jul 2020 17:31:10 +0200

On 2020-07-07 17:15, Robert Moskowitz wrote:
> different MAC addresses (Note that many Brd-RID messages do NOT have
> the Remote ID, the receiver MUST be able to correlate messages to RID
> based on MAC).
>
 there is upstarting work on MAC identifier
replacements:
https://mentor.ieee.org/802.11/dcn/20/11-20-0742-01-0rcm-proposed-par-draft.docx

which might be interesting if this is something that is going to present
architectural or other concerns in this group. or perhaps to talk about the work of this group in the ietf-ieee coordination group at least.

> expected to register it with the FAA (or EASA in EU) and be assigned a
I'm assuming that registration of hobby drones (or other aerial
vehicles) will occur with national or at least regional CAAs in the
European area, and that EASA will not perform a stronger function than
coordinating the federated architecture for registries that are thus set
up - at least in so far as they do not contain information that is
deemed sensitive by the national or regional CAAs (or other entities) in
question.

This is why the U-space documents emphasize federation and modularity a
lot, and perhaps why something like DNS tech could be interesting (I
imagine).

best regards,

Amelia

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 7 Jul 2020 11:46:22 -0400

> architectural or other concerns in this group. or perhaps to talk about the work of this group in the ietf-ieee coordination group at least.

Thanks for the heads up.  Even though I am on the 802.11 distribution 
and TEND to pay attention, I missed this one.  I did work on some of the 
802sec work, so I will see how this ties in.

I do know most of the 802.11 people.

> lot, and perhaps why something like DNS tech could be interesting (I

The goal will be to add in some flexibility and still allow the CAAs to 
meet their regulator/safety concerns.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 7 Jul 2020 18:03:53 +0200

Le 07/07/2020 à 17:15, Robert Moskowitz a écrit :
>>>> - In some European languages, there is no language-inherent 
>>>> ways to express the difference between safety and security, 
>>>> said the Scholar. In some Scandinavian languages, for
>>>> instance, the closest translation of "safety" rather brings the
>>>> mind to a state of personal comfort. It is easy to get lost in 
>>>> translation when operating in fields that rely a lot on the 
>>>> distinction.
>>> 
>>> Indeed.  E.g., in German, both are called “Sicherheit”. In 
>>> practice, we help ourselves by simply using the English terms 
>>> when we need a more selective term.  If we are ever forced to 
>>> actually speak German, we invent compound terms such as 
>>> “Angriffssicherheit” (Security) and “Betriebssicherheit” 
>>> (Safety).
>> 
>> Platon would have probably said something about Σωτηρία (ancient 
>> Greek for the name of a goddess of salvation), especially because 
>> he cared about that, as he found the defenders to be very useful.
>> 
>> That aside,
>> 
>> I wonder why the choice of encoding an identifier in one
>> domainname was made, and not that of set of them?
> 
> Nothing prevents a UA from having multiple IDs to use where needed. 
> Just the caveat that the Basic ID Message only has room for one ID 
> and it is expected that that ID be used for a whole Operation.
> 
>> There could be two domainnames in an onboard network of a flying 
>> taxi: one dedicated to the hosts on the onboard safety network and 
>> one for the hosts on the entertainment network, for the
>> traveller's smartphone wifi.
> 
> UAM provides some other interesting considerations.  I suspect that
> a UAM will still be required to Broadcast Remote ID messages.  In 
> theory it could have 2 radios sending out different set of messages 
> with different MAC addresses (Note that many Brd-RID messages do NOT 
> have the Remote ID, the receiver MUST be able to correlate messages 
> to RID based on MAC).

A querier receiving simply two such unrelated IDs would have difficulty
distinguishing that being one object or two objects flying in formation.
('flightooning', akin to 'platooning' which is a convoy of trucks on road).

A number that is painted would not have such a problem, because the
paint is glued on one object.

>> When that is so, one would still want one domainname to be 
>> advertised to the outside, like there is just one text painted on 
>> the outside.
>> 
> expected to register it with the FAA (or EASA in EU) and be assigned 
> a tail number.

Thanks.  I would guess a flying taxi would be more like an evolution of
an existing flying car, which is itself more of a plane that can also
drive on the highway, with its wings folded.  As such I would suspect
the tail numbers apply to flying taxis.

> Thus for 'starters' a UA has THREE IDs:  Manufacturer Serial Number, 
> CAA registration, Remote ID.  Now the ASTM and FAA and EASA
> proposals offer to use Serial # or Tail # as RID (see text about ASTM
> RID types currently defined).
> 
> But each CAA has its own rules on what is a tail number, thus 
> encoding into an IPv6 address is interesting.  Actually that IS
> being discussed in IATF GRAIN study group (yet another weekly call).

For automobiles, it is very simple: there is a VIN number (Vehicle
Identification Number) standardised by SAE and there is the license
plate standardised by a country regulator.

It thus seems that the tail number is like a license plate.

I wonder whether there is a number in planes that is similar to the VIN
number in automobiles.

>> If we do so, the privacy question would be easier: the painted
>> text is there mandatory anyways so anyone can see it with a pair
>> of binoculars.
> 
> Yes, but that is not even VLOS as you can't always see where the 
> number is.  With RID, it is RLOS.

I see.

It sounds like one would expect to query on the Internet the approach of
a flying object, like I informally look some times at flightradar24.
The great advantage is that I can query it from anywhere about anywhere.

For more formal identifications I would have suspected one would query
the object in a more direct manner.

Alex

> 
> Oh, and I have been told there are 'perfect' replica model planes. 
> For example it LOOKs just like a 737 even with binoculars.  But it
> is only 1000' feet away, not 30000'.
> 
>>> of the human mind to effect the degradation of freedom from 
>>> dangers. (Of course, the terms are not used as selectively in 
>>> practice in English either, e.g., “social security” is mostly 
>>> about safety.)
>>> 
>>> Grüße, Carsten
>>> 
>> 
> 
> -- 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, 7 Jul 2020 13:26:32 -0400

Alex,

I had 19 years automotive.  I lived through the 13 - 17 character VIN 
conversion.  This included the year 80 'crisis' (before yr2000, there 
was yr80, going from 1 digit to 2).  At AMC we had to run a number of 
systems in '81 on year 'A' and /only/ 1 in '82 on year 'B'.  I KNOW 
about VIN :)

On 7/7/20 12:03 PM, Alexandre Petrescu wrote:
>>>>> Scholar. In some Scandinavian languages, for
>>>> practice, we help ourselves by simply using the English terms when 
>>>> we need a more selective term.  If we are ever forced to actually 
>>>> speak German, we invent compound terms such as “Angriffssicherheit” 
>>>> (Security) and “Betriebssicherheit” (Safety).
>>>
>>> Greek for the name of a goddess of salvation), especially because he 
>>> cared about that, as he found the defenders to be very useful.
>>>
>>> That aside,
>>>

Exactly.  I *THINK* there is wording in the FAA NPRM of only one RID for 
a UA during an operation.

> paint is glued on one object.

As opposed to auto license plates that 'questionable' people attach with 
electro-magnets to drop the fake plate as needed?  :)

> the tail numbers apply to flying taxis.

Everything I have seen on UAM (Urban Air Mobility) has strict controls 
over them and this includes proper CAA registration and visible 'tail' 
numbers.

> plate standardised by a country regulator.

As I said, I lived this.  Also when we had to put the VIN visible 
through the front window and on the engine block and a plate in the 
driver door frame.  Happy to have that behind me.

> It thus seems that the tail number is like a license plate.

That is how many see it.

> I wonder whether there is a number in planes that is similar to the VIN

There is an airframe number that is standardized across the manned 
aircraft industry.  For UAS the proposal currently accepted is ANSI/CTA 
2063-A.  This presents challenges for DIY and researcher UA.

> The great advantage is that I can query it from anywhere about anywhere.

This is the whole UTM/Observer 'ecosystem'.  I have seen one 
demonstration.  What you can learn is controlled by authentication. 
Perhaps I can find out the RID of all UA over downtown San Fran, but 
with my geoloc in Detroit, even a safety officer SHOULD not be able to 
learn about the Operator of those UA.

> the object in a more direct manner.

No.  Not direct.  Over what link?  This is why there is the whole UTM 
system that Stu has shown in his slides.

But our plan for HHITs for RID does provide for a rather formal 
identification.  By receiving the Authentication Messages (see Adam's 
drafts on the proposed content), an Observer can 'trust' the Remote ID.  
I talk about this in the Security Considerations section of my 
drip-uas-rid draft.

>>>> practice in English either, e.g., “social security” is mostly about 
>>>> safety.)
>>>>
>>>> Grüße, Carsten
>>>>
>>>
>>

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 7 Jul 2020 13:50:24 -0400

Oops.  That was actually yr 80 and yr 81.  We DID not use 0 for yr80 as 
that was already in the history files for yr70...

What did we do for cars made prior to yr70?  I don't think we had any 
connected systems going that far back until much later.

On 7/7/20 1:26 PM, Robert Moskowitz wrote:
>>>>> speak German, we invent compound terms such as 
>>>>> “Angriffssicherheit” (Security) and “Betriebssicherheit” (Safety).
>>>>
> Exactly.  I *THINK* there is wording in the FAA NPRM of only one RID 
> for a UA during an operation.
>
>>
> As opposed to auto license plates that 'questionable' people attach 
> with electro-magnets to drop the fake plate as needed?  :)
>
>
>>
> aircraft industry.  For UAS the proposal currently accepted is 
> ANSI/CTA 2063-A.  This presents challenges for DIY and researcher UA.
>
>
>>
> drafts on the proposed content), an Observer can 'trust' the Remote 
> ID.  I talk about this in the Security Considerations section of my 
> drip-uas-rid draft.
>
>>
>> Alex
>>
>>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 8 Jul 2020 14:49:41 +0200

Le 07/07/2020 à 19:26, Robert Moskowitz a écrit :
> ANSI/CTA 2063-A

Thank you.

I downloaded it.

But it says "Unmanned", whereas a flying taxi would be manned even if 
that person would not control the flight.

Maybe they'll change the title of the document, or maybe the UAM 
inclined will invent a new ID for 'manned but not in control' or 
something like that.

Alex

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 8 Jul 2020 09:02:21 -0400

> inclined will invent a new ID for 'manned but not in control' or 

For now, ICAO sees UAM as Unmanned and will use the 2063 numbering 
scheme.  They are unmanned in the sense of no pilot on board.  If there 
IS a pilot on board, then they are manned aircraft and fall under those 
regulations and numbering. (actually I believe testing to date have been 
onboard pilot air taxis.)

ICAO (Saulo needs to join in) has augmented the paper certification 
process for manned aircraft with a digital process.  Manned flying taxis 
will be in this category unless a new one is created.

Then you get should a UAM, even manned participate in the Broadcast 
Remote ID messaging for safety purposes?  I would think so, but this is 
still really an unclear area.

definitely they will not participate in the automotive V2X ecosystem, 
despite conversations over on the ITS list.  Oh, they may listen in, but 
what messaging impacts them?

Bob

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 8 Jul 2020 16:54:04 +0200

> what messaging impacts them?

Can we expect an UAM vehicle to use 802.11-OCB mode (earlier known as 
802.11p) at 5.9GHz?

Or is it some other IP-able link layer technology?

Or is it a non-IP link?

Alex

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 8 Jul 2020 11:39:19 -0400

On 7/8/20 10:54 AM, Alexandre Petrescu wrote:
>>> But it says "Unmanned", whereas a flying taxi would be manned even 
>>> if that person would not control the flight.
>>>
>> scheme.  They are unmanned in the sense of no pilot on board.  If 
>> there IS a pilot on board, then they are manned aircraft and fall 
>> under those regulations and numbering. (actually I believe testing to 
>> date have been onboard pilot air taxis.)
>>
>> process for manned aircraft with a digital process.  Manned flying 
>> taxis will be in this category unless a new one is created.
>>
>> Remote ID messaging for safety purposes?  I would think so, but this 
>> is still really an unclear area.
>>
>> despite conversations over on the ITS list.  Oh, they may listen in, 
>> but what messaging impacts them?
>

I really doubt it.  I know a bit about 802.11-OCB.  I was active in 802 
when 802.11p was done and did some time on 1609 as well...

I suspect there will be a turf war if the CAAs try to get into the DoTs 
spectrum.  :)

Plus the ICAO is concerned about security and garden-walling airspace 
from most ground space.

So you either have LTE/5G, perhaps a private addressing/slice.  Or 
something down-frequency like 500 - 900 MHz like IEEE 802.16 (note the 
work being done on the PHYs there in TG 802.15.16t).  So I see more of a 
money fight between the 3GPP cellular companies and the private spectrum 
companies.

The private spectrum companies have a very strong case for managing who 
uses their spectrum and maintaining the 'mission critical' 
communication.  Do check out:

http://www.ieee802.org/15/pub/TG16t.html

Some of these frequencies have very good characteristics for this 
application.

For UAM, it SHOULD be an IP link, but if they go Sat, all bets are off, 
depending on the Sat company.

Bob

---

From: "Stuart W. Card" <[email-masked]>
Date: Wed, 8 Jul 2020 11:49:24 -0400

Thanks Amelia for your informative & entertainingly written review, and
everyone else for your contributions!

I am attempting to address all points with revisions...

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 9 Jul 2020 09:02:24 +0200

Hi, Bob,

Le 08/07/2020 à 17:39, Robert Moskowitz a écrit :
[...]
> So you either have LTE/5G, perhaps a private addressing/slice.

Interesting.

Loon did put, apparently, 4G base stations in high altitude balloons, in
South America.  These could be used to talk to flying devices including
UAM vehicles and such multicopters.

ESA (European Space Agency) does pursue actively 5G plans.

However, there could be doubts about the whole concept of using 5G in a
UAM vehicle (flying taxi) for simple reaons such as antenna placement,
orientation and coverage.

> Or something down-frequency like 500 - 900 MHz like IEEE 802.16
> (note the work being done on the PHYs there in TG 802.15.16t).

Interesting.

An 802.15.* PAN (Personal) proposed at UHF and VHF hundred km ranges
sounds so.

In such a frequency range, one could also think about DVB-T
modifications (Digital Video Broadcast - Terrestrial).  The
flightradar24.com tracks regular airline flights also by proposing a
DVB-T USB key that enthusiasts could help with.

These dongles receive presence data from these planes.
https://www.flightradar24.com/build-your-own

They call it "ADS-B Receivers" (Automatic Dependent Surveillance -
Broadcast).

I wouuld like to ask if there is a packet dump available showing such
presence data form planes?  Maybe wireshark already supports it, maybe
it even dissects it.

Maybe this 802.15.16t Licensed narrowband for mission critical entities
would compete with that ADS-B concept.

At that point, one could think about using IP-over-ADS, or
IP-over-802-15-16t, and so there could be a resolution.

> So I see more of a money fight between the 3GPP cellular companies 
> and the private spectrum companies.
> 
> The private spectrum companies have a very strong case for managing 
> who uses their spectrum and maintaining the 'mission critical' 
> For UAM, it SHOULD be an IP link, but if they go Sat, all bets are 
> off, depending on the Sat company.

Sattelite communications for UAM vehicles such as flying taxis could
indeed be useful, even though it might increase their cost.

But, if it is an IP link, I suspect I must look closer at the DRIP
message formats and see whether they could be transmitted on these IP links.

Finally, as you might notice, I might have an interest for UAM
vehicles such as manned-but-not-in-control air taxis (VoloCopter, Geely,
Lilium, Kitty Hawk, Ehang, Link&Fly, Kitty Hawk Cora, Cezeri, Hyundai
Uber flying taxi at CES 2020), and for broadcasting over IP their
presence information.  This is a little bit different than DNS and
presence advertisement over the Internet, even though it is on IP.  I
will have to read the drafts of DRIP.

Alex

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 9 Jul 2020 07:45:02 -0400

> An 802.15.* PAN (Personal) proposed at UHF and VHF hundred km ranges

This was a bit of 802 exec committee procedure...

802.16 is in hibernation.  802ec did not want to reactivate it with all 
the admin costs for this PAR, so they stuffed it on the 802.15 workgroup 
to run it.  It is still an addendum to 802.16, just being done under 
802.15 administration.

:)

> presence data form planes?  Maybe wireshark already supports it, maybe

Over in EU, ask AirBus.  Or our IETF Boeing colleagues.  Thing is there 
are LOTs of different datastreams from aircraft.  One of the goals in 
the move to IPv6 is to comminize the communications and simplify the 
ground (and plane) costs.

> IP-over-802-15-16t, and so there could be a resolution.

There are a number of recognized problems with ADS-B.  I am not 
connected at all to see how thes may be addressed.  I don't even have a 
clear list, I only hear complaints.  Definitely the lack of security is 
critical.  Maybe they need MLS?

> message formats and see whether they could be transmitted on these IP 

DRIP message formats, as such are based on ASTM F3411-19 which is 
designed to work over BT4 beacons (27 bytes).  The Auth message is 10 of 
these, or 256 bytes of payload.

Most C2 messaging is also small data payloads.

> will have to read the drafts of DRIP.

F3411-19 has the Location/Vector message.  It has a couple flaws that 
will be addressed in the next? release.  One is they left out altitude.  
FAA wants this in barometric to match manned aircraft, not GPS 
altitude.  This could cause problems dodging buildings (though probably 
internally the UA would have both).  I remember reading of an incident 
during WWII in the DC3 supply flights to China over the Himalayas.  One 
DC3 crew that crashed because barometric altitude does not match 
mountain elevation (hidden in the clouds), managed to remove their cargo 
door and tobogganed down the mountain on it...

My drip-operator-privacy draft addresses the privacy concerns with these 
messages.

Any UA could be sending these messages via broadcast.  The carrier RF 
options currently are:  BT4&5 and 802.11NAN.  I see the 802.11bc as 
another, future, option.  Thus any ground system can receive them and 
'know' what is overhead.  See my crowd-sourced draft.

Bob

---

From: "Da Silva, Saulo" <[email-masked]>
Date: Thu, 9 Jul 2020 14:51:43 +0000

You mentioned my name, so, some comments below your notes.
Saulo

-----Original Message-----
From: Tm-rid <[email-masked]> On Behalf Of Robert Moskowitz
Sent: 8-Jul-20 9:02 AM
To: Alexandre Petrescu <[email-masked]>
Cc: [email-masked]
Subject: Re: [Tm-rid] Review of draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and other

> inclined will invent a new ID for 'manned but not in control' or 

Saulo: We call them autonomous.

For now, ICAO sees UAM as Unmanned and will use the 2063 numbering scheme.  They are unmanned in the sense of no pilot on board.  If there IS a pilot on board, then they are manned aircraft and fall under those regulations and numbering. (actually I believe testing to date have been onboard pilot air taxis.)

ICAO (Saulo needs to join in) has augmented the paper certification process for manned aircraft with a digital process.  Manned flying taxis will be in this category unless a new one is created.

Saulo: I don’t know wat you call "augmented paper certification" but whatever a vehicle is called "aircraft" it requests airworthiness certification, be it manned or unmanned and on the unmanned we may also have the autonomous category (no pilot onboard or on the ground) ones.

Then you get should a UAM, even manned participate in the Broadcast Remote ID messaging for safety purposes?  I would think so, but this is still really an unclear area.

Saulo: As of today's developments , without having the regulations to cover it, the answer is yes.

definitely they will not participate in the automotive V2X ecosystem, despite conversations over on the ITS list.  Oh, they may listen in, but what messaging impacts them?

Saulo: Agree.

Bob

--
Tm-rid mailing list
[email-masked]
https://secure-web.cisco.com/1fVCI0d3ZjaRLYOqMoz20_QhDktYXzfHlKy6CLfTnv4KFnaZHu9HTvyETH-VA66yy-K1D3aWSetch81R8oetV7bN_1Gd9cxec72BWZpzMStE8jhFkE7FyW8BbZ7A8FQhrnu1jfxZLbtqsp2QjM5iSAjepvmNvstZz4eg4JOpwV-9XmxZpjKbithNlUzs4-WR2CfjyYnz9fINzZExnw-gcxVjcnwQX9F6hFGG_kUV1Yzuadz3QbQWgtNmAbawrxaPlIrF725lXvPPHkaRRcjlLkdK_8l0QE82tGwPOF_sGF54vD20ee1VofYgXwiE5472dpqKMlOgqccgTn7qjXO2XLA/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftm-rid

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 9 Jul 2020 18:04:47 +0200

Le 09/07/2020 à 16:51, Da Silva, Saulo a écrit :
> You mentioned my name, so, some comments below your notes. Saulo
> 
> -----Original Message----- From: Tm-rid <[email-masked]> On
> Behalf Of Robert Moskowitz Sent: 8-Jul-20 9:02 AM To: Alexandre
> Petrescu <[email-masked]> Cc: [email-masked] Subject:
> Re: [Tm-rid] Review of draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and
> other
> 
> 
> 
> scheme.

Noted, thank you.

I will check the 2063 numbering scheme from the freely available 
document ANSI/CTA 2063-A (free, hm, but very unfriendly to privacy 
because it requests my postal address at work).

>  They are unmanned in the sense of no pilot on board.

YEs, but note how difficult is it to understand.

UAM - U means Urban
UAV - U means Unmanned

Unmanned - there is no Pilot onboard but there could be a journalist 
with no pilot skill, like in the ehang demo of a year ago or so.

Alex

   If
> Saulo: I don’t know wat you call "augmented paper certification" but
> whatever a vehicle is called "aircraft" it requests airworthiness
> certification, be it manned or unmanned and on the unmanned we may
> also have the autonomous category (no pilot onboard or on the ground)
> ones.
> 
> -- Tm-rid mailing list [email-masked]

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 9 Jul 2020 12:33:52 -0400

> YEs, but note how difficult is it to understand.

TLDs, ya just got to love it...  :)

> with no pilot skill, like in the ehang demo of a year ago or so.

SOMEONE has to be onboard, or it is not a 'taxi'.  :)

Unmanned means no LICENSED pilot in control.

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 9 Jul 2020 13:28:30 -0400

> Saulo: I don’t know wat you call "augmented paper certification" but whatever a vehicle is called "aircraft" it requests airworthiness certification, be it manned or unmanned and on the unmanned we…

It is my thought of the slide deck Mike Goodfellow (of ICAO for the rest 
here) shared with me on the IATF X.509 work.  It shows the 'old' paper 
system for certifying an airframe and registering it and how that is 
input to the new digital registration process.  So the old paper system 
is 'augmented' with digital components, but still, for the most part, 
the same process.

> definitely they will not participate in the automotive V2X ecosystem, despite conversations over on the ITS list.  Oh, they may listen in, but what messaging impacts them?

Perhaps ICAO should check in on the IETF ITS list and add some 
perspective there?  They are going down a road where they are designing 
for including UAM into the V2X framework.  I really can't fault them too 
much, as I have seen many position papers on the interaction between 
urban ground systems and air systems...

---

From: "Stuart W. Card" <[email-masked]>
Date: Wed, 29 Jul 2020 22:45:33 -0400

Sorry for the slow reply.

ADS-B is gradually being mandated for essentially all manned aircraft.

ADSB-In and ADSB-Out are mandated for airliners: -In gives their pilots
some Situational Awareness (SA) of other aircraft; -Out gives other
pilots SA of the airliners.

"ADSB-Out" is mandated even for small general aviation aircraft: it does
not directly benefit the pilots of those aircraft; but by providing SA
to others, it indirectly benefits all.

ADSB is _not_ going to be deployed on large numbers of small UAS as it
would overwhelm the limited bandwidth available at those lower radio
frequencies (which propagate long ranges). In fact, it is expected to be
explicitly prohibited in the US per the FAA NPRM; I suspect most of the
rest of the world will do likewise.

ADSB is also altogether insecure.

On 7/9/2020 3:02 AM, Alexandre Petrescu wrote:
> ...
> it even dissects it...

---

From: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Thu, 30 Jul 2020 09:49:04 +0000

Just to echo Stu on the ADSB, AFAIK, ADSB will  not be feasible for most of the drones mostly due to SwaP, commercial drones might be exception.

Best,
Shuai Zhao

From: Tm-rid <[email-masked]> on behalf of "Stuart W. Card" <[email-masked]>
Date: Wednesday, July 29, 2020 at 19:46
To: "[email-masked]" <[email-masked]>
Subject: [Drip] ADSB (was: Review of draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and other)(Internet mail)

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 30 Jul 2020 06:22:53 -0400

By "commercial drones" do you mean what a delivery service would use or 
a long-haul freight (Rhaegal) and air-taxis (UAM)?

On 7/30/20 5:49 AM, shuaiizhao(Shuai Zhao) wrote:
>
> Just to echo Stu on the ADSB, AFAIK, ADSB will  not be feasible for 
> most of the drones mostly due to SwaP, commercial drones might be 
> exception.
>
> Best,
>
> Shuai Zhao
>
> *From: *Tm-rid <[email-masked]> on behalf of "Stuart W. Card" 
> <[email-masked]>
> *Date: *Wednesday, July 29, 2020 at 19:46
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[Drip] ADSB (was: Review of draft-drip-arch-02 w.r.t. 
> RFC6973, RFC8280 and other)(Internet mail)
>

---

From: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Thu, 30 Jul 2020 10:43:15 +0000

Yes, as well as drones with military purpose,  that’s my understanding.

-SZ iPhone
Please forgive any typos

On Jul 30, 2020, at 03:23, Robert Moskowitz <[email-masked]> wrote:

 By "commercial drones" do you mean what a delivery service would use or a long-haul freight (Rhaegal) and air-taxis (UAM)?

Best,
Shuai Zhao

From: Tm-rid <[email-masked]><mailto:[email-masked]> on behalf of "Stuart W. Card" <[email-masked]><mailto:[email-masked]>
Date: Wednesday, July 29, 2020 at 19:46
To: "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: [Drip] ADSB (was: Review of draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and other)(Internet mail)

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

--
Robert Moskowitz
Owner
HTT Consulting
C:      248-219-2059
F:      248-968-2824
E:      [email-masked]<mailto:[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: Thu, 30 Jul 2020 06:48:27 -0400

Shuai,

That was an 'or' question.  My bad.

I don't see urban delivery UA, even rural (I have seen the UPS demo) 
using ADSB.  I even question air-taxis, other than if they want to make 
runs to the airport, they will probably require it.

Local delivery UA are already so power starved, severely impacting their 
range (why UPS has them serviced from their trucks).

On 7/30/20 6:43 AM, shuaiizhao(Shuai Zhao) wrote:
>>  By "commercial drones" do you mean what a delivery service would 
>> use or a long-haul freight (Rhaegal) and air-taxis (UAM)?
>>
>>> *From: *Tm-rid <[email-masked]> on behalf of "Stuart W. 
>>> Card" <[email-masked]>

---

From: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Thu, 30 Jul 2020 10:53:47 +0000

It is really hard to foresee the future.

Personally, I don’t think FAA  (in NA) will let the air-taxi going into an airport for taking or landing. But we never know. That is also the reason I think the Crowd source draft has much more weight than everyone else thinks. It might be a good alternative compared with ADS-B since those UA operations might not be as critical as GA.

Best,
Shuai Zhao

From: Robert Moskowitz <[email-masked]>
Date: Thursday, July 30, 2020 at 03:48
To: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Stuart W. Card" <[email-masked]>
Subject: Re: [Drip] ADSB(Internet mail)

Shuai,

I don't see urban delivery UA, even rural (I have seen the UPS demo) using ADSB.  I even question air-taxis, other than if they want to make runs to the airport, they will probably require it.

Local delivery UA are already so power starved, severely impacting their range (why UPS has them serviced from their trucks).
On 7/30/20 6:43 AM, shuaiizhao(Shuai Zhao) wrote:
Yes, as well as drones with military purpose,  that’s my understanding.
-SZ iPhone
Please forgive any typos

On Jul 30, 2020, at 03:23, Robert Moskowitz <[email-masked]><mailto:[email-masked]> wrote:
By "commercial drones" do you mean what a delivery service would use or a long-haul freight (Rhaegal) and air-taxis (UAM)?
On 7/30/20 5:49 AM, shuaiizhao(Shuai Zhao) wrote:
Just to echo Stu on the ADSB, AFAIK, ADSB will  not be feasible for most of the drones mostly due to SwaP, commercial drones might be exception.

Best,
Shuai Zhao

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 30 Jul 2020 07:00:03 -0400

We need to take the crowd source draft to the next step and define the 
actual protocol.  Target that for the August Interim.

On 7/30/20 6:53 AM, shuaiizhao(Shuai Zhao) wrote:
> Standard
> Personally, I don’t think FAA  (in NA) will let the air-taxi going 
> into an airport for taking or landing. But we never know. That is also 
> the reason I think the Crowd source draft has much more weight than 
> everyone else thinks. It might be a good alternative compared with 
> ADS-B since those UA operations might not be as critical as GA.
>
> Best,
>
> Shuai Zhao
>
> *From: *Robert Moskowitz <[email-masked]>
> *Date: *Thursday, July 30, 2020 at 03:48
> *To: *"shuaiizhao(Shuai Zhao)" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "Stuart W. Card" 
> *Subject: *Re: [Drip] ADSB(Internet mail)
>
> Shuai,
>
> using ADSB.  I even question air-taxis, other than if they want to 
> make runs to the airport, they will probably require it.
>
> Local delivery UA are already so power starved, severely impacting 
> their range (why UPS has them serviced from their trucks).
>
>         On Jul 30, 2020, at 03:23, Robert Moskowitz
>         <[email-masked]> <mailto:[email-masked]>
>         wrote:
>
>         By "commercial drones" do you mean what a delivery service
>         would use or a long-haul freight (Rhaegal) and air-taxis (UAM)?
>
>             Just to echo Stu on the ADSB, AFAIK, ADSB will  not be
>             feasible for most of the drones mostly due to SwaP,
>             commercial drones might be exception.
>
>             Best,
>
>             Shuai Zhao
>
>             *From: *Tm-rid <[email-masked]>
>             <mailto:[email-masked]> on behalf of "Stuart W.
>             <mailto:[email-masked]>
>             *To: *"[email-masked]" <mailto:[email-masked]>
>             <[email-masked]> <mailto:[email-masked]>
>             *Subject: *[Drip] ADSB (was: Review of draft-drip-arch-02
>             w.r.t. RFC6973, RFC8280 and other)(Internet mail)
>
>             <http://www.axenterprize.com>
>
>         E: [email-masked] <mailto:[email-masked]>
>
> E: [email-masked] <mailto:[email-masked]>
>

---

From: "Jarvenpaa, Mika (Nokia - FI/Espoo)" <[email-masked]>
Date: Thu, 30 Jul 2020 12:29:14 +0000

Maybe known info but sending anyway.

Here couple of (a bit random) articles giving some background and reasoning of ’ADS-B in’ for drones and ’ADS-B in/out’ for manned planes plus pros and cons from the different view points (like manned crop spraying plane retrofit case too; similar things in EU about the huge costs for getting ADS-B out to manned airplanes over 5700 kg where mandated).

’ADS-B in’ can be seen only as a nice to have feature on drones, but it won’t solve the issue, it can even give false safety feeling.

’ADS-B out’ won’t be installed / on board / used on all low flying / slow / small European and US manned helicopters, balloons, lightweight planes, gliders, paragliders etc. (in uncontrolled airspace) anytime soon. Also many emergency and military helicopters don’t broadcast their location because of privacy/security issues (eg. press and audience not wanted to emergency scenes).

RID type but secure way of ’sending’ location info would allow other (low flying) manned / unmanned aircrafts to sense and avoid too (when able to receive networked or broadcast info). Maybe ’ADS-B out’ could still be mandated for high flying / fast / heavy UAVs and/or air taxis for some regions for some operations if the volume stay low and limited connectivity or no better way available.

https://www.suasnews.com/2017/05/battle-drone-tracking-technology/

https://www.techradar.com/news/should-you-buy-a-dji-mavic-air-2-without-the-airsense-alert-system

https://www.agaviation.org/2016-first-place-essay

https://sky-review.com/ads-b-philosophy-for-drones

https://uavionix.com/drone-repellent/

EU timeline delayed:
https://www.aviationtoday.com/2020/05/05/ads-b/
https://www.easa.europa.eu/newsroom-and-events/news/entry-force-airspace-requirement-ads-b-and-mode-s
https://www.easa.europa.eu/sites/default/files/dfu/EASA_STC_NEWS_JUNE_2018.pdf

FAQs about certification on manned side:
https://www.easa.europa.eu/the-agency/faqs/ads-b-certification

Mika

________________________________
Lähettäjä: Tm-rid <[email-masked]> käyttäjän Robert Moskowitz <[email-masked]> puolesta
Lähetetty: torstaina, heinäkuuta 30, 2020 2:00 ip.
Vastaanottaja: Zhao, Shuai (UMKC-Student)
Kopio: [email-masked]; Stuart W. Card
Aihe: Re: [Drip] ADSB(Internet mail)

We need to take the crowd source draft to the next step and define the actual protocol.  Target that for the August Interim.

Best,
Shuai Zhao

From: Robert Moskowitz <[email-masked]><mailto:[email-masked]>
Date: Thursday, July 30, 2020 at 03:48
To: "shuaiizhao(Shuai Zhao)" <[email-masked]><mailto:[email-masked]>
Cc: "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, "Stuart W. Card" <[email-masked]><mailto:[email-masked]>
Subject: Re: [Drip] ADSB(Internet mail)

Shuai,

Best,
Shuai Zhao