Subject: [Drip] Comment on -arch-22

From: Jens Finkhaeuser <[email-masked]>
Date: Thu, 24 Mar 2022 09:45:36 +0000

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

---

From: <[email-masked]>
Date: Thu, 24 Mar 2022 10:31:00 +0000

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 <[email-masked]> De la part de Jens Finkhaeuser
Envoyé : jeudi 24 mars 2022 10:46
À : [email-masked]
Objet : [Drip] Comment on -arch-22

Hi all,

I ask for two reasons:

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.

---

From: "Card, Stu" <[email-masked]>
Date: Thu, 24 Mar 2022 07:31:23 -0400

Jens --

It is definitely our intention/desire for DRIP to have global applicability.

As Med wrote, we have only a few volunteers in the WG. Most of us are more
familiar with the regulations of the US FAA than with those of other CAAs.
Likewise most of us are more familiar with F3411 and related work of ASTM
International (which is indeed international but began as the American
Society for Testing and Materials so still has disproportionate US
representation among its volunteers) than with the technical standards of
European and other SDOs.

We would _welcome_ whatever reviews, information or assistance you can
provide!

-- Stu

On Thu, Mar 24, 2022 at 6:31 AM <[email-masked]> wrote:

> 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):
>
>
>
> 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?
>
>
>
> *De :* Tm-rid <[email-masked]> *De la part de* Jens Finkhaeuser
> *Envoyé :* jeudi 24 mars 2022 10:46
> *À :* [email-masked]
> *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).
>
>
>
> --
> Tm-rid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tm-rid
>

---

From: Jens Finkhaeuser <[email-masked]>
Date: Thu, 24 Mar 2022 11:36:21 +0000

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

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 24 Mar 2022 07:55:19 -0400

Jens,

I would like to add that ASTM F38 does have EU participants that have 
been providing input.   In fact the addition of WiFi BEACON for 
broadcast came out of France with backing from wider EU usage.

More later.  Today is just bad for me to comment much.  Perhaps this 
afternoon US ET.

Bob

On 3/24/22 07:31, Card, Stu wrote:
> As Med wrote, we have only a few volunteers in the WG. Most of us are 
> more familiar with the regulations of the US FAA than with those of 
> other CAAs. Likewise most of us are more familiar with F3411 and 
> related work of ASTM International (which is indeed international but 
> began as the American Society for Testing and Materials so still has 
> disproportionate US representation among its volunteers) than with the 
> technical standards of European and other SDOs.
>
>     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.,
>     BTW, you may subscribe to the list because otherwise your messages
>     will be delayed till a moderator validates them.
>
>     Cheers,
>
>     Med
>
>     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:
>
>         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
>

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 24 Mar 2022 07:59:13 -0400

Jens,

Please see my draft:

https://datatracker.ietf.org/doc/draft-moskowitz-drip-secure-nrid-c2/

It specifically deals with Network RID and C2 with multiple links. Stu 
has demonstrated this over a year ago a the US Griffiths UAS test site 
in Rome NY.

Perhaps Med can pull up the URL for the video session where Stu covers this.

This is architecture.  There are a number of actual implementation 
drafts coming along at various states of readiness.

Again, I will comment more closely to your message later.  Got the 
madinas session right now, and that has specific impact to UAS.

Bob

On 3/24/22 07:36, Jens Finkhaeuser 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
>
>> 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.
>>
>> related to ASTM F3411, and maybe more so than immediately apparent. I 
>> wonder how intentional that is?
>>
>> I ask for two reasons:
>>
>>     exclude some drone categories and use cases (which admittedly are
>>     also a source of disagreement between some of our research partners).
>>

---

From: "Card, Stu" <[email-masked]>
Date: Thu, 24 Mar 2022 08:00:39 -0400

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 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 <[email-masked]> wrote:

> Hi,
>
> I am (recently) subscribed to the list, unfortunately under a different
> email address than I selected previously.
>
> 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.
>
> 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
> 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
>

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 24 Mar 2022 08:05:13 -0400

On 3/24/22 08:00, Card, Stu wrote:
> 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).
>
> 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).
>
> leveraging DRIP (focused on UAS RID) to facilitate robust 
> identity-oriented V2I communications for C2, DAA, etc. :-)
>
> -- Stu
>
>
>
>
>     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.
>
>     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.
>
>     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.
>
>     means (remote, offshore, in RF shadow) will require similar link
>     and perhaps control handover as BVLOS here implies beyond RF LOS.
>
>     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.
>
>>     BTW, you may subscribe to the list because otherwise your
>>     messages will be delayed till a moderator validates them.
>>
>>     Cheers,
>>
>>     Med
>>
>>     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.
>>
>>         potentially a bit out of date; consequently, it is unclear
>>         how well this proposal will work as-is in European airspace.
>>         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
>>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[email-masked]

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

---

From: Jens Finkhaeuser <[email-masked]>
Date: Thu, 24 Mar 2022 12:59:18 +0000

Hi,

there is some conflict between the aviation world and the Internet world, and since they meet in UAS, that's where the conflict happens.

------- Original Message -------

On Thursday, March 24th, 2022 at 13:05, Robert Moskowitz <[email-masked]> wrote:

> 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

Yes, we essentially replicate MP-TCP components but for strictly datagram/packet oriented "links" (terminology is a mess here with respect to ISO/OSI but it seemed the best compromise). This is borne out of issues with MP-TCP we've had in practice in border regions and completely unrelated to drones.

The protocol we've built here is a (set of) state machine(s) that observe/manage unidirectional flows and consider a multi-link established if at least one unidirectional flow in either direction is active. I suppose it's a generalized form of MP-TCP's behaviour. Data is encapsulated and sent over the highest priority egress flow.

In practice, we've mostly used UDP/IP uniflows that then come in pairs, so the protocol is a little overgeneralized for this case. However, it allows us to use different send and return channels.

I've written a draft paper about this, but it never got all that far due to other work items gaining priority. If there's an interest in this in the IETF, I wouldn't quite know which WG or when to carve out time to convert this to an IETF appropriate form. Plus, my employer would have to agree.

Not that this is the main topic here.

> 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. :-)

Well, when I mentioned this aviation - network "conflict" above, we've noted during our cooperation that the transparent failover is not something that sits all too well with the aviation world. They're very much in favour of higher level functions being in control of the failover. That's something we can address, but detracts a little from the simplicity of a plugin-in, multi-link technology. Live and learn.

More to the point: I think the identifier/locator split you're proposing as well as the specific formats for each are just fine, for what it's worth, but my initial caveat that I haven't had all that much time yet for review still stands.

First point last: I think the majority of BVLOS scenarios do assume Internet connectivity. Strictly speaking that's not true, but it is in practical terms.

EASA consideres different categories of drones; we tend to focus on the "specific" category, which has weight/range/lift characteristics suitable for commercial or emergency delivery missions. Because of the commercial application, there's a strong desire to have low cost - both in hardware and operations - which must be balanced against the safety needs of the regulators.

So any connectivity options are essentially based on off the shelf offerings, which also means from a reliability/security perspective they're treated as black channel. But for the purposes here, within size, weight and power limits, it's easier to cram more of them into a drone and get reliability from a software layer above than to invest into different radio technology.

So in practical terms, most commercial mission profiles will be able to rely on 3GPP availability (maybe failing over to Wifi), which means Internet access. That much is very true.

But a variety of commercial or emergency applications are very explicitly about remote or inaccessible areas. One scenario we're discussing revolves around a rescue situation within a burning chemical factory. You send in a robot on wheels and a swarm of drones to map the area. The robot will most certainly act as radio base station for the drones, and it may also act as a limited ground control station - especially when it's own link to the outside of the building is interrupted. Even if that link is stable, a mobile ground control station placed outside of the building in a van may not provide Internet access in all areas. Identification becomes necessary whenever the drone loses and regains connectivity to its GCS, whichever that is.

The good news here is that this doesn't necessarily need to fit into U-SPACE's network identification needs. It may be enough for U-SPACE to cordon off the entire area because of the emergency situation, and let identification become an entirely local concern. But the same drone may need to report to U-SPACE in the next mission, so building distinct and incompatible identification systems does not seem sensible.

I really do need to read the DRIP drafts in much more depth... I saw the "last call" and did a bit of a panic review. I'll be able to get to that... maybe next week? I'll let you know.

Jens

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 24 Mar 2022 09:07:52 -0400

Again, no real time to review and comment in depth, but I am active in 
ICAO and the GRAIN work where aviation and internet are intersecting.  
Big time.  :)

I will only be able to be in the first part of cfrg and then off to the 
dentist.  Yet again.  Sigh.  I hope to be able to function this 
afternoon here.  But Med wants me cracking on the next ver of drip-rid.  ;)

On 3/24/22 08:59, Jens Finkhaeuser wrote:
> Hi,
>
> there is some conflict between the aviation world and the Internet 
> world, and since they meet in UAS, that's where the conflict happens.
>
> Yes, we essentially replicate MP-TCP components but for strictly 
> datagram/packet oriented "links" (terminology is a mess here with 
> respect to ISO/OSI but it seemed the best compromise). This is borne 
> out of issues with MP-TCP we've had in practice in border regions and 
> completely unrelated to drones.
>
> The protocol we've built here is a (set of) state machine(s) that 
> observe/manage unidirectional flows and consider a multi-link 
> established if at least one unidirectional flow in either direction is 
> active. I suppose it's a generalized form of MP-TCP's behaviour. Data 
> is encapsulated and sent over the highest priority egress flow.
>
> In practice, we've mostly used UDP/IP uniflows that then come in 
> pairs, so the protocol is a little overgeneralized for this case. 
> However, it allows us to use different send and return channels.
>
> I've written a draft paper about this, but it never got all that far 
> due to other work items gaining priority. If there's an interest in 
> this in the IETF, I wouldn't quite know which WG or when to carve out 
> time to convert this to an IETF appropriate form. Plus, my employer 
> would have to agree.
>
> Well, when I mentioned this aviation - network "conflict" above, we've 
> noted during our cooperation that the transparent failover is not 
> something that sits all too well with the aviation world. They're very 
> much in favour of higher level functions being in control of the 
> failover. That's something we can address, but detracts a little from 
> the simplicity of a plugin-in, multi-link technology. Live and learn.
>
> More to the point: I think the identifier/locator split you're 
> proposing as well as the specific formats for each are just fine, for 
> what it's worth, but my initial caveat that I haven't had all that 
> much time yet for review still stands.
>
> First point last: I think the majority of BVLOS scenarios do assume 
> Internet connectivity. Strictly speaking that's not true, but it is in 
> practical terms.
>
> EASA consideres different categories of drones; we tend to focus on 
> the "specific" category, which has weight/range/lift characteristics 
> suitable for commercial or emergency delivery missions. Because of the 
> commercial application, there's a strong desire to have low cost - 
> both in hardware and operations - which must be balanced against the 
> safety needs of the regulators.
>
> So any connectivity options are essentially based on off the shelf 
> offerings, which also means from a reliability/security perspective 
> they're treated as black channel. But for the purposes here, within 
> size, weight and power limits, it's easier to cram more of them into a 
> drone and get reliability from a software layer above than to invest 
> into different radio technology.
>
> So in practical terms, most commercial mission profiles will be able 
> to rely on 3GPP availability (maybe failing over to Wifi), which means 
> Internet access. That much is very true.
>
> But a variety of commercial or emergency applications are very 
> explicitly about remote or inaccessible areas. One scenario we're 
> discussing revolves around a rescue situation within a burning 
> chemical factory. You send in a robot on wheels and a swarm of drones 
> to map the area. The robot will most certainly act as radio base 
> station for the drones, and it may also act as a limited ground 
> control station - especially when it's own link to the outside of the 
> building is interrupted. Even if that link is stable, a mobile ground 
> control station placed outside of the building in a van may not 
> provide Internet access in all areas. Identification becomes necessary 
> whenever the drone loses and regains connectivity to its GCS, 
> whichever that is.
>
> The good news here is that this doesn't necessarily need to fit into 
> U-SPACE's network identification needs. It may be enough for U-SPACE 
> to cordon off the entire area because of the emergency situation, and 
> let identification become an entirely local concern. But the same 
> drone may need to report to U-SPACE in the next mission, so building 
> distinct and incompatible identification systems does not seem sensible.
>
> I really do need to read the DRIP drafts in much more depth... I saw 
> the "last call" and did a bit of a panic review. I'll be able to get 
> to that... maybe next week? I'll let you know.
>
> Jens
>

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 24 Mar 2022 17:19:29 -0400

Jens,

I have had a few moments to reread your message.  Let me try and tell 
you what our goals are for DRIP and what is in the immediate pipeline 
and what remains to tackle.

The DRIP charter is at:

https://datatracker.ietf.org/wg/drip/about/

we are constrained by our charter to be working on Remote ID, but that 
includes Network Remote ID.

Our first set of work is around Broadcast Remote ID, and I need to 
finish up the main document on our Trustworthy Remote ID using 
Hierarchical Host Identity Tags (HHIT).  Adam is working on the 
broadcast authentication messages and the Remote ID registration pieces.

One last part of the broadcast part is my crowd-sourced remote ID draft 
of which we have a customer that wants me to get this finished as well.

Operator privacy SHOULD be important for broadcast, but neither the FAA 
or EU seem to care about this, but my draft is available:

Then we move on to Network Remote ID.  I should add that supposedly once 
ASTM F38 finishes the current 1.1 document there is a general agreement 
to provide an 'open standard' for Network Remote ID. Currently, each USS 
has its own flavor of NRID.  This is our opportunity to drive the F38 
and other processes.  I really need to finish up Broadcast work so I can 
really fill in Network and would greatly love to have real help!  You 
seem to have a piece of the understanding of what is really perhaps 
needed here.

BTW, it is from the EU participants in F38 where the push to do an open 
Network RID approach.

I look forward to talking to you about this.  In my opinion, C2 and NRID 
use similar solutions, but C2 is more demanding in that both parties may 
move in the network.

As far as controlling media handoff rather that 'transparent', there is 
the work done in IEEE 802.21 that MAY be of help.  Lots of good work 
done, but there was no compelling use case.  Perhaps it is here?

Bob

---

From: Jens Finkhaeuser <[email-masked]>
Date: Fri, 25 Mar 2022 09:25:41 +0000

Hi,

thank you for this, it is very useful. To jump to one of the last points first, I would be glad to be of assistance, but again need to familiarize myself with the existing documents much more. Speaking to my boss, it seems there is a way to relate this to an ongoing R&D project, so there do not seem to be too many constraints on that side, either.

The charter certainly reads as if the use-cases we're discussing in our projects are relevant here, so I can certainly contribute from that perspective.

I'll dig deeper into the drafts, then!

Some more comments in-line.

------- Original Message -------

On Thursday, March 24th, 2022 at 22:19, Robert Moskowitz <[email-masked]> wrote

> Our first set of work is around Broadcast Remote ID, and I need to finish up the main document on our Trustworthy Remote ID using Hierarchical Host Identity Tags (HHIT). Adam is working on the broadcast authentication messages and the Remote ID registration pieces.

I have skimmed through that draft as well (need to read deeper).

> One last part of the broadcast part is my crowd-sourced remote ID draft of which we have a customer that wants me to get this finished as well.
> 

> Operator privacy SHOULD be important for broadcast, but neither the FAA or EU seem to care about this, but my draft is available:

I did not see a link to that, but if it's within the WG I can find it.

> Then we move on to Network Remote ID. I should add that supposedly once ASTM F38 finishes the current 1.1 document there is a general agreement to provide an 'open standard' for Network Remote ID. Currently, each USS has its own flavor of NRID. This is our opportunity to drive the F38 and other processes. I really need to finish up Broadcast work so I can really fill in Network and would greatly love to have real help! You seem to have a piece of the understanding of what is really perhaps needed here.

I try, and within the limits of what I have been working on, I suppose I do.

> BTW, it is from the EU participants in F38 where the push to do an open Network RID approach.

That'll definitely help in financing my contributions!

> I look forward to talking to you about this. In my opinion, C2 and NRID use similar solutions, but C2 is more demanding in that both parties may move in the network.

Yes, think so as well. The key to is IMHO to make sure the DRIP version of NRID is compatible with the constraints of C2. Conceptually there is no conflict that I can see, but in implementation details there may be.

> As far as controlling media handoff rather that 'transparent', there is the work done in IEEE 802.21 that MAY be of help. Lots of good work done, but there was no compelling use case. Perhaps it is here?

I'll have to review that. We've explicitly treated the link layer as "black channel" for cost reasons, but that doesn't mean we can't learn from it.

I'll review the drafts, and provide some overall feedback when I have a better understanding!

Jens

---

From: <[email-masked]>
Date: Fri, 25 Mar 2022 13:59:31 +0000

Hi Jens,

Thank you for the follow-up.

FWIW, I opened an issue to cite the npa doc to make sure the authors will addressed it: https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/36.

Feel free to report any issue you may found on the arch I-D either using the list or https://github.com/ietf-wg-drip/draft-ietf-drip-arch/. PRs are encouraged as well.

Your comments will be considered like any other IETF LC comments. The LC runs till 2022-04-06.

Cheers,
Med

De : Jens Finkhaeuser <[email-masked]>
Envoyé : vendredi 25 mars 2022 10:26
À : Robert Moskowitz <[email-masked]>
Cc : [email-masked]; BOUCADAIR Mohamed INNOV/NET <[email-masked]>; Card, Stu <[email-masked]>
Objet : Re: [Drip] Comment on -arch-22

Hi,

---

From: Andrei Gurtov <[email-masked]>
Date: Tue, 29 Mar 2022 18:06:33 +0200

Hello Jens,

Thanks for interest in DRIP and greetings from nearby Sweden.

Maybe you've heard about EU projects AiRMOUR and Corus-Xuam where we try 
to demo DRIP as a part of their tests.

https://airmour.eu/

https://corus-xuam.eu/

Btw, there is an interesting show from a Swiss company Involi about an 
add-on box for Remote ID, should we get them involved in DRIP?

https://dronelife.com/2022/03/27/remote-id-drone-tracker-leman-remoteid-from-involi-video/

BR Andrei
-- 
Andrei Gurtov, PhD, ACM Distinguished Scientist
Professor, LiU, Sweden
Chair, IEEE Sweden
https://www.ida.liu.se/~andgu38/

---

From: Jens Finkhaeuser <[email-masked]>
Date: Wed, 30 Mar 2022 10:49:13 +0000

Hi,

I was under the impression that Corus is completed. I do not know the -xuam postfix. Is it a follow-on or subproject?

Since Corus is more related to U-SPACE and therefore (internet-) connected services, and our projects are more related to the vehicles themselves, I suspect there is some use in better coordination. We do of course consume results from such projects, but I get the impression that on occasion they're less connected than might be useful. That's generally the case between any of these projects, also we are sometimes busy transferring insights from one to the other and back.

It's interesting as well that the drone identification issue overlaps in the communication space with the more general discussion occurring in int-area on locators vs identifiers. The latter here is a network identifier, which from a communications perspective shouldn't be all that different from the drone identifier - either one derived from the other, or the same. That is, it is desirable from a ground control station to "speak with the drone" rather than "speak with the first network interface on the drone" or "speak with the IP address that the first network interface of the drone currently has assigned".

I'm trying to provide this perspective to that conversation at the moment. That's also the lens through which I'm exploring DRIP. Fun times ahead!

Jens

------- Original Message -------

> Maybe you've heard about EU projects AiRMOUR and Corus-Xuam where we try to demo DRIP as a part of their tests.
> 

> Btw, there is an interesting show from a Swiss company Involi about an add-on box for Remote ID, should we get them involved in DRIP?
>

---

From: "Card, Stu" <[email-masked]>
Date: Wed, 30 Mar 2022 08:20:32 -0400

Jens --

The point of your 3rd paragraph about an aircraft identifier being useful
for V2X communications if it is a network identifier and the distinction of
that from a locator is precisely why my coworkers and I came to the IETF
for help with what we call Trustworthy Multipurpose Remote Identification
(tm-rid). I did not know that discussion of that distinction had resumed in
int-area, thanks for that tip!

The need to be able to trust that an aircraft (or other aviation related
entity) claiming an identity (and associated identifier) is why we turned
not to ILNP, LISP or any of the other locator-identifier split approaches
but to HIP, which naturally bakes it in. HIP being for hosts (in this
context, individual end systems on a specific aircraft, rather than the
collection of all intermediate and end systems on that aircraft) suggests
we may want to revisit something like

https://datatracker.ietf.org/doc/draft-henderson-hip-vpls/

as well as

https://datatracker.ietf.org/doc/draft-nikander-esp-beet-mode/

DRIP Architecture is intended to support making UAS RID both trustworthy
and immediately useful, e.g. to initiate policy-authorized Observer to
Pilot (O2P) or other V2X comms. We would really appreciate your thoughts on
this.

-- Stu

On Wed, Mar 30, 2022, 06:49 Jens Finkhaeuser <[email-masked]> wrote:

> Hi,
>
> I was under the impression that Corus is completed. I do not know the
> -xuam postfix. Is it a follow-on or subproject?
>
> Since Corus is more related to U-SPACE and therefore (internet-) connected
> services, and our projects are more related to the vehicles themselves, I
> suspect there is some use in better coordination. We do of course consume
> results from such projects, but I get the impression that on occasion
> they're less connected than might be useful. That's generally the case
> between any of these projects, also we are sometimes busy transferring
> insights from one to the other and back.
>
> It's interesting as well that the drone identification issue overlaps in
> the communication space with the more general discussion occurring in
> int-area on locators vs identifiers. The latter here is a *network*​
> identifier, which from a communications perspective shouldn't be all that
> different from the drone identifier - either one derived from the other, or
> the same. That is, it is desirable from a ground control station to "speak
> with the drone" rather than "speak with the first network interface on the
> drone" or "speak with the IP address that the first network interface of
> the drone currently has assigned".
>
> I'm trying to provide this perspective to that conversation at the moment.
> That's also the lens through which I'm exploring DRIP. Fun times ahead!
>
> Jens
>
> Chair, IEEE Swedenhttps://www.ida.liu.se/~andgu38/
>