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

[Alexandre Petrescu <[e-mail]>]

Le 12/07/2023 à 19:52, Robert Moskowitz a écrit :
> 
> 
> 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.

True, you told me so earlier, I remmeber.  But recently someone 
published some measures over in PQUIP, and in the text they do mention a 
parameter of bandwidth like 10mbit/s.  I do not know what the results 
are, but 10mbit/s is, I think, what a version of bluetooth can do, and I 
think (I might be wrong) DRIP uses exclusively bluetooth.

If still the bandwidth criterion holds, despite what that pdf says, then 
it's fine.

  https://wggrs.nl/post/tls-measurements/handout-tls.pdf

Alex

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