Re: [Drip] how you can help (was: ADSB)

[Robert Moskowitz <[e-mail]>]

On 7/12/23 13:15, Alexandre Petrescu wrote:
> Stu,
> I agree with focusing on the work of the WG.
>
> I will look at the two documents you proposed later.
> draft-ietf-drip-auth and "*DRIP Entity Tag (DET) Identity Management
> Architecture *draft".
>
> When I look at them I will look from a few perspectives:
>
> - do the proposed auth mechanism also use new 'post-quantum' (i.e.
> quantum-resistant algos) and if yes how.

No.  Read rfc9374 Security Considerations on this.

Basically no bandwidth for those monsters.


> - is the identification mechanism compatible more universally on a
> vertical ladder to cover not only FNAC drones (drones one can buy from
> FNAC for large public and have bluetooth and wifi) but more towards
> high, like higher altitude platforms, and also more towards below, like
> in tunnels or under water.  If conversions are needed then I will
> recommend against conversions because conversions are difficult, despite
> you seeming to assume all people think they are easy.  I do not 
> disagree with you assuming so, and I do not disagree with all people 
> thinking that conversions are straightforward.

That is the plan and part of the reason for my activity in ICAO.

> - I will try to see where the implementations of these two drafts can
> be, open source or not, how can I consult as a lambda user, how can a
> programmer feel these drafts.

Dr. Gurtov has open code.  Join in.

> - I might want to check whether 3GPP, ETSI or ISO refer to these two
> documents, or whether these two documents describe mechanisms under a
> different name that is described also at other SDO among these 3.

Nope.  3GPP is pushing IEEE 1609.2 so that UAS is part of ground 
vehicles, not NAS.  IMO.

Best I can find is ETSI and ISO not doing anything for securing "Direct ID".

> - I might want to check what the R&D strategy in Europe and future calls
> for R&D projects tell about drone identification technologies.

Check with Dr. Gurtov.

> - I might want to check - maybe not the last thing - whether suggestions
> of breaks in DRIP technologies exist (like 'a break in AI', 'a break 
> in 6G') whether proposals exist and how to address them. Just to make 
> sure.

Please do.


> - I might want to ask chatbots what they think about these two 
> documents, just to see.

Will be interested.

> But only later can I do all that.   I suspect that only a few remarks 
> coming from such an analysis might be interesting to a focused work in 
> WG on these two documents, so I will have to trim accordingly.
>
> Until then I can only thank you for the clarifications.
>
> Alex
>
>
>
> Le 12/07/2023 à 18:04, Stu Card a écrit :
>> Alexey --
>>
>> I greatly appreciate your efforts to contribute to DRIP work.
>>
>> I only ask that you try to stay on topic, within the scope of what
>> our WG is chartered to and could feasibly do.
>>
>> Many things are broken in this world, we cannot fix them all. Just 
>> within aviation related instrumentation and communication, there are
>>  many problems, some of them long-standing, that the DRIP WG cannot
>> even address. You have mentioned some of them, like what is really
>> meant by AGL, for which there are competing definitions, which one
>> hardworking smart knowledgeable friend of ours has dedicated much
>> effort to trying to reconcile. But those are mostly _aviation_
>> issues, not UAS RID specific, much less in DRIP scope.
>>
>> We need to refer, in DRIP,  to much external context. We must not be
>>  distracted by constantly caveating those references with our own 
>> opinions about them, changing their terminology to something we like
>>  better, translating their units (when readers can easily do their
>> own unit conversions if needed), etc.
>>
>> We must focus our efforts on what we uniquely can contribute to
>> making UAS RID more useful: _trustworthy_ & _immediately actionable_
>> to benefit safety & security of participating & nonparticipating
>> people, property, and the environment.
>>
>> To contribute to this important work, keeping the above in mind,
>> please review our *DRIP Entity Tag Authentication Formats & Protocols
>> for Broadcast Remote ID *draft at 
>> https://datatracker.ietf.org/doc/draft-ietf-drip-auth/ 
>> <https://datatracker.ietf.org/doc/draft-ietf-drip-auth/>
>>
>> Then please review the *DRIP Entity Tag (DET) Identity Management 
>> Architecture *draft. If you really want to dig in, volunteer to 
>> co-author some of the registry related drafts.
>>
>> Thanks!
>>
>> -- Stu
>>
>> Get Outlook for Android <https://aka.ms/AAb9ysg> 
>> ------------------------------------------------------------------------
>>
>>
> *From:* Alexandre Petrescu <[e-mail]>
>> *Sent:* Wednesday, July 12, 2023 11:13:50 AM *To:* Stu Card
>> <[e-mail]> *Cc:* [e-mail] <[e-mail]> 
>> *Subject:* Re: [Drip] ADSB 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.
>>
>> 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
>>> <https://aka.ms/AAb9ysg>>
>>>
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>>
> *From:* Alexandre Petrescu <[e-mail]>
>>> *Sent:* Wednesday, July 12, 2023, 10:43 *To:* Stu Card
>>> <[e-mail]>; Robert Moskowitz 
>>> <[e-mail]>; Carsten Bormann <[e-mail]> *Cc:*
>>> [e-mail] <[e-mail]> *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 
>>>> <[e-mail]> Sent: Wednesday, July 12, 2023
>>>> 9:45 AM To: Robert Moskowitz <[e-mail]>; Carsten
>>>> Bormann <[e-mail]> Cc: Stu Card <[e-mail]>;
>>>> [e-mail] 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 
>>>>>> <[e-mail]> 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:[e-mail]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit