Re: [Drip] ADSB - draft-moskowitz-drip-crowd-sourced-rid/

Alexandre Petrescu <alexandre.petrescu@gmail.com> Tue, 18 July 2023 08:57 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: tm-rid@ietfa.amsl.com
Delivered-To: tm-rid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22A2C14CE30 for <tm-rid@ietfa.amsl.com>; Tue, 18 Jul 2023 01:57:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.672
X-Spam-Level:
X-Spam-Status: No, score=0.672 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zn1MuG_IgekZ for <tm-rid@ietfa.amsl.com>; Tue, 18 Jul 2023 01:57:51 -0700 (PDT)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B76F9C14F749 for <tm-rid@ietf.org>; Tue, 18 Jul 2023 01:57:50 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 36I8vlJ4034605; Tue, 18 Jul 2023 10:57:47 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 65B53205DBB; Tue, 18 Jul 2023 10:57:47 +0200 (CEST)
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 53392200CDB; Tue, 18 Jul 2023 10:57:47 +0200 (CEST)
Received: from [10.14.0.97] ([10.14.0.97]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 36I8vlSq062844; Tue, 18 Jul 2023 10:57:47 +0200
Content-Type: multipart/alternative; boundary="------------i00JOkgplnJsB1D7tDsB44Sp"
Message-ID: <459b1c92-8f02-3359-1f78-8f610ea7cadc@gmail.com>
Date: Tue, 18 Jul 2023 10:57:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0
Content-Language: fr
To: Robert Moskowitz <rgm@labs.htt-consult.com>, Stu Card <stu.card@axenterprize.com>
Cc: "tm-rid@ietf.org" <tm-rid@ietf.org>
References: <6dfe8ea4-e803-5a70-c8eb-08eb3c1d4c4c@gmail.com> <2dd5fa11-d586-43e4-bd09-828c6aa77a0f@cea.fr> <MN2PR13MB4207C77AF8314327F9757A8FF831A@MN2PR13MB4207.namprd13.prod.outlook.com> <3decc87c-5b25-6349-b98f-618775dc5a57@gmail.com> <C5708075-DE36-4803-BA30-E4219E0BF1CA@tzi.org> <bc739d4f-4a03-4379-0fcb-6336f7b86ae6@labs.htt-consult.com> <33c4528e-1fb1-e329-7308-b782698208be@gmail.com> <MN2PR13MB42073DC46CDB9EFB2CF5A055F836A@MN2PR13MB4207.namprd13.prod.outlook.com> <445a964b-75b5-cf36-633e-90ce70c0814b@gmail.com> <MN2PR13MB420708D526162E9E96418914F836A@MN2PR13MB4207.namprd13.prod.outlook.com> <ee960fb3-e97d-85bd-8910-8b930bb9d760@gmail.com> <c7620042-f844-d9a4-c0fd-8dbaba1ec732@labs.htt-consult.com> <5cffd08e-9b79-31ca-16a7-49d3983aa487@gmail.com> <5cce0647-5db4-5061-bb00-e22cb9f6cf96@labs.htt-consult.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
In-Reply-To: <5cce0647-5db4-5061-bb00-e22cb9f6cf96@labs.htt-consult.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tm-rid/41szkyX0gIclLONuuLbys2WQRmA>
Subject: Re: [Drip] ADSB - draft-moskowitz-drip-crowd-sourced-rid/
X-BeenThere: tm-rid@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Drone Remote Identification Protocol <tm-rid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tm-rid>, <mailto:tm-rid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tm-rid/>
List-Post: <mailto:tm-rid@ietf.org>
List-Help: <mailto:tm-rid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tm-rid>, <mailto:tm-rid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jul 2023 08:57:53 -0000

I read the abstract of draft-moskowitz-drip-crowd-sourced-rid.

Disclaimer: I will not personally going to work on this, for other reasons.

But I wanted to ask: we discussed about people converting between other 
formats, presumably bluetooth formats, into ADS-B to display in 
flightradar.  That discussion assumed a simple 1-1 conversion.  Is there 
a draft about that? (I am asking, but I am not going to work on it 
either for various reasons, but the question is inevitable).

Alex

Le 12/07/2023 à 18:04, Robert Moskowitz a écrit :
>
>
> On 7/12/23 11:52, Alexandre Petrescu wrote:
>>
>>
>> Le 12/07/2023 à 17:31, Robert Moskowitz a écrit :
>>>
>>>
>>> On 7/12/23 11:13, Alexandre Petrescu wrote:
>>>> thanks for the clarification I must have endeavoured in
>>>> unchartered lands...
>>>>
>>>> Just to clarify: I am not disputing.
>>>>
>>>> I came with this thread to say that I saw ADS-B drones on flightradar.
>>>
>>> I am sure people do it.  How they get an aircraft number might be 
>>> interesting.  Of course some transponders are preset for this from 
>>> what I have heard.
>>>
>>> Also I am away of code that takes "standard" Remote ID messages and 
>>> feeds that into ADS-B systems.  So you see them in things like 
>>> FlightAware, but they are NOT sending ADS-B.
>>
>> Interesting.  If so then flightradar might say so somewhere on the
>> Internet.
>
> See my draft:
>
> https://datatracker.ietf.org/doc/draft-moskowitz-drip-crowd-sourced-rid/
>
> For harvesting RemoteID messages to feed into UTM.  Feeding into ATC 
> is probably not a good thing, IMHO.
>
>>
>>> of course you have to lie about the aircraft number,
>>
>> For the aircraft type, registration and country of reg.: it says 'N/A'.
>> (for 'Not Available' I suppose - never knew what a dash had to do there,
>> as if it were 'Not/Available').
>>
>> There is no 'aircraft number' in the page, but maybe you meant something
>> like that.
>>
>> Also, even the legally carrying ADS-B aircraft sometimes dont provide
>> some of these ADS-B fields, or are some times badly read, or badly
>> interpreted.
>>
>> But I am happy to see what is there to be seen.
>>
>>> going from the 20 character UA ID to the 24-bit aircraft number...
>>
>> The 'ADS-B' drone I saw on flightradar said the 'ICAO 24-bit address'
>> was '511161' decimal I suppose.  Is there a means to check the validity
>> of this number?  Or to tilt to thinking it is a fake?
>
> I do not know if there is a way for the general public to link the 
> 24-bit address back to anything remotely interesting.   Just have not 
> spent time in that direction.
>
>>
>>> The one effort I reviewed on this I asked this question, and they 
>>> said the hashed the UA ID down to 24 bits...
>>
>> Sure, we can do anything, put random or other crazy things in there -
>> but maybe it is not very good to play like that with these numbers.  But
>> I will not dispute that either.  I am just happy I could see it there.
>>
>> If they hashed the UA ID to 24 bit for a 'standard' Remote ID of a drone
>> into ADS-B - would they do the same for a ground vehicle at the airport?
>>  Do ground vehicles at airport also likely carry 'standard' Remote IDs?
>> (obviously ignoring vehicles have other IDs like VINs...)
>
> WE would like to see Trustworthy Remote ID (DRIP work) used beyond 
> UAS!  I am working along these paths in ICAO.  Civil Aviation is 
> pushing a PKI; FAA and EUROCONTROL are doing initial testing. Aircraft 
> and other moving things that participate could easily have DETs to 
> use.  WIP.
>
>>
>> Alex
>>
>>>
>>>>
>>>> That's about it.
>>>>
>>>> Alex
>>>>
>>>> Le 12/07/2023 à 16:56, Stu Card a écrit :
>>>>> The UAS RID rules are _not_ defined in this WG!
>>>>>
>>>>> They are defined by Civil Aviation Authorities (CAAs) in each 
>>>>> jurisdiction, with coordination via the International Civil 
>>>>> Aviation Organization (ICAO).
>>>>>
>>>>> Disputing the rules should be taken up with them, not with the 
>>>>> DRIP WG or any part of IETF.
>>>>>
>>>>> Such rules are mentioned in DRIP docs only as background: 
>>>>> motivation, context & constraints.
>>>>>
>>>>> Standard Means of Compliance with UAS RID rules, in turn, is 
>>>>> mostly the province of SDOs other than IETF, primarily ASTM 
>>>>> International. Again, disputing those standards should be taken up 
>>>>> with those SDOs, not us.
>>>>>
>>>>> Only if some reference, in DRIP docs, to the rules or external 
>>>>> standards, is factually incorrect or unclear in expression for 
>>>>> understanding by DRIP protocol implementors, is it something we 
>>>>> should be debating here.
>>>>>
>>>>>
>>>>> Get Outlook for Android <https://aka.ms/AAb9ysg>
>>>>>
>>>>> ------------------------------------------------------------------------ 
>>>>>
>>>>>
>>>>>
>>>>>
>> *From:* Alexandre Petrescu <alexandre.petrescu@gmail.com>
>>>>> *Sent:* Wednesday, July 12, 2023, 10:43 *To:* Stu Card 
>>>>> <stu.card@axenterprize.com>; Robert Moskowitz 
>>>>> <rgm@labs.htt-consult.com>; Carsten Bormann <cabo@tzi.org> *Cc:* 
>>>>> tm-rid@ietf.org <tm-rid@ietf.org> *Subject:* Re: [Drip] ADSB
>>>>>
>>>>>
>>>>>
>>>>> Le 12/07/2023 à 16:00, Stu Card a écrit :
>>>>>> Very short answers (all for which I have time):
>>>>>>
>>>>>> The rules for RID are based not primarily on RF
>>>>>> considerations, but on aviation considerations.
>>>>>
>>>>> hmmm... it's a principle that is reasonable and that could be 
>>>>> debated.
>>>>>
>>>>> One will excuse me for not knowing precisely what are the RID 
>>>>> rules. The RID rules are defined in this WG and I will need to 
>>>>> look at them.
>>>>>
>>>>> If I look at them, one day, I will look at them from this 
>>>>> perspective:
>>>>>
>>>>> For example, when RID rules say 'altitude' they should say 
>>>>> 'altitude expressed in meters and not in feet as is currently
>>>>> the inherited case from WWII development of aviation'.
>>>>>
>>>>> This kind of text could be of enormous help to implementers:
>>>>> they simply would need to call less functions(), because less
>>>>> need of conversions.
>>>>>
>>>>> It is the same when RID rules say 'heading' or 'speed', or when we 
>>>>> talk about airport track orientation.  It should be made easy to 
>>>>> implementer to compare a heading value in a 'heading' of a
>>>>> UAS to that of a track. One should come up with a single common
>>>>> way of expressing track orientation, compatible to that of RID
>>>>> rules, instead of several and incompatible, as is the case in
>>>>> current air flight industry.  It is because if one does that 
>>>>> (interoperable defs of headings) then the programmer has an easier 
>>>>> task.
>>>>>
>>>>> Also, about RID rules: they should say that when ASTM wants to 
>>>>> send position and heading they should send the NMEA statements, 
>>>>> without conversion.
>>>>>
>>>>> Until then, if we can not do that, we can also have a human 
>>>>> listening to the radio airport and maneouvering locally or from
>>>>> a distance, using an innombrable number of calculators and 
>>>>> conversions, after having learned tomes of manuals about how to 
>>>>> fly things.  It is basically easier.
>>>>>
>>>>>>
>>>>>> Crewed aircraft _mostly_ fly above 500 feet, except during 
>>>>>> takeoff and landing.
>>>>>
>>>>> I always had problems with this term 'crewed' aircraft.  I noticed 
>>>>> it also in the TVR WG, in its reverse form 'uncrewed' aircraft.
>>>>>
>>>>> But in reality there can be uncrewed crewed aircrafts too 
>>>>> (Unmanned Air Mobility device, a flying taxi, does carry a
>>>>> couple of persons on board - 'crew?', yet none of them actually
>>>>> drives the UAM - they just signed the insurance agreement).  An
>>>>> uncrewed aircraft is still crewed by the fact that a (group of)
>>>>> persons on the ground is its crew (drone Reaper is such). There
>>>>> can also be these devices that are not crewed, are not
>>>>> continuously driven from a ground by a crew, yet there are very
>>>>> many eyes of people loooking at where it is going to - they're
>>>>> pre-programmed.  These would be the true 'uncrew' aircraft even
>>>>> though there are many crews simply looking at them.  They fly at
>>>>> more altitudes than 500 feet.
>>>>>
>>>>> This is why I am not sure how to use this term 'crewed aircraft'.
>>>>>
>>>>> But I think you meant a 200 passenger aircraft like a regular 
>>>>> airline flight from a city to another.  Even that can be automated 
>>>>> (crewless?) soon.
>>>>>
>>>>>> Small uncrewed aircraft _mostly_ fly at much lower altitudes, as 
>>>>>> they are flown largely not to get from one place to
>>>>>> another, but for photographing or otherwise sensing things on
>>>>>> the ground (or for recreation).
>>>>>
>>>>> BEcause of this term 'crew' I can not say whether I agree or not 
>>>>> with you.
>>>>>
>>>>> Instinctively, I'd say that there are so many other flying 
>>>>> aircraft that it is hard to say so easily at which altitudes are 
>>>>> they allowed or not, simply based on that 'crewed' qualifier.
>>>>>
>>>>> I think the point of view of 'crewed' vs 'uncrewed' is limited in
>>>>> itself, leading to potentially missing some aspects.
>>>>>
>>>>>> The FAA has established an upper limit of 400 feet AGL for small 
>>>>>> uncrewed aircraft flying under their rule appropriate
>>>>>> for most such, to provide 100 feet of vertical separation from 
>>>>>> these small UAS and where the crewed aircraft _mostly_ fly.
>>>>>
>>>>> I will not oppose - maybe it is sufficient for them.
>>>>>
>>>>> If I were to be picky, I'd say that the notion of 'AGL' itself can 
>>>>> be subject to debate (there are several sea levels in this world 
>>>>> and moreover they change as we speak) and if one asks why then I 
>>>>> reply that if one would like to put NMEA statements in ASTM 
>>>>> messages for the goal of avoiding conversions then one
>>>>> might be facing such aspects of precisely what is a sea level.
>>>>>
>>>>> But I will not go to the respective SDO, so I leave it there.  I 
>>>>> agree they set limits where they need them.
>>>>>
>>>>>> WRT units: yes it is a mess; no the EU does not use precisely the 
>>>>>> metric equivalents of feet etc. in their rules; note my original 
>>>>>> message said "EU rules are similar" not "EU rules are the same 
>>>>>> except for translation of metric units".
>>>>>
>>>>> I agree, you did not say that.
>>>>>
>>>>>> IETF does not get to write rules for aviation, therefore neither 
>>>>>> does IETF get to write rules for aviation communications; we can 
>>>>>> only provide technical standards for interoperable network 
>>>>>> protocols that _enhance_ those communications.
>>>>>
>>>>> It's a good thing, because enhancing communications is always good.
>>>>>
>>>>> Alex
>>>>>
>>>>>>
>>>>>> -----Original Message----- From: Alexandre Petrescu 
>>>>>> <alexandre.petrescu@gmail.com> Sent: Wednesday, July 12, 2023 
>>>>>> 9:45 AM To: Robert Moskowitz <rgm@labs.htt-consult.com>; Carsten 
>>>>>> Bormann <cabo@tzi.org> Cc: Stu Card <stu.card@axenterprize.com>; 
>>>>>> tm-rid@ietf.org Subject: Re: [Drip] ADSB
>>>>>>
>>>>>>
>>>>>>
>>>>>> Le 12/07/2023 à 13:56, Robert Moskowitz a écrit :
>>>>>>>
>>>>>>>
>>>>>>> On 7/12/23 06:45, Carsten Bormann wrote:
>>>>>>>> On 2023-07-12, at 11:52, Alexandre Petrescu 
>>>>>>>> <alexandre.petrescu@gmail.com> wrote:
>>>>>>>>> why not 400m
>>>>>>>> This is not a domain where we get to invent boundaries.
>>>>>>>>
>>>>>>>> (Also, generally speaking, of course we should have a strong 
>>>>>>>> bias to using SI units, but in a domain where regulation is 
>>>>>>>> widely based on furlongs per fortnight,
>>>>>>>> we’ll have to adapt.)
>>>>>>>
>>>>>>> And anyway it would be 125M to be a bit more than the Imperial 
>>>>>>> 400'.
>>>>>>
>>>>>> True.
>>>>>>
>>>>>> And it obviously begs the question whether in Europe they also 
>>>>>> have the same limit of 400' equivalent in meters.  I strongly 
>>>>>> doubt that an EU document would talk about a limit of
>>>>>> precisely 121.92 meters just because of being converted to the
>>>>>> easy to grasp 400 feet.
>>>>>>
>>>>>> At that point we talk about devices that might be different in an 
>>>>>> EU market than in an US market.
>>>>>>
>>>>>> What is the EU altitude limit for numerous drone aircraft to
>>>>>> be considered flying very low, so numerous and so low such as
>>>>>> to be forbidden to carry ADS-B equipment (or turn it off at
>>>>>> lower than that altitude if it carries one)?
>>>>>>
>>>>>>> Why 400'?
>>>>>>>
>>>>>>> I think it was to keep general aviation some reasonable distance 
>>>>>>> above people on the ground.  As the ceiling for UA that is a 
>>>>>>> consequence.
>>>>>>
>>>>>> You see, I think there is an error.
>>>>>>
>>>>>> 400 feet might be a good limit in terms of separation of
>>>>>> people and objects above their heads, but it is certainly not
>>>>>> any limit in terms of radio communication.
>>>>>>
>>>>>> If there is to be a radio communication limit (use or not use 
>>>>>> ADS-B) it should be based on the power levels it uses and the 
>>>>>> guarantees of range. In WiFi, bluetooth and 2G..5G that's how 
>>>>>> they separate.
>>>>>>
>>>>>> For example, an 5G-carrying UAS would be limited to 450meter 
>>>>>> altitude because that is how high the ground 5G oriented towards 
>>>>>> ground reaches high.
>>>>>>
>>>>>> A bluetooth-carrying UAS (and not carrying ADS-B) would be 
>>>>>> limited to 100 meter altitude because that is how high a 
>>>>>> bluetooth device is allowed to emit, by bluetooth regulation.
>>>>>>
>>>>>>> "They can't go any lower, you can't go any higher."
>>>>>>
>>>>>> Strange.  Many devices, especially those who plane or glide like 
>>>>>> these UAS drones, and helicopters too, will stay stable
>>>>>> at very many low altitudes.  Their power systems - more and
>>>>>> more performing, allows for that.
>>>>>>
>>>>>> I very well see a helicopter stable 100meter above the ground, 
>>>>>> and surely it carries an ADS-B device, if not several of them.
>>>>>>
>>>>>>>
>>>>>>> It is called boundaries to keep unequal players apart.
>>>>>>>
>>>>>>> One of the interesting debates in this is that the 400'
>>>>>>> floor is to ground obstacles like radio towers.  Thus since
>>>>>>> big birds have to stay 400' from that 700' radio tower down
>>>>>>> the block, you can take your UA up to 1100' right next to
>>>>>>> it... Or so some claim.
>>>>>>
>>>>>> Right!
>>>>>>
>>>>>> RAdio towers, or radio towers with even higher anti-flash 
>>>>>> ('paratonnerre', fr.) on them?  That adds some 10 meter to the 
>>>>>> picture, to which an UAS drone would need to pay attention, just 
>>>>>> like helicopters need to care about power lines above ground too.
>>>>>>
>>>>>>>
>>>>>>> And speaking of Imperial vs Metric...
>>>>>>>
>>>>>>> Civil aviation separation is 1000'.
>>>>>>>
>>>>>>> This has already caused incidents where a lesser Metric distance 
>>>>>>> was used by one aircraft against one using the greater 
>>>>>>> separation of Imperial.
>>>>>>>
>>>>>>> Fun!
>>>>>>>
>>>>>>> Not.
>>>>>>
>>>>>> I agree.
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>>>
>>>>>>> Bob
>>>>>>>
>>>>>
>>>>
>>>
>>> -- Standard Robert Moskowitz Owner HTT Consulting C:248-219-2059 
>>> F:248-968-2824 E:rgm@labs.htt-consult.com
>>>
>>> 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:rgm@labs.htt-consult.com
>
> There's no limit to what can be accomplished if it doesn't matter who 
> gets the credit