Re: [Drip] Comment on -arch-22

[Robert Moskowitz <[e-mail]>]

On 3/24/22 08:00, Card, Stu wrote:
> Jens --
>
> Your concerns are well taken.
>
> I did not know that expectations outside the US of how BVLOS 
> operations would work do not typically entail Internet connectivity 
> (as they seem to here).
>
> Handoff among different links (and different link technologies) is 
> something we are trying to address. In our own test flights, for C2 
> (not UAS RID), we have used HIP, MP-TCP and other protocols to fail 
> over transparently

'fall' over transparently.

:)

> from Wi-Fi to LTE when the former link quality degrades excessively 
> (due to distance or whatever), then transparently fall back when Wi-Fi 
> again becomes usable.
>
> By using a Hierarchical Host Identity Tag (HHIT) as the DRIP Entity 
> Tag (DET), we deconflate that identifier (and the public key based 
> Host Identity [HI] it represents) from any/all locators (including 
> conventional IP addresses), yet facilitate mapping between identifiers 
> and locators (e.g. using HIP DNS RRs) to support mobility and 
> multihoming (the latter facilitating make-before-break soft handoff).
>
> Bob Moskowitz and I would appreciate any inputs/help we can get on 
> leveraging DRIP (focused on UAS RID) to facilitate robust 
> identity-oriented V2I communications for C2, DAA, etc. :-)
>
> -- Stu
>
>
>
>
> On Thu, Mar 24, 2022 at 7:36 AM Jens Finkhaeuser <[e-mail]> 
> wrote:
>
>     Hi,
>
>     I am (recently) subscribed to the list, unfortunately under a
>     different email address than I selected previously.
>
>     Yes, NPA-2021-14 is a good starting point. It refers to the
>     U-SPACE regulation (EU) 2021/664 which concerns itself in more
>     detail with identification. I don't think that offhand there is
>     much conflict here with the draft in principle.
>
>     I am actually a little more concerned with the implications of the
>     last paragraph on page 5 referring to C2 links and the first on
>     the following page. The AMC on C2/C3 links always require mission
>     appropriate link performance; in this they provide some
>     parameters, but also refer back to ICAO regulations.
>
>     At any rate, given current state of the art, it is unlikely for a
>     multi-purpose drone to carry a single link technology, but hand
>     over C2/C3 connectivity between several. This, and how this
>     relates to control hand over between different ground control
>     stations is our current research focus.
>
>     Link technology and control handover tend to coincide with
>     critical phases of flight (i.e. takeoff and landing), as altitude
>     changes often trigger the need to switch links, and proximity to
>     ground control stations often require control handover. A
>     particular challenge here is posed by fixed-wing drones which can
>     land at speeds in excess of 100km/h; range and latency of RF
>     technology clearly influence the ability to switch over safely.
>
>     But also BVLOS scenarios to areas not covered by conventional 3GPP
>     means (remote, offshore, in RF shadow) will require similar link
>     and perhaps control handover as BVLOS here implies beyond RF LOS.
>
>     What this means is that the ASTM suggestion of e.g. Bluetooth 4 or
>     WiFi for broadcast RIDs is likely only workable to comparatively
>     slow drones. Conversely, the assumption that there is some
>     Internet connectivity provided by the C2 link is not in line with
>     beyond RF LOS scenarios - the draft acknowledges this, but seems
>     to focus on situations where Internet connectivity is given after all.
>
>     Again, though, this doesn't invalidate any work done on this
>     draft, or its contents. It just raises the spectre of future work
>     in fulfilling regulatory requirements in such scenarios that are
>     less ideal for communications.
>
>     I hope that clarifies my comment a little. It comes back to a
>     question of intended scope; regional scope is only one aspect.
>
>     Unfortunately, I did not consider joining IETF mailing lists until
>     very recently, or I would have been able to raise this much earlier.
>
>     Jens
>
>     ------- Original Message -------
>     On Thursday, March 24th, 2022 at 11:31,
>     <[e-mail]> wrote:
>
>>     Hi Jens,
>>
>>     Thank you for sharing these valuable comments.
>>
>>     The intent was not to be centric but we are working under the
>>     usual volunteer-based constraints. This point was discussed early
>>     in the WG (e.g.,
>>     https://datatracker.ietf.org/doc/minutes-interim-2020-drip-01-202004221100/)
>>     and this limitation was called out, e.g. (from the write-up of
>>     RFC9153):
>>
>>        Early versions of the document was largely based on the process
>>
>>        of one region (US). The WG discussed that issue at the time and
>>
>>        agreed to progress the work based on available inputs/volunteers
>>
>>        as any other IETF effort. Also, the WG agreed to record this issue
>>
>>        in an appendix. Since then, the document was enriched with inputs
>>
>>        and relevant documents from the EU region.
>>
>>     For the first point, I guess you are referring to
>>     https://www.easa.europa.eu/document-library/notices-of-proposed-amendment/npa-2021-14.
>>     Right?
>>
>>     If you can share more specific comments, this will help the WG
>>     and authors assess them.
>>
>>     BTW, you may subscribe to the list because otherwise your
>>     messages will be delayed till a moderator validates them.
>>
>>     Cheers,
>>
>>     Med
>>
>>     *De :* Tm-rid <[e-mail]> *De la part de* Jens
>>     Finkhaeuser
>>     *Envoyé :* jeudi 24 mars 2022 10:46
>>     *À :* [e-mail]
>>     *Objet :* [Drip] Comment on -arch-22
>>
>>     Hi all,
>>
>>     since I am active through my employer in European drone research
>>     (ADACORSA and COMP4DRONES projects to name just two), and our
>>     speciality here is communications which relates to
>>     identification, I read the draft with some interest. I fear a
>>     full analysis and review would require more effort than I have
>>     managed to put into it.
>>
>>     However, as a comment, it appears that the draft is very strongly
>>     related to ASTM F3411, and maybe more so than immediately
>>     apparent. I wonder how intentional that is?
>>
>>     I ask for two reasons:
>>
>>      1. The EASA regulation referenced is not the most relevant, and
>>         potentially a bit out of date; consequently, it is unclear
>>         how well this proposal will work as-is in European airspace.
>>      2. The assumptions made on communications technologies seem to
>>         exclude some drone categories and use cases (which admittedly
>>         are also a source of disagreement between some of our
>>         research partners).
>>
>>     I'd be happy to bring more perspectives to this, but I am not
>>     sure this is appropriate to the draft's intent.
>>
>>     Jens
>>
>>     _________________________________________________________________________________________________________________________
>>
>>     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.
>
>     -- 
>     Tm-rid mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/tm-rid
>
>

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