Subject: Re: [Drip] ADSB

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 4 Aug 2020 15:44:06 +0200

Le 30/07/2020 à 04:45, Stuart W. Card a écrit :
> 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).

Thanks for the clarification of what is ADSB-In and -Out.

It makes think that ADSB-Out might be a good candidate link layer
technology, on which one might put IP Router Advertisements.

About the risk of overwhelming a bandwidth: true, drones are smaller
than planes, and as such they might be much more numerous in a same
given volume and so, intuititvely, they might be too many and so create
a bottleneck.

However, that might happen at a layer below IP (PHY or MAC), that is not
an IETF layer.  At the IETF layers there are some mechanisms to allow
for avoiding of these bottlenecks.  There are many computers on the
Internet overall and they dont interfere with each other.  Drones could
also be part of it if IETF layers were used.

> 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.

Noted the insecurity of ADS-B.

And noted the potential prohibition of ADS-B in drones, by FAA NPRM and 
potentially others.

Alex

> 
> On 7/9/2020 3:02 AM, Alexandre Petrescu wrote:
>> ... 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...
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 4 Aug 2020 15:52:55 +0200

architectural layers discussion...

Le 30/07/2020 à 11:49, shuaiizhao(Shuai Zhao) a écrit :
> 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.

It might be that ADS-B might be forbidden in drones on Earth, but how
about the drones on Mars? ('NASA Mars helicopters', or ESA too).  On
Mars there would be much less such drones, so less risk of interference.

With such a system (ADS-B under IP) one could re-use DTN (Delay Tolerant
Networking) between planets, and so identify drones even on Mars.

But if we have reluctance about the use of ADS-B, and thus of IP, and we
recommend Bluetooth-without-IP to identify drones, then we might become
too dependent on it?

(do not get me wrong, I do like Bluetooth, but I like many other things
together with Bluetooth).

Alex

> 
> 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)
> 
> pilots
> some Situational Awareness (SA) of other aircraft; -Out gives other
> 
> pilots SA of the airliners.
> 
> does
> not directly benefit the pilots of those aircraft; but by providing
> SA
> 
> to others, it indirectly benefits all.
> 
> 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.
> 
> ...
> They call it "ADS-B Receivers" (Automatic Dependent Surveillance -
> 
> Broadcast).
> 
> such
> presence data form planes?  Maybe wireshark already supports it,
> maybe
> 
> it even dissects it...
> 
> --
> 
> -----------------------------------------
> 
> Stuart W. Card, PhD, Principal Engineer
> 
> AX Enterprize, LLC  www.axenterprize.com
> 
> 4947 Commercial Drive, Yorkville NY 13495
> 
>

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 4 Aug 2020 15:16:36 +0000

Alexandre,

ADS-B is a 20+ year old technology and offers properties (bandwidth, security, cost) of a 20 year old technology.  That it just recently sees widespread adoption is a result of incredibly slow (even by IETF standards) deployment process, and that in turn is the result of the very conservative and safety conscious aviation community and regulators, as well as the high cost related to anything manmade that flies.  By speculating to use ADS-B as an underlying technology for IP, I fear you demonstrate a certain lack of background.  The Wikipedia article on ADS-B (https://en.wikipedia.org/wiki/Automatic_dependent_surveillance_–_broadcast) is mostly correct, and I recommend in particular the sections on "Theory of operation" and "System Design Considerations".

A few (of many) reasons why ADS-B is unsuitable for light drones (anything significantly smaller than a man-carrying aircraft):
-24 bit ICAO transponder code, limiting the number of (active or inactive) ADS-B equipment.  Each modern aircraft over a certain size (except the smallest two-seaters, powered parachutes, and aircraft without electrical systems such as antiques) has a unique code assigned for its lifetime.
-line-of-sight wireless connection for the "uplink" with only a few hundred ground stations for the whole US (or 70 for the whole Australia).  That means ADS-B coverage is almost everywhere only available at altitudes in which small drones are neither legal nor, in most cases, physically capable to fly (a few thousand feet in the US except near major airports where you don't want drones, 30000 ft in Australia).  Aircraft send over the uplink information such as aircraft ICAO code, aircraft type, speed, direction of flight, altitude, etc.).  Information is sent in the clear, by design.  You can buy a box receiving this info, hook it up to an Raspberry PI or something, and look at the traffic near your house and send it on to your friends--in fact, this type of crowdsourced ATC info is what makes flightradar24 and similar sites work.
-the downlink (system to aircraft) is bandwidth-limited to a few hundred kbit/s for all aircraft combined in the coverage of the satellite transponder.  (This is somewhat over-simplified, as the uplink is intentionally sent in the clear, and many ADS-B receivers monitor the uplink of other aircraft for redundancy and more up-to-date information about traffic; see abive.)  AFAIK, the whole continental US is covered by less than 20 transponders. N The downlink carries not only traffic information but also cruise and airport weather, certain airspace restrictions, and so forth.  All this is broadcasted and the ADS-B receivers in the aircraft need to filter out the information relevant for its position, course, and intentions.  Already, the bandwidth available is almost fully utilized to the point that the broadcast occasionally needs to omit certain less-critical information to make space for more critical one.  The system scales only by adding satellite transponders, which is expensive and not a fine granularity.

As for Mars, ADS-B is unsuitable until someone builds a ground-station network and has suitable satellites in orbit.  A bit closer to earth, for over-water and trans-pole operations there is ADS-C, which is completely satellite based and, AFAIK, even more bandwidth limited than ADS-B.  Yet another example for a network unsuitable to carry IP traffic, but I digress.

In short, forget ADS-B for the DRIP work..

Stephan

On 8/4/20, 6:53 AM, "Tm-rid on behalf of Alexandre Petrescu" <[email-masked] on behalf of [email-masked]> wrote:

    Alex

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

---

From: "Stuart W. Card" <[email-masked]>
Date: Tue, 4 Aug 2020 11:17:06 -0400

I just want to respond to one line that I think comes from confusion:

> But if we have reluctance about the use of ADS-B, and thus of IP, 
> and we recommend Bluetooth-without-IP to identify drones

We aren't recommending Bluetooth-without-IP, we are _supporting_ it, as
it is specified in ASTM F3411, which most of the regulators are dubbing
as an approved technical means of regulatory compliance.

AFAIK, no one runs IP over ADS-B, which was designed as a narrowband
application specific communications stovepipe, not a data link
supporting higher layer network protocols, so not great for IP.

More importantly, we have no "reluctance about the use of... IP", which
is an entirely separate issue from ADS-B.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 4 Aug 2020 17:27:44 +0200

Thanks for the clarification.

Le 04/08/2020 à 17:17, Stuart W. Card a écrit :
> We aren't recommending Bluetooth-without-IP, we are _supporting_ it,

But, the security manifest that I have seen on slides during the 
presentation of the DRIP WG meeting - is something below IP, right?

Alex

  as

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 4 Aug 2020 11:51:03 -0400

> presentation of the DRIP WG meeting - is something below IP, right?

For now, we are dealing with broadcast messages.  Either over Bluetooth 
or WiFI (NAN).  There is NO security for the messages below the message 
package.  Just not enough payload size for anything that would work in a 
broadcast environment like a National Airspace.  All of the security we 
are specifying is inside the messages where appropriate.

That security manifest is a payload of the ASTM F3411-19 Authentication 
Message.  These messages are broadcasted as Adam mentioned in his 
'flying DRIP' comments at the beginning.

Now later I expect us to move on to Network Remote ID and Command and 
Control (C2).

Most C2 (e.g. Mavlink) is directly over the MAC, but there is a method 
to run it over UDP (I forget the UDP port commonly used...). AX 
Enterprize has done this using HIP so the UA starts with WiFi over the 
launch point, transitions to LTE, and on return back to WiFi.

Network Remote ID can work either directly from the UA, or via C2 
information to the GCS, from the GCS.  In either case, IP is assumed.  
This will probably be done via UDP.  From the UA, mobility will be 
important; from the GCS nice to have (most GCS will be stable 
location).  As UDP to a fixed Net-SP, DTLS 1.3 is a viable alternative 
to HIP.

>>> and we

-- 
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, 4 Aug 2020 11:53:19 -0400

> presentation of the DRIP WG meeting - is something below IP, right?

Oh, and for Network Remote ID and C2 see my draft:

draft-moskowitz-drip-secure-nrid-c2

---

From: "Stuart W. Card" <[email-masked]>
Date: Tue, 4 Aug 2020 13:11:52 -0400

The proposed manifest and other DRIP authentication related structures
are all independent of transport, but designed to work with the most
constraining transport thus specified by regulators and/or other SDOs,
that being ASTM F3411 Broadcast RID over Bluetooth 4.

So, for Broadcast RID, they would be encapsulated in ASTM F3411 messages
over Bluetooth 4, Bluetooth 5 or WiFi Neighbor Awareness Networking
(without IP).

For Network RID, they could be carried in any IP based transport,
HTTPS/TCP/IP initially (although, for Network RID, some of them are
superfluous).

---

From: <[email-masked]>
Date: Wed, 5 Aug 2020 09:13:29 +0000

Hi Stu, 

I remember that Andrei raised in the past a question about the use of ADB-S. I suspect that others may make a similar comment in the future.
Having some text in draft-ietf-drip-arch reflecting the main arguments shared in this thread (by Shuai, Bob, Stephan, you) will be useful. 

Can you please consider adding such text to the draft? 

Thank you. 

Cheers,
Med

> -----Message d'origine-----
> De : Tm-rid [mailto:[email-masked]] De la part de Stuart W.
> Card
> Envoyé : mardi 4 août 2020 19:12
> À : [email-masked]
> Objet : Re: [Drip] ADSB
> 
> So, for Broadcast RID, they would be encapsulated in ASTM F3411
> messages over Bluetooth 4, Bluetooth 5 or WiFi Neighbor Awareness
> Networking (without IP).
> 

_________________________________________________________________________________________________________________________

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.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 5 Aug 2020 11:53:28 +0200

Stephan,

Le 04/08/2020 à 17:16, Stephan Wenger a écrit :
> Alexandre,
> 
> ADS-B is a 20+ year old technology and offers properties (bandwidth,
>  security, cost) of a 20 year old technology.  That it just recently
>  sees widespread adoption is a result of incredibly slow (even by
> IETF standards) deployment process, and that in turn is the result of
> the very conservative and safety conscious aviation community and 
> regulators, as well as the high cost related to anything manmade
> that flies.  By speculating to use ADS-B as an underlying technology
> for IP, I fear you demonstrate a certain lack of background.  The 
> Wikipedia article on ADS-B 
> (https://en.wikipedia.org/wiki/Automatic_dependent_surveillance_–_broadcast)
>
>
>
> 
is mostly correct, and I recommend in particular the sections on
> "Theory of operation" and "System Design Considerations".

There is no worry to fear I demonstrate lack of background in this
field.  It is true.  I still need to learn many things here.

I continue to look for a wireless link layer that is well adapted
for communication between flying devices (drones, flying taxis) and
ground.  And that would support very well IP.

Maybe ADS-B is not that link, but Bluetooth isnt it either because too
low power.

Maybe WiFi at 5.4GHz, which also used for remote control.

That aside, let me try to answer some of the points below.

> A few (of many) reasons why ADS-B is unsuitable for light drones 
> (anything significantly smaller than a man-carrying aircraft): -24 
> bit ICAO transponder code, limiting the number of (active or 
> inactive) ADS-B equipment.  Each modern aircraft over a certain size
>  (except the smallest two-seaters, powered parachutes, and aircraft 
> without electrical systems such as antiques) has a unique code 
> assigned for its lifetime.

Ok.  But MAC addresses of Bluetooth also are limited.  They have 48bit
which is more than 24bit of ADS-B, but it is still limited.

> -line-of-sight wireless connection for the "uplink" with only a few 
> hundred ground stations for the whole US (or 70 for the whole 
> Australia).  That means ADS-B coverage is almost everywhere only 
> available at altitudes in which small drones are neither legal nor, 
> in most cases, physically capable to fly (a few thousand feet in the 
> US except near major airports where you don't want drones, 30000 ft 
> in Australia).  Aircraft send over the uplink information such as 
> aircraft ICAO code, aircraft type, speed, direction of flight, 
> altitude, etc.).  Information is sent in the clear, by design.  You 
> can buy a box receiving this info, hook it up to an Raspberry PI or 
> something, and look at the traffic near your house and send it on to 
> your friends--in fact, this type of crowdsourced ATC info is what 
> makes flightradar24 and similar sites work.

This sounds like an argument in favor of using ADS-B for identification,
not against.  Or maybe I dont understand.

Only a few ground stations: I suspect this is around airport areas,
which is good.

ADS-B messages sent by the ground stations only to altitudes where
drones are forbidden (I suspect above 150m or so): I dont think it is
possible to restrict the altitude at which a message is sent to.  It
would be impossible for an ADS-B message sent by a ground station to not
be heard at 100meters and only be heard at 200meters.  Or I do not
udnertsand.

Planes that send ADS-B messages over the 'uplink'.  I think I have to
understand this better.  Until now I thought 'uplink' means a direction
from ground to up in the sky.  It is a distinct meaning than networking.

In networking, a smartphone has an uplink, but the base-station also has
an uplink.  One's uplink is the other's downlink.  Compared to that, I
thought that in ADS-B the 'uplink' is only from ground up, but it seems
to not be so.

> -the downlink (system to aircraft)

Again, I thought the 'downlink' is from the plane down to ground.   You
seem to say it reversely.

I think the notion of 'uplink' and 'downlink' are with respect to a
device.  A device's uplink  is the other device's downlink, when they
communicate with each other.

> is bandwidth-limited to a few hundred kbit/s for all aircraft 
> combined in the coverage of the satellite transponder.  (This is 
> somewhat over-simplified, as the uplink is intentionally sent in the 
> clear, and many ADS-B receivers monitor the uplink of other aircraft 
> for redundancy and more up-to-date information about traffic; see 
> abive.)  AFAIK, the whole continental US is covered by less than 20 
> transponders. N The downlink carries not only traffic information
> but also cruise and airport weather, certain airspace restrictions,
> and so forth.  All this is broadcasted and the ADS-B receivers in
> the aircraft need to filter out the information relevant for its 
> position, course, and intentions.  Already, the bandwidth available 
> is almost fully utilized to the point that the broadcast
> occasionally needs to omit certain less-critical information to make
> space for more critical one.  The system scales only by adding
> satellite transponders, which is expensive and not a fine
> granularity.

I agree there might be bandwidth limitation that needs to be respected.

It still is that putting an IP message on it can still work.

> As for Mars, ADS-B is unsuitable until someone builds a 
> ground-station network and has suitable satellites in orbit.

YEs, the ground station would be on the rover and the satellite would
be on one of the stations (I dont know their names) that currently hover
above Mars routinely.

> A bit closer to earth, for over-water and trans-pole operations
> there is ADS-C, which is completely satellite based and, AFAIK, even
> more bandwidth limited than ADS-B.  Yet another example for a network
>  unsuitable to carry IP traffic, but I digress.
> 

Ok, if no ADS-B for DRIP work, then Bluetooth?  Is it more appropriate?

Knowing that Bluetooth has a typical range of 10meter (I mean distance
range), is it reasonable to rely on it for identifying drones at
several hundred meters away?

Knowing that Bluetooth is lower power than WiFi at 5.4Ghz, and that that
5.4GHz is already used to control drone flight, video, etc, is it
preferrable to use Bluetooth instead of that WiFi at 5.4GHz?

Alex

> 
> Stephan
> 
> 
> On 8/4/20, 6:53 AM, "Tm-rid on behalf of Alexandre Petrescu" 
> <[email-masked] on behalf of [email-masked]> 
> 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.
> 
> It might be that ADS-B might be forbidden in drones on Earth, but
> how about the drones on Mars? ('NASA Mars helicopters', or ESA too).
> On Mars there would be much less such drones, so less risk of 
> interference.
> 
> With such a system (ADS-B under IP) one could re-use DTN (Delay 
> Tolerant Networking) between planets, and so identify drones even on
>  Mars.
> 
> But if we have reluctance about the use of ADS-B, and thus of IP, and
> we recommend Bluetooth-without-IP to identify drones, then we might
> become too dependent on it?
> 
> (do not get me wrong, I do like Bluetooth, but I like many other 
> things together with Bluetooth).
> 
> Alex
> 
>> 
>> Best,
>> 
>> Shuai Zhao
>> 
>> 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)
>> 
>> "ADSB-Out" is mandated even for small general aviation aircraft:
>> it does
>> 
>> not directly benefit the pilots of those aircraft; but by
>> providing SA
>> 
>> ADSB is _not_ going to be deployed on large numbers of small UAS
>> as it
>> 
>> 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
>> 
> -- Tm-rid mailing list [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 5 Aug 2020 12:11:33 +0200

Le 04/08/2020 à 17:51, Robert Moskowitz a écrit :
>>>> But if we have reluctance about the use of ADS-B, and thus of 
>>>> IP, and we recommend Bluetooth-without-IP to identify drones
>>> 
> For now, we are dealing with broadcast messages.  Either over 
> Bluetooth or WiFI (NAN).

If it is a broadcast message and it is over Bluetooth or over WiFi then 
it certainly is IP multicast, cant be anything else.

If it is IP multicast over Bluetooth or over WiFi then I wonder what is
the value  in the Next Header field of the IP header format (RFC8200
"IPv6", section 3 "Header format").  Basically - what is the payload?

If one asks me, I would dare to think that payload might be an ICMPv6
Router Advertisement.

> There is NO security for the messages below the message package.

Noted.

> Just not enough payload size for anything that would work in a 
> broadcast environment like a National Airspace.  All of the security 
> we are specifying is inside the messages where appropriate.
> 
> That security manifest is a payload of the ASTM F3411-19 
> Authentication Message.

It costs 85USD I wont pay to see it.  It is security.  There will always 
be someone smarter to break that security and ask for more money.

I would not oppose if that Authentication MEssage had a specification in
clear.

> These messages are broadcasted as Adam mentioned in his 'flying DRIP'
> comments at the beginning.

Thank you for the reminder.  I looked again at the 'flying DRIP' 
presentation during the WG meeting, and at the related draft.
https://datatracker.ietf.org/meeting/108/materials/slides-108-drip-authentication-formats
and
draft-wiethuechter-drip-auth-01

During the presentation, the slide clearly shows on slide 8 that a 
Bluetooth header immediately precedes an Open Drone ID message.  There 
is no IP header in that slide.

In the draft, there is similar discussion tightly related to Bluetooth 
and without IP.

But if we are to have an independence of Bluetooth, and use a networking 
layer such as IP, then the question of the use of an authentication 
header is made differently.

The authentication header would be an IP Authentication Header.  This AH 
would be somehow re-used and extended where necessary for DRIP purposes.

> Now later I expect us to move on to Network Remote ID and Command
> and Control (C2).
> 
> Most C2 (e.g. Mavlink) is directly over the MAC, but there is a 
> method to run it over UDP (I forget the UDP port commonly used...). 
> AX Enterprize has done this using HIP so the UA starts with WiFi
> over the launch point, transitions to LTE, and on return back to
> WiFi.
> 
> information to the GCS, from the GCS.  In either case, IP is
> assumed. This will probably be done via UDP.  From the UA, mobility
> will be important; from the GCS nice to have (most GCS will be stable
>  location).  As UDP to a fixed Net-SP, DTLS 1.3 is a viable 
> alternative to HIP.

I will have to look closer at HIP again :-) and see how it could be made 
to work with DRIP and IP.

Alex

> 
> 
> 
> 
>> 
>> Alex
>> 
>> as
>>> it is specified in ASTM F3411, which most of the regulators are 
>>> dubbing as an approved technical means of regulatory compliance.
>>> 
>>> AFAIK, no one runs IP over ADS-B, which was designed as a 
>>> narrowband application specific communications stovepipe, not a 
>>> data link supporting higher layer network protocols, so not
>>> great for IP.
>>> 
>>> More importantly, we have no "reluctance about the use of...
>>> IP", which is an entirely separate issue from ADS-B.
>>> 
>>>>> 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.
>>>> 
>>>> It might be that ADS-B might be forbidden in drones on Earth, 
>>>> but how about the drones on Mars? ('NASA Mars helicopters', or 
>>>> ESA too).  On Mars there would be much less such drones, so 
>>>> less risk of interference.
>>>> 
>>>> With such a system (ADS-B under IP) one could re-use DTN
>>>> (Delay Tolerant Networking) between planets, and so identify
>>>> drones even on Mars.
>>>> 
>>>> But if we have reluctance about the use of ADS-B, and thus of 
>>>> IP, and we recommend Bluetooth-without-IP to identify drones, 
>>>> then we might become too dependent on it?
>>>> 
>>>> (do not get me wrong, I do like Bluetooth, but I like many 
>>>> other things together with Bluetooth).
>>>> 
>>>> Alex
>>>> 
>>>>> 
>>>>> 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)
>>>>> 
>>>>> ADSB-In and ADSB-Out are mandated for airliners: -In gives 
>>>>> their pilots
>>>>> 
>>>>> "ADSB-Out" is mandated even for small general aviation 
>>>>> aircraft: it does
>>>>> 
>>>>> ADSB is _not_ going to be deployed on large numbers of small 
>>>>> UAS as it
>>>>> 
>>>>> 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
>>>>> 
>>>>> 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...
>>>>> 
>>>>> --
>>>>> 
> -- 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: Wed, 5 Aug 2020 07:41:54 -0400

> Maybe WiFi at 5.4GHz, which also used for remote control.

I recommend you look at IEEE 802.15.16t:

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

This is actually an addendum to 802.16.  A bit of 802 politics. 802.16 
is in hibernation.  802 EC did not want to go through the process and 
risks of reactivating it for this work.  So they turned over management 
of the work to the 802.15 leadership.

This is licensed spectrum.  The current use cases:

https://mentor.ieee.org/802.15/documents?is_dcn=DCN%2C%20Title%2C%20Author%20or%20Affiliation&is_group=016t

Does not include aviation, but so what?  Get one of the RF license 
holders in this business model and you are in business.

Some of these frequencies have the bandwidth and range for practical use 
here.

>>> ADS-B is gradually being mandated for essentially all manned aircraft.
>>>
>>> ADSB-In and ADSB-Out are mandated for airliners: -In gives their pilots
>>>
>>> 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...
>>>
>>> -- 
>>>

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 5 Aug 2020 07:53:02 -0400

On 8/5/20 6:11 AM, Alexandre Petrescu wrote:
> If it is a broadcast message and it is over Bluetooth or over WiFi 
> then it certainly is IP multicast, cant be anything else.

Wrong for BT4.  There are only 25 bytes available.  We can do most of 
the messaging in a single frame.  To do anything with IP will force this 
to a multiframe design.

Even BT5 it is wrong for the Authentication Message.  We need the full 
frame for our content.  We would have to go with multiframe design for 
BT5 as a result.

So this leaves WiFi NAN.  Sure you can do it, but why?  What does it 
add?  In My Not So Humble Opinion (IMNSOHO) nothing but cost and 
processing overhead.

> It costs 85USD I wont pay to see it.  It is security.  There will 
> always be someone smarter to break that security and ask for more money.

Look at:

https://github.com/opendroneid/specs/blob/master/OpenDroneID_Bluetooth_0.64.3.pdf

It is close enough.

> I would not oppose if that Authentication MEssage had a specification in

The above plus Adam's draft will get you there.

> is no IP header in that slide.

That is right.  No IP.  No room for it.  No justification for it. It is 
all RLOS only.

> But if we are to have an independence of Bluetooth, and use a 
> networking layer such as IP, then the question of the use of an 
> authentication header is made differently.

Again what is the justification for adding IP multicast?  Where do you 
see these messages going beyond the RF Line Of Sight?

>
> The authentication header would be an IP Authentication Header. This 
> AH would be somehow re-used and extended where necessary for DRIP 
> purposes.
>
> I will have to look closer at HIP again :-) and see how it could be 
> made to work with DRIP and IP.

Stu, Adam, Andrei, and I see HIP for where there is pairwise 
communication with potentially both ends mobile and using multiple 
interfaces.  Once you have that use case, be consistent and use it for 
simpler situations.

>>>>>> for most of the drones mostly due to SwaP, commercial drones 
>>>>>> might be exception.
>>>>>
>>>>> how about the drones on Mars? ('NASA Mars helicopters', or ESA 
>>>>> too).  On Mars there would be much less such drones, so less risk 
>>>>> of interference.
>>>>>
>>>>> and we recommend Bluetooth-without-IP to identify drones, then we 
>>>>> might become too dependent on it?
>>>>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 5 Aug 2020 14:13:13 +0200

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

I looked at some of the slides of 802.15.16th of presentations in July, 
2020.

The best I could understand is this:
   "The IEEE 802.15.16t Task Group is developing an amendment to
    802.16-2017. Project 802.16t “Amendment - Fixed and Mobile Wireless
    Access in Narrowband Channels” This project specifies operation in
    licensed spectrum with channel bandwidths greater than or equal to 5
    kHz and less than 100 kHz. A new PHY will be specified, with changes
    to the MAC as necessary. The amendment is frequency independent but
    focuses on spectrum less than 2 GHz. Aggregated operation in adjacent
    and non-adjacent channels will be supported."

> of the work to the 802.15 leadership.

I see, that's why.

So, the question that could be made to 802.15.16t is: would the new 
802.16 (the one including 802.15.16t) consider drones and their 
identification as a potential use-case?  If yes, would the new 802.16 
like to use IP to carry the drone identification?  Or would the new 
802.16 rather carry the drone identification in a new 802.16 header that 
sits below IP?

> Some of these frequencies have the bandwidth and range for practical use 

Fair enough.

There would be however some differences between carrying drone 
identification numbers by Bluetooth headers or by 802.16 headers.   IEEE 
and Bluetooth SIG made different formats.

If one wanted a unique format for drone identification to be transmitted 
on all these link layers similarly, one would need to use IP.  IP sits 
ok on both 802.16 and on Bluetooth.

Alex

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 5 Aug 2020 08:32:28 -0400

On 8/5/20 8:13 AM, Alexandre Petrescu wrote:
> I looked at some of the slides of 802.15.16th of presentations in 
> July, 2020.
>
>> This is actually an addendum to 802.16.  A bit of 802 politics. 
>> 802.16 is in hibernation.  802 EC did not want to go through the 
>> process and risks of reactivating it for this work.  So they turned 
>> over management of the work to the 802.15 leadership.
>
> I see, that's why.
>
> 802.16 rather carry the drone identification in a new 802.16 header 
> that sits below IP?
>
>> Some of these frequencies have the bandwidth and range for practical 
>> use here.
>
> Fair enough.
>
> identification numbers by Bluetooth headers or by 802.16 headers.   
> IEEE and Bluetooth SIG made different formats.

Where do you see in any of the DRIP documents that the proposed Remote 
ID numbers are carried in the Bluetooth headers?

In the Basic ID Message, the Remote ID IS the payload.  Look at Adam's 
slide 8 where he lays out the BT frame content for ASTM. There are 19 
bytes of BT header and 25 bytes for ASTM content.  In the Basic ID 
Message, 20 of those 25 bytes are the Remote ID.

Now where the BT header (4, 5, and even WiFi) comes in to play is that 
the RID is ONLY in the Basic ID message and some Authentication Message 
payloads.  So to determine which messages are from which UA, the MAC 
address is used as the value to link all messages from a UA to its RID.

This is spelled out in the ASTM standard, and perhaps it should be 
restated in the drip-arch and drip-uas-rid drafts (actually I do think 
it is in there somewhere).

> If one wanted a unique format for drone identification to be 
> transmitted on all these link layers similarly, one would need to use 
> IP.  IP sits ok on both 802.16 and on Bluetooth.

No, you don't need IP.  Or you have to pay the cost of IP on media where 
it is very expensive.

>>>> in most cases, physically capable to fly (a few thousand feet in 
>>>> the US except near major airports where you don't want drones, 
>>>> 30000 ft in Australia).  Aircraft send over the uplink information 
>>>> such as aircraft ICAO code, aircraft type, speed, direction of 
>>>> flight, altitude, etc.). Information is sent in the clear, by 
>>>> design.  You can buy a box receiving this info, hook it up to an 
>>>> Raspberry PI or something, and look at the traffic near your house 
>>>> and send it on to your friends--in fact, this type of crowdsourced 
>>>> ATC info is what makes flightradar24 and similar sites work.
>>>
>>>> somewhat over-simplified, as the uplink is intentionally sent in 
>>>> the clear, and many ADS-B receivers monitor the uplink of other 
>>>> aircraft for redundancy and more up-to-date information about 
>>>> traffic; see abive.) AFAIK, the whole continental US is covered by 
>>>> less than 20 transponders. N The downlink carries not only traffic 
>>>> information

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 5 Aug 2020 14:50:14 +0200

Le 05/08/2020 à 13:53, Robert Moskowitz a écrit :
>>>>>> But if we have reluctance about the use of ADS-B, and thus 
>>>>>> of IP, and we recommend Bluetooth-without-IP to identify 
>>>>>> drones
>>>>> 
>>>> But, the security manifest that I have seen on slides during 
>>>> the presentation of the DRIP WG meeting - is something below 
>>>> IP, right?
>>> 
> Wrong for BT4.  There are only 25 bytes available.  We can do most
> of the messaging in a single frame.  To do anything with IP will
> force this to a multiframe design.

I might say something stupid if I am allowed, maybe things that are
already known.  Sorry, I did not check the BoF archive discussion.  But
here goes anyways.  If one wants to do something with Bluetooth4 below
IP and finds it to be too small packets, then there could be several
possibilities:
- do it at Bluetooth SIG instead of IETF;
- do it in 6lo WG;
- use a header compression scheme at IETF (6lowpan HC at 6lo WG, SCHC at
   LP-WAN WG, ROHC and why not CBOR);
- implement packet fragmentation and reassembly and multiframe design
   below IP;
- use the already available data in the 25 bytes in order to realize
   that identification (there must be MAC addresses in there, and they're
   likely to be useful).

> Even BT5 it is wrong for the Authentication Message.  We need the 
> full frame for our content.  We would have to go with multiframe 
> design for BT5 as a result.

So, I do not understand: does DRIP want the entire packet to stay of
size 25bytes?  Or does DRIP want the packet to be more than 25bytes?

Would a multiframe design in which an IP packet of length 1280bytes is
chopped into 25bytes BT5 packets be advantageous for DRIP?

Do the BT5 packets have a notion of interlinking between sub-packets
that make a bigger packet?  (such a mechanism exists at the IP layer; it
uses Identification to identify a chain and an Offset to say where in
the chain is that sub-packet to be found).

> add?  In My Not So Humble Opinion (IMNSOHO) nothing but cost and 

I think WiFi 5.4 GHz is already used extensively to remotely control
drones.  These consoles with joysticks are WiFi 5.4GHz, if I am not
mistaken.

>> If it is IP multicast over Bluetooth or over WiFi then I wonder 
>> what is the value  in the Next Header field of the IP header
>> format (RFC8200 "IPv6", section 3 "Header format").  Basically -
>> what is the payload?
>> 
>> If one asks me, I would dare to think that payload might be an 
>> ICMPv6 Router Advertisement.
>> 
>>> broadcast environment like a National Airspace.  All of the 
>>> security we are specifying is inside the messages where 
>>> appropriate.
>>> 
It is close enough.

Thanks for the pointer.  Noted.

It is about Bluetooth.  Should be submitted to Bluetooth SIG.

I might stay something stupid here again... si I wont say it :-)

>> I would not oppose if that Authentication MEssage had a 
>> specification in clear.
> 
>>> These messages are broadcasted as Adam mentioned in his 'flying 
>>> DRIP' comments at the beginning.
>> 
>> and draft-wiethuechter-drip-auth-01
>> 
>> Bluetooth header immediately precedes an Open Drone ID message. 
>> There is no IP header in that slide.
> 
> That is right.  No IP.  No room for it.  No justification for it. It 
> is all RLOS only.

I might say something stupid here: no IP?  No IETF.

>> In the draft, there is similar discussion tightly related to 
>> Bluetooth and without IP.
>> 
> Again what is the justification for adding IP multicast?

I would not be afraid of IP multicast like the multicast we know for
video delivery.  It is IP multicast because IP is IPv6 and IPv6 has no
broadcast.

_If_ there is agreement that DRIP should be with IP (Internet Protocol).

We know that the drone identification should be broadcasted (like in TV
broadcast).  In IPv4 there is a mechanism to implement such TV-broadcast
concept.  It is called IPv4 broadcast.  That broadcast is sent to a
dedicated address (like 255.255.255.255 which is all Internet, or like
195.212.142.255 which is all computers in a particular subnet).  In IPv6
such broadcast concept does not exist.  Rather, it's called 'multicast'
and, as opposed to IPv4, it has a mandatory and voluntary join/leave
mechanism.

I name that IPv6 multicast simply IP multicast, because IPv4 should not
be used as basis for any new work at IETF.

On such an IP multicast perspective for DRIP, one would have to come up
with an architecture for joining and leaving that makes it easy to use
by authorities, mandatory to implement, is secure enough (security and
multicast is not that easy), etc.

> Where do you see these messages going beyond the RF Line Of Sight?

True.

But one would not want all BT5 devices (like my watch or earphones)
around a drone's sight to be awaken by its identification beacons,
right?  Only those devices who have voluntarily subscribed to that
multicast group would be awaken.

>> The authentication header would be an IP Authentication Header. 
>> This AH would be somehow re-used and extended where necessary for 
>> DRIP purposes.
>> 
>>> method to run it over UDP (I forget the UDP port commonly 
>>> used...). AX Enterprize has done this using HIP so the UA starts 
>>> with WiFi over the launch point, transitions to LTE, and on 
>>> return back to WiFi.
>>> 
>>> Network Remote ID can work either directly from the UA, or via
>>> C2 information to the GCS, from the GCS.  In either case, IP is 
>>> assumed. This will probably be done via UDP.  From the UA, 
>>> mobility will be important; from the GCS nice to have (most GCS 
>>> will be stable location).  As UDP to a fixed Net-SP, DTLS 1.3 is 
>>> a viable alternative to HIP.
>> 
>> I will have to look closer at HIP again :-) and see how it could
>> be made to work with DRIP and IP.
> 
> interfaces.  Once you have that use case, be consistent and use it 
> for simpler situations.

I wanted to ask whether using a Host Identity that is cryptographically
generated is sufficient for authorities to trust a drone upon reception
of one DRIP identification packet, or maybe am additional roundrip (a
ping, a request-response) would still be needed from ground officer to
drone to make sure it's the right drone who replies?  Or maybe a full
Diffie-Hellman exchange is needed?

Alex

> 
>> 
>> Alex
>> 
>>> 
>>> 
>>> 
>>> 
>>>> 
>>>> Alex
>>>> 
>>>> as
>>>>> it is specified in ASTM F3411, which most of the regulators 
>>>>> are dubbing as an approved technical means of regulatory 
>>>>> compliance.
>>>>> 
>>>>> narrowband application specific communications stovepipe,
>>>>> not a data link supporting higher layer network protocols,
>>>>> so not great for IP.
>>>>> 
>>>>>> It might be that ADS-B might be forbidden in drones on 
>>>>>> Earth, but how about the drones on Mars? ('NASA Mars 
>>>>>> helicopters', or ESA too).  On Mars there would be much 
>>>>>> less such drones, so less risk of interference.
>>>>>> 
>>>>>> (Delay Tolerant Networking) between planets, and so 
>>>>>> identify drones even on Mars.
>>>>>> 
>>>>>> But if we have reluctance about the use of ADS-B, and thus 
>>>>>> of IP, and we recommend Bluetooth-without-IP to identify 
>>>>>> drones, then we might become too dependent on it?
>>>>>> 
>>>>>>> *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, 
>>>>>>> not directly benefit the pilots of those aircraft; but
>>>>>>> by providing SA
>>>>>>> 
>>>>>>> ADSB is _not_ going to be deployed on large numbers of 
>>>>>>> small UAS as it
>>>>>>> 
>>>>>>> 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
>>>>>>>

---

From: "Card, Stu" <[email-masked]>
Date: Wed, 5 Aug 2020 09:20:26 -0400

Will do.

On Wed, Aug 5, 2020, 5:13 AM <[email-masked]> wrote:

> Hi Stu,
>
> I remember that Andrei raised in the past a question about the use of
> ADB-S. I suspect that others may make a similar comment in the future.
> Having some text in draft-ietf-drip-arch reflecting the main arguments
> shared in this thread (by Shuai, Bob, Stephan, you) will be useful.
>
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: "Card, Stu" <[email-masked]>
Date: Wed, 5 Aug 2020 09:38:13 -0400

Again, I wish to respond primarily to one line that again I believe
results from some confusion.

> then it certainly is IP multicast, cant be anything else.

There is nothing preventing application layer protocols from being layered
directly over link layer protocols. This is exactly what is typically done
with Bluetooth, not only for UAS RID, but other applications as well. It
can even be done with WiFi, Ethernet, etc., although this is less commonly
done. This certainly limits flexibility and internetworking. Again,
however, this is not up to us: the regulators are citing ASTM F3411 for UAS
RID; that standard defines how to put UAS RID application specific message
formats directly into Bluetooth link layer frames, without any intervening
headers (such as would be required for IP encapsulation of the app layer
messages). While I think their specifying Bluetooth generally was a bad
idea (for many reasons, including range as you mention, as has been
confirmed marginal in our testing), and supporting legacy Bluetooth 4
specifically was an even worse idea (for even lower range and its
incredibly short 25 byte payloads), this decision was not made by, and
cannot be reversed by, the DRIP WG. We can only hope to mitigate its
security deficiencies, address the issues it fails to address (such as how
registries work and how communications between an Observer and a Remote
Pilot can be initiated), and improve its interoperability with the Internet
once we get beyond the Broadcast RID data link.

---

From: "Card, Stu" <[email-masked]>
Date: Wed, 5 Aug 2020 09:50:49 -0400

Again, a single point response. The reason this work is appropriate for
IETF rather than the Bluetooth SIG is that ASTM F3411 specifies Bluetooth
_only_ as one transport for Broadcast RID (WiFi NaN is also specified and
other alternatives could be added later, as you, Bob and others are
discussing, also consider RTCA SC-228 DO-362 UAS C2 Data Link at ~1 and ~5
GHz), but there is also Network RID where ASTM F3411 specifies use of the
Internet, and a lot more to the overall UAS RID architecture/problem than
just the initial streaming of messages from the UAS.

Please look at the openly published early draft of ASTM F3411 to which Bob
pointed you, and perhaps some of the other external docs cited in the DRIP
requirements draft, for  essential context on the UAS RID problem and what
others have already done to address it, which we hope to complement (not
replace) with DRIP. Thanks!

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 5 Aug 2020 10:07:49 -0400

>   that identification (there must be MAC addresses in there, and they're

The reason for DRIP is to leverage IETF technologies to work with 
existing and planned UAS communications.  The definition of much of 
these communications are outside of IETF.  We MUST work with the ASTM 
messages that work within a single BT4 frame.  We CANNOT change this.

So what are we doing?

First define a stronger RemoteID than has been done and fit this within 
the defined messages.

We are proposing modifying HIP's HIT for this. (drip-uas-rid and 
drip-auth).  We can't add CBOR as much as I would like to do that...

Then once we have strong RemoteID that works on the most constrained 
communications (BT4) we add functionality.  Like using EPP for 
registering operators and pilots and UAS.  Using RDAP for Observer 
authenticated retrieval of said registered info and active operation 
data from USS/UTM.

Adding crowd-sourced collection of the Broadcast messages and using CBOR 
and CoAP is another area were IETF will add value.  Other organizations 
(like USAF) are realizing they need better affordable methods for 
discovering UA and they are talking about what we are defining in my 
crowd-source-rid draft!

But as Stu just said, we deal with the hand dealt.  We cannot change the 
ASTM messages from the outside, only work within them and then add other 
communications to the UAS ecosystem.

Also if we do this well, it will fit into ALL aviation.  In fact much of 
my time right now is doing items that will impact all aviation.  Why I 
really want things to move forward here, as we are getting attention 
focused on our work.

>>> If it is IP multicast over Bluetooth or over WiFi then I wonder what 
>>> is the value  in the Next Header field of the IP header
>>>> security we are specifying is inside the messages where appropriate.
>>>>
>>>> over the launch point, transitions to LTE, and on return back to WiFi.
>>>>
>>>> will be important; from the GCS nice to have (most GCS will be 
>>>> stable location).  As UDP to a fixed Net-SP, DTLS 1.3 is a viable 
>>>> alternative to HIP.
>>>
>>>>>>> ESA too).  On Mars there would be much less such drones, so less 
>>>>>>> risk of interference.
>>>>>>>
>>>>>>> Tolerant Networking) between planets, and so identify drones 
>>>>>>> even on Mars.
>>>>>>>
>>>>>>>> *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: Alexandre Petrescu <[email-masked]>
Date: Wed, 5 Aug 2020 16:22:09 +0200

Hi,

Thank you for the reply.

Le 05/08/2020 à 15:38, Card, Stu a écrit :
> There is nothing preventing application layer protocols from being 
> layered directly over link layer protocols. This is exactly what is 
> typically done with Bluetooth, not only for UAS RID, but other 
> applications as well. It can even be done with WiFi, Ethernet, etc.,
>  although this is less commonly done. This certainly limits
> flexibility and internetworking. Again, however, this is not up to
> us: the regulators are citing ASTM F3411 for UAS RID; that standard
> defines how to put UAS RID application specific message formats
> directly into Bluetooth link layer frames, without any intervening
> headers (such as would be required for IP encapsulation of the app
> layer messages). While I think their specifying Bluetooth generally
> was a bad idea (for many reasons, including range as you mention, as
> has been confirmed marginal in our testing), and supporting legacy
> Bluetooth 4 specifically was an even worse idea (for even lower range
> and its incredibly short 25 byte payloads), this decision was not
> made by, and cannot be reversed by, the DRIP WG. We can only hope to
> mitigate its security deficiencies, address the issues it fails to
> address (such as how registries work and how communications between
> an Observer and a Remote Pilot can be initiated), and improve its
> interoperability with the Internet once we get beyond the Broadcast
> RID data link.

It does clarify the point of view.

I will try to get along with the described view.  The best part that I
could follow is the part of DRIP developments that improve the
interoperability with the Internet.

In 6lo there was a perspective of a Gateway, or a 'backbone router',
that would link many small Bluetooth devices to the Internet.  But
unfortunately it is a smart network, instead of a 'smart end dumb network'.

lpwan directions too are distanced from the 'smart end dumb network',
because they dont use IP headers either: SCHC removes them.

I also struggle via IPWAVE WG for the use of IP networking layer for
automobiles, as opposed to IEEE P1609.3 Networking layer, and that too
is far from being a win.

Overall, there seems to be an agreement on tendency to act more and more
that way that you describe.  There is a draft that presents that in a
advantageous light; it's titled "Limited Domains", in which one could do
many things precisely as one wishes, and not as being Internet as IP is.

I will try to follow the developments along these lines.

Alex

> 
> On Wed, Aug 5, 2020 at 6:11 AM Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
> 
> 
> is the value  in the Next Header field of the IP header format
> (RFC8200 "IPv6", section 3 "Header format").  Basically - what is the
> payload?
> 
> I would not oppose if that Authentication MEssage had a specification
> in clear.
> 
and
>> with WiFi over the launch point, transitions to LTE, and on return
>> back to WiFi.
>> 
>> will be stable location).  As UDP to a fixed Net-SP, DTLS 1.3 is a
>> viable alternative to HIP.
> 
>>>> narrowband application specific communications stovepipe, not
>>>> a data link supporting higher layer network protocols, so not 
>>>> great for IP.
>>>> 
>>>>> helicopters', or ESA too).  On Mars there would be much less
>>>>> such drones, so less risk of interference.
>>>>> 
>>>>>> *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
> <http://www.axenterprize.com>
>>>>>> 
> <mailto:[email-masked]>
>> 
> -- Tm-rid mailing list [email-masked] <mailto:[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 5 Aug 2020 16:23:26 +0200

Le 05/08/2020 à 15:50, Card, Stu a écrit :
> IETF rather than the Bluetooth SIG is that ASTM F3411 specifies 
> Bluetooth _only_ as one transport for Broadcast RID (WiFi NaN is also 
> specified and other alternatives could be added later, as you, Bob and 
> others are discussing, also consider RTCA SC-228 DO-362 UAS C2 Data Link 
> at ~1 and ~5 GHz), but there is also Network RID where ASTM F3411 
> specifies use of the Internet, and a lot more to the overall UAS RID 
> architecture/problem than just the initial streaming of messages from 
> the UAS.
> 
> Please look at the openly published early draft of ASTM F3411 to which 
> Bob pointed you,

I looked and I will keep it aside for reference when needed.

It's an Intel document.

Alex

  and perhaps some of the other external docs cited in
> the DRIP requirements draft, for  essential context on the UAS RID 
> problem and what others have already done to address it, which we hope 
> to complement (not replace) with DRIP. Thanks!
> 
> 
> On Wed, Aug 5, 2020 at 8:50 AM Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
>      >>>>>>> *"[email-masked] <mailto:[email-masked]>"
>     <[email-masked] <mailto:[email-masked]>> *Subject: *[Drip]
>     [email-masked] <mailto:[email-masked]>

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 5 Aug 2020 10:26:04 -0400

On 8/5/20 10:23 AM, Alexandre Petrescu wrote:
>> Again, a single point response. The reason this work is appropriate 
>> for IETF rather than the Bluetooth SIG is that ASTM F3411 specifies 
>> specified and other alternatives could be added later, as you, Bob 
>> and others are discussing, also consider RTCA SC-228 DO-362 UAS C2 
>> Data Link at ~1 and ~5 GHz), but there is also Network RID where ASTM 
>> F3411 specifies use of the Internet, and a lot more to the overall 
>> UAS RID architecture/problem than just the initial streaming of 
>> messages from the UAS.
>>
>> Please look at the openly published early draft of ASTM F3411 to 
>> which Bob pointed you,
>

yes, Intel got ASTM's approval to do the OpenDrone ID work for PoC. So 
there is code there for implementing this on github.  Adam used that as 
his starting point.

>> problem and what others have already done to address it, which we 
>> hope to complement (not replace) with DRIP. Thanks!
>>
>>
>>      >
>>      >
>>      > On 8/5/20 6:11 AM, Alexandre Petrescu wrote:
>>      >>
>>      >>
>>      >> Le 04/08/2020 à 17:51, Robert Moskowitz a écrit :
>>      >>>
>>      >>>
>>      >>> On 8/4/20 11:27 AM, Alexandre Petrescu wrote:
>>      >>>> Thanks for the clarification.
>>      >>>>
>>      >>>> Le 04/08/2020 à 17:17, Stuart W. Card a écrit :
>>      >>>>> I just want to respond to one line that I think comes from
>>      >>>>> confusion:
>>      >>>>>
>>      >>>>>> But if we have reluctance about the use of ADS-B, and thus
>>      >>>>>> of IP, and we recommend Bluetooth-without-IP to identify
>>      >>>>>> drones
>>      >>>>>
>>      >>>>> We aren't recommending Bluetooth-without-IP, we are
>>      >>>>> _supporting_ it,
>>      >>>>
>>      >>>> But, the security manifest that I have seen on slides during
>>      >>>> the presentation of the DRIP WG meeting - is something below
>>      >>>> IP, right?
>>      >>>
>>      >>> For now, we are dealing with broadcast messages.  Either over
>>      >>> Bluetooth or WiFI (NAN).
>>      >>
>>      >> If it is a broadcast message and it is over Bluetooth or over 
>> WiFi
>>      >> then it certainly is IP multicast, cant be anything else.
>>      >
>>      > Wrong for BT4.  There are only 25 bytes available.  We can do 
>> most
>>      > of the messaging in a single frame.  To do anything with IP will
>>      > force this to a multiframe design.
>>
>>      > Even BT5 it is wrong for the Authentication Message. We need the
>>      > full frame for our content.  We would have to go with multiframe
>>      > design for BT5 as a result.
>>
>>      > So this leaves WiFi NAN.  Sure you can do it, but why?  What 
>> does it
>>      > add?  In My Not So Humble Opinion (IMNSOHO) nothing but cost and
>>      > processing overhead.
>>
>>      >> If it is IP multicast over Bluetooth or over WiFi then I wonder
>>      >> what is the value  in the Next Header field of the IP header
>>      >> format (RFC8200 "IPv6", section 3 "Header format").  Basically -
>>      >> what is the payload?
>>      >>
>>      >> If one asks me, I would dare to think that payload might be an
>>      >> ICMPv6 Router Advertisement.
>>      >>
>>      >>> There is NO security for the messages below the message 
>> package.
>>      >>
>>      >> Noted.
>>      >>
>>      >>> Just not enough payload size for anything that would work in a
>>      >>> broadcast environment like a National Airspace.  All of the
>>      >>> security we are specifying is inside the messages where
>>      >>> appropriate.
>>      >>>
>>      >>> That security manifest is a payload of the ASTM F3411-19
>>      >>> Authentication Message.
>>      >>
>>      >> It costs 85USD I wont pay to see it.  It is security.  There 
>> will
>>      >> always be someone smarter to break that security and ask for 
>> more
>>      >> money.
>>      >
>>      > Look at:
>>      >
>>      >
>>      >
>>      >
>>      >
>>      >> I would not oppose if that Authentication MEssage had a
>>      >> specification in clear.
>>      >
>>      > The above plus Adam's draft will get you there.
>>      >
>>      >>
>>      >>> These messages are broadcasted as Adam mentioned in his 'flying
>>      >>> DRIP' comments at the beginning.
>>      >>
>>      >> Thank you for the reminder.  I looked again at the 'flying DRIP'
>>      >> presentation during the WG meeting, and at the related draft.
>>      >>
>>      >>
>>      >>
>>      >>
>>      >> and draft-wiethuechter-drip-auth-01
>>      >>
>>      >> During the presentation, the slide clearly shows on slide 8 
>> that a
>>      >> Bluetooth header immediately precedes an Open Drone ID message.
>>      >> There is no IP header in that slide.
>>      >
>>      > That is right.  No IP.  No room for it.  No justification for 
>> it. It
>>      > is all RLOS only.
>>
>>      >> In the draft, there is similar discussion tightly related to
>>      >> Bluetooth and without IP.
>>      >>
>>      >> But if we are to have an independence of Bluetooth, and use a
>>      >> networking layer such as IP, then the question of the use of an
>>      >> authentication header is made differently.
>>      >
>>      > Again what is the justification for adding IP multicast?
>>
>>      > Where do you see these messages going beyond the RF Line Of 
>> Sight?
>>
>>     True.
>>
>>      >> The authentication header would be an IP Authentication Header.
>>      >> This AH would be somehow re-used and extended where necessary 
>> for
>>      >> DRIP purposes.
>>      >>
>>      >>> Now later I expect us to move on to Network Remote ID and 
>> Command
>>      >>> and Control (C2).
>>      >>>
>>      >>> Most C2 (e.g. Mavlink) is directly over the MAC, but there is a
>>      >>> method to run it over UDP (I forget the UDP port commonly
>>      >>> used...). AX Enterprize has done this using HIP so the UA 
>> starts
>>      >>> with WiFi over the launch point, transitions to LTE, and on
>>      >>> return back to WiFi.
>>      >>>
>>      >>> Network Remote ID can work either directly from the UA, or via
>>      >>> C2 information to the GCS, from the GCS.  In either case, IP is
>>      >>> assumed. This will probably be done via UDP. From the UA,
>>      >>> mobility will be important; from the GCS nice to have (most GCS
>>      >>> will be stable location).  As UDP to a fixed Net-SP, DTLS 
>> 1.3 is
>>      >>> a viable alternative to HIP.
>>      >>
>>      >> I will have to look closer at HIP again :-) and see how it could
>>      >> be made to work with DRIP and IP.
>>      >
>>      > Stu, Adam, Andrei, and I see HIP for where there is pairwise
>>      > communication with potentially both ends mobile and using 
>> multiple
>>      > interfaces.  Once you have that use case, be consistent and 
>> use it
>>      > for simpler situations.
>>
>>      >
>>      >>
>>      >> Alex
>>      >>
>>      >>>
>>      >>>
>>      >>>
>>      >>>
>>      >>>>
>>      >>>> Alex
>>      >>>>
>>      >>>> as
>>      >>>>> it is specified in ASTM F3411, which most of the regulators
>>      >>>>> are dubbing as an approved technical means of regulatory
>>      >>>>> compliance.
>>      >>>>>
>>      >>>>> AFAIK, no one runs IP over ADS-B, which was designed as a
>>      >>>>> narrowband application specific communications stovepipe,
>>      >>>>> not a data link supporting higher layer network protocols,
>>      >>>>> so not great for IP.
>>      >>>>>
>>      >>>>> More importantly, we have no "reluctance about the use of...
>>      >>>>>  IP", which is an entirely separate issue from ADS-B.
>>      >>>>>
>>      >>>>> On 8/4/2020 9:52 AM, Alexandre Petrescu wrote:
>>      >>>>>> architectural layers discussion...
>>      >>>>>>
>>      >>>>>> Le 30/07/2020 à 11:49, shuaiizhao(Shuai Zhao) a écrit :
>>      >>>>>>> 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.
>>      >>>>>>
>>      >>>>>> It might be that ADS-B might be forbidden in drones on
>>      >>>>>> Earth, but how about the drones on Mars? ('NASA Mars
>>      >>>>>> helicopters', or ESA too).  On Mars there would be much
>>      >>>>>> less such drones, so less risk of interference.
>>      >>>>>>
>>      >>>>>> With such a system (ADS-B under IP) one could re-use DTN
>>      >>>>>> (Delay Tolerant Networking) between planets, and so
>>      >>>>>> identify drones even on Mars.
>>      >>>>>>
>>      >>>>>> But if we have reluctance about the use of ADS-B, and thus
>>      >>>>>> of IP, and we recommend Bluetooth-without-IP to identify
>>      >>>>>> drones, then we might become too dependent on it?
>>      >>>>>>
>>      >>>>>> (do not get me wrong, I do like Bluetooth, but I like many
>>      >>>>>> other things together with Bluetooth).
>>      >>>>>>
>>      >>>>>> Alex
>>      >>>>>>
>>      >>>>>>>
>>      >>>>>>> Best,
>>      >>>>>>>
>>      >>>>>>> Shuai Zhao
>>      >>>>>>>
>>      >>>>>>> *From: *Tm-rid <[email-masked]
>>      >>>>>>> "Stuart W. Card" <[email-masked]
>>      >>>>>>> *Wednesday, July 29, 2020 at 19:46 *To:
>>      >>>>>>> *"[email-masked] <mailto:[email-masked]>"
>>      >>>>>>> ADSB (was: Review of draft-drip-arch-02 w.r.t. RFC6973,
>>      >>>>>>> RFC8280 and other)(Internet mail)
>>      >>>>>>>
>>      >>>>>>> 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:
>>      >>>>>>>
>>      >>>>>>> ...
>>      >>>>>>>
>>      >>>>>>> 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...
>>      >>>>>>>
>>      >>>>>>> --
>>      >>>>>>>
>>      >>>>>>> -----------------------------------------
>>      >>>>>>>
>>      >>>>>>> Stuart W. Card, PhD, Principal Engineer
>>      >>>>>>>
>>      >>>>>>> AX Enterprize, LLC www.axenterprize.com
>>      >>>>>>>
>>      >>>>>>> 4947 Commercial Drive, Yorkville NY 13495
>>      >>>>>>>
>>      >>>>>>>
>>      >>>>>>
>>      >>>>>
>>      >>>>>
>>      >>>>>
>>      >>>>
>>      >>>
>>      >>> -- 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
>>      >
>>      > -- 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
>>
>>     --     Tm-rid mailing list

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 5 Aug 2020 10:30:36 -0400

> unfortunately it is a smart network, instead of a 'smart end dumb 

See:

draft-moskowitz-drip-crowd-sourced-rid

> automobiles, as opposed to IEEE P1609.3 Networking layer, and that too

Part of the reason I stepped away from IPWAVE work.  I have 19 years 
automotive, so I 'know' the players at Ford and other OEMs, and while at 
Verizon we replied to the PKI RFI with an approach that would allow for 
good support of cellphone participation and were basically told to go 
away...

>>>>> More importantly, we have no "reluctance about the use of... IP", 
>>>>> which is an entirely separate issue from ADS-B.
>>>>>
>>>>>> Tolerant Networking) between planets, and so identify drones even 
>>>>>> on Mars.
>>>>>>
>>>>>>> draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and other)(Internet 
>>>>>>> mail)
>>>>>>>

---

From: "Card, Stu" <[email-masked]>
Date: Wed, 5 Aug 2020 10:34:14 -0400

Yes, the openly published early draft of ASTM F3411 was developed largely
by Gabriel Cox of Intel and his group there. While we all are generally
suspicious of the motivations of large companies, I have spoken often with
Gabriel: his heart is pure; he says Intel hopes to increase sales by simply
helping mature a standard that enables a market to grow. Development and
publication of the standard within ASTM then attracted many other large and
small players, so Intel could not force anything upon the world that
benefited primarily Intel. While I do not agree with all the decisions made
(and neither does Gabriel), they are the decisions that SDO working group
made, in response to the concerns of many different stakeholders
(especially regulators, manufacturers and would-be UTM network service
providers). Alas, ASTM supports themselves by sales of standards documents,
so F3411-19 is not openly published. OTOH $85 is small compared to the
value of most contributor's time working on the problem, and better still
one can join ASTM as an individual for only $75 and get this standard as
part of the one free "volume" of standards that a member may select (from a
large library) upon joining. As a fallback, we point people to the openly
published early draft, which provides pretty good context; perhaps I should
add it to the reference list in the requirements draft? Thanks again for
your interest and help with this!

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 5 Aug 2020 16:36:28 +0200

Le 05/08/2020 à 16:07, Robert Moskowitz a écrit :
[...]
> communications to the UAS ecosystem.

Maybe the UAS ecosystem also looks at the use of IP in the future.  Or
maybe not.

Maybe UAS ecosystem would consider to carry ASTM messages as UDP payload
on IP?  Maybe request new port number from IANA for DRIP, let's say next
in sequence from
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

An ASTM message on UDP/IP could look like below.
If carried over Bluetooth it would add a preceding header different than 
when carried over 802.15.16t (the 802.16 for NB-IoT).

    IPv6 Header
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Version| Traffic Class |           Flow Label                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Payload Length        |  Next Header  |   Hop Limit   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                         Source Address                        +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                      Destination Address                      +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    UDP Header
                 0      7 8     15 16    23 24    31
                  +--------+--------+--------+--------+
                  |     Source      |   Destination   |
                  |      Port       |      Port       |
                  +--------+--------+--------+--------+
                  |                 |                 |
                  |     Length      |    Checksum     |
                  +--------+--------+--------+--------+

    ASTM message
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +---------------+-----------------------------------------------+
    |  Auth Header  |                                               |
    +---------------+  ASTM Authentication Headers  +---------------+
    |                                               |               |
    +-----------------------------------------------+               |
    |                                                               |
    |                                                               |
    |                                                               |
    |                Authentication Data / Signature                |
    |                                                               |
    |                                                               |
    |                                                               |
    +---------------------------------------------------------------+

Alex

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 5 Aug 2020 10:41:42 -0400

On 8/5/20 10:36 AM, Alexandre Petrescu wrote:
>> But as Stu just said, we deal with the hand dealt.  We cannot change 
>> the ASTM messages from the outside, only work within them and then 
>> add other communications to the UAS ecosystem.
>

Please see:

this is Network Remote ID.  ASTM F3411 assumes that only the data model 
of the messages will be used for Network Remote ID, but there is madness 
and proprietary products.  I leverage the Broadcast message formats for 
the nrid portion of this draft.

I would be interested in working with others on expanding the draft and 
getting testing going...

> If carried over Bluetooth it would add a preceding header different 
> than when carried over 802.15.16t (the 802.16 for NB-IoT).
>
>
>    IPv6 Header

---

From: "Card, Stu" <[email-masked]>
Date: Wed, 5 Aug 2020 10:48:46 -0400

Now you're talking! :-)

Yes, UDP/IP encapsulation of Broadcast RID messages, over media other than
Bluetooth, is an attractive possibility, which goes beyond but does not
conflict with ASTM F3411.

Also, UDP/IP, TCP/IP, HTTPS/TCP/IP, etc. encapsulations of Broadcast RID
message structures (not merely data dictionary elements) as a means of
transporting Network RID, comprise another attractive possibility, which
probably conflicts with the initial ASTM F3411-19 version but there will be
future revisions that we may be able to influence.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 7 Aug 2020 14:51:49 +0200

Le 05/08/2020 à 16:34, Card, Stu a écrit :
> Yes, the openly published early draft of ASTM F3411 was developed 
> largely by Gabriel Cox of Intel and his group there. While we all are 
> generally suspicious of the motivations of large companies, I have 
> spoken often with Gabriel: his heart is pure; he says Intel hopes to 
> increase sales by simply helping mature a standard that enables a market 
> to grow. Development and publication of the standard within ASTM then 
> attracted many other large and small players, so Intel could not force 
> anything upon the world that benefited primarily Intel. While I do not 
> agree with all the decisions made (and neither does Gabriel), they are 
> the decisions that SDO working group made, in response to the concerns 
> of many different stakeholders (especially regulators, manufacturers and 
> would-be UTM network service providers). Alas, ASTM supports themselves 
> by sales of standards documents, so F3411-19 is not openly published. 
> OTOH $85 is small compared to the value of most contributor's time 

Yes 85USD is small compared to other things.

At IETF there was an innovation last meeting, in that non-paying the 
attending money was somehow an option.  Its results are still to be 
understood but the option was there.  I hope others could replicate.

There are many things.

> working on the problem,
  and better still one can join ASTM as an
> individual for only $75 and get this standard as part of the one free 
> "volume" of standards that a member may select (from a large library) 
> upon joining. As a fallback, we point people to the openly published 
> early draft, which provides pretty good context; perhaps I should add it 
> to the reference list in the requirements draft?

Yes yes, please add the openly available document to the reference list 
in the appropriate draft.

Alex

  Thanks again for your
> interest and help with this!
> 
> 
> On Wed, Aug 5, 2020 at 10:23 AM Alexandre Petrescu 
>     which
>     hope
>      > <[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
>      >
>      >
>      >      >> If it is a broadcast message and it is over Bluetooth or
>     over WiFi
>      >      > Wrong for BT4.  There are only 25 bytes available.  We can
>     do most
>      >         that identification (there must be MAC addresses in
>     there, and
>      >     they're
>      >         likely to be useful).
>      >
>      >      > So this leaves WiFi NAN.  Sure you can do it, but why? 
>     What does it
>      >      >> It costs 85USD I wont pay to see it.  It is security. 
>     There will
>      >      >> always be someone smarter to break that security and ask
>     for more
>      >      >> money.
>      >      >
>      >      > Look at:
>      >      >
>      >      >
>      >
>      >      >> During the presentation, the slide clearly shows on slide
>     8 that a
>      >      > That is right.  No IP.  No room for it.  No justification
>     for it. It
>      >      > is all RLOS only.
>      >
>      >      > Where do you see these messages going beyond the RF Line
>     Of Sight?
>      >
>      >     True.
>      >
>      >      >> This AH would be somehow re-used and extended where
>     necessary for
>      >      >> DRIP purposes.
>      >      >>
>      >      >>> Now later I expect us to move on to Network Remote ID
>     and Command
>      >      >>> and Control (C2).
>      >      >>>
>      >      >>> used...). AX Enterprize has done this using HIP so the
>     UA starts
>      >      >>> will be stable location).  As UDP to a fixed Net-SP,
>     DTLS 1.3 is
>      >      > interfaces.  Once you have that use case, be consistent
>     and use it
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>> on behalf of
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>> *Date:
>      >      >>>>>>> *"[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>"
>      >     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> *Subject: *[Drip]
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >      >>>
>      >      >>> There's no limit to what can be accomplished if it
>     doesn't matter
>      >      >>> who gets the credit
>      >      >
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >      >
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>