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

[Robert Moskowitz <[e-mail]>]

Maybe early HIP drafts before we developed the HIP RR?

We DID use TXT RR for initial testing...

On 7/25/23 16:03, Stu Card wrote:
> Bard states, inter alia:
>
> "DETs are registered as TXT records in the DNS"
>
> I find "TXT" nowhere in the referenced draft.
>
> This appears to be a LLM hallucination?
>
> -----Original Message-----
> From: Alexandre Petrescu <[e-mail]>
> Sent: Tuesday, July 25, 2023 6:44 AM
> To: Robert Moskowitz <[e-mail]>; Stu Card <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Drip] how you can help (was: ADSB)
>
>
>
> Le 12/07/2023 à 19:52, Robert Moskowitz a écrit :
>>
>> On 7/12/23 13:15, Alexandre Petrescu wrote:
> [...]
>>> - 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".
> Aha.
>
>>> - 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 will ask him separately.
>
> I just checked a couple of work programmes (SNS JU, HE Cluster 4 and ESA
> Star) under work in Europe about years 2024 and 2025, which are related to communications systems of systems including above-our-heads systems.
> To my disappointment I could not find anything about keyword 'Remote ID'
> in the UAS or Drones text.  Probably I am not looking at the right calls, or not looking right.
>
> Maybe I should check for 'Direct  ID' or 'identification of drones' or 'identification of UAS'.  I will see later.
>
> [...]
>>> - I might want to ask chatbots what they think about these two
>>> documents, just to see.
>> Will be interested.
> I asked bard of google what it thinks about the "DRIP Entity Tag (DET) Identity Management Architecture draft".
>
> I received a relatively sophisticated answer after about 10 seconds.  It calls it a 'good starting point' :-)
>
> Given that sophistication of that automated answer I will have to think harder - spend more time! - about how to give a more differentiating answer :-)
>
> There is a direction in the research world telling that maybe we should use these tools (bard etc) more, other directions that tell we should refrain from doing so.  Maybe the I-D authors want to address these comments from bard, or maybe the authors dont want to spend time on that at all.
>
> Maybe the automated comments from systems like bard can count as comments to drafts (in view of ADs), or not at all, in order to progress the drafts.
>
> Alex, humane
>
>>> 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