Re: [Drip] Comment on -arch-22

Jens Finkhaeuser <jens@interpeer.io> Fri, 25 March 2022 09:25 UTC

Return-Path: <jens@interpeer.io>
X-Original-To: tm-rid@ietfa.amsl.com
Delivered-To: tm-rid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F143A115D for <tm-rid@ietfa.amsl.com>; Fri, 25 Mar 2022 02:25:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=interpeer.io
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cjv62Jdh0jVi for <tm-rid@ietfa.amsl.com>; Fri, 25 Mar 2022 02:25:47 -0700 (PDT)
Received: from mail-4323.proton.ch (mail-4323.proton.ch [185.70.43.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F40563A110B for <tm-rid@ietf.org>; Fri, 25 Mar 2022 02:25:46 -0700 (PDT)
Date: Fri, 25 Mar 2022 09:25:41 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interpeer.io; s=protonmail; t=1648200343; bh=CUZyNsJiPKjBYhSUX95LVTPmQUzgAdTeirNDybbzuMY=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=Llje2QTia4aMqXShxQ7z9XbVrlDoEj1rfv3FDyHTI8bZ/Vrqtr/mkKG0S4p8wV1xG mnLn8o5VuxSbD7iT2gYRFzpTy9cSw3lPuCkbY0wP0EC+gTFcHcDosYjfr31dC2Zk6z zf6E1YuvpnE0SWAQbMGz0aJC7f5ehRU22WExOs3I=
To: Robert Moskowitz <rgm@labs.htt-consult.com>
From: Jens Finkhaeuser <jens@interpeer.io>
Cc: "tm-rid@ietf.org" <tm-rid@ietf.org>, Mohamed Boucadair <mohamed.boucadair@orange.com>, "Card, Stu" <stu.card@axenterprize.com>
Reply-To: Jens Finkhaeuser <jens@interpeer.io>
Message-ID: <CAaxfba55FNBc1Bu8BO3eu_dckS4KBI5UolrpBa0XuJ1o9u2o3a4f6CKLXiuRybYyO2CKgLJ34XrH8lwOZawVU5udiMr7ZoGm-fbW9mmK1I=@interpeer.io>
In-Reply-To: <789c9cdb-4080-b885-a516-d44ae2483bef@labs.htt-consult.com>
References: <t941p8wbPadYaW5iXMZZ92fRZxA9AShZYY2-vpoY4Nh9uhgeZozaJJI1GnLhzKJlirvUFL4vy8ARuip2QVfc0Br6upFgliBWVCM2YXJsWhw=@protonmail.com> <30761_1648117860_623C4864_30761_38_1_a40164ce7fbe4102b749d156b9e568e3@orange.com> <Am3ylFsd9lsuyQBORGgwqaSzDhclB0shSOvnajujZB8MMgwTl_RcgLGh-DV5x-IlyOPaGeJ2BhFd0hEnf87XFVA_bJy0IqcBECtZhugnnPE=@interpeer.io> <CAKM0pYNJfgC0++csfj4S2J6xLvtwHZhxM3=JJQMN-=u9KaoKqA@mail.gmail.com> <5c1891d0-8560-7bf9-64c4-e7e63fb6f8a1@labs.htt-consult.com> <fwDcXoFeFTbD97RI08XWNPEtIk8Tq6UvlncYo651OsG9ifILA_JWZlETYZAal-G16lOjXHJWvdpXHeMq6May_OhDbYCtcPZrb3Adu7nQQNE=@interpeer.io> <789c9cdb-4080-b885-a516-d44ae2483bef@labs.htt-consult.com>
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------3f4ca7b76665ee5ea6ca18a7018cd262e578d937085cca07a8941a2115589bcd"; charset=utf-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/tm-rid/7Pf80rRPpZd2DmLQpwBxVpOM1HQ>
Subject: Re: [Drip] Comment on -arch-22
X-BeenThere: tm-rid@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Drone Remote Identification Protocol <tm-rid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tm-rid>, <mailto:tm-rid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tm-rid/>
List-Post: <mailto:tm-rid@ietf.org>
List-Help: <mailto:tm-rid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tm-rid>, <mailto:tm-rid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Mar 2022 09:25:54 -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 <rgm@labs.htt-consult.com> 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