Re: [Drip] [Tm-rid] Review of draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and other
"Stuart W. Card" <stu.card@axenterprize.com> Fri, 30 October 2020 04:44 UTC
Return-Path: <stu.card@axenterprize.com>
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 DD9BF3A07C4 for <tm-rid@ietfa.amsl.com>; Thu, 29 Oct 2020 21:44:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.346
X-Spam-Level:
X-Spam-Status: No, score=-2.346 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, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=axenterprize.com
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 eF1Jaaafn09q for <tm-rid@ietfa.amsl.com>; Thu, 29 Oct 2020 21:44:45 -0700 (PDT)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05EE43A0957 for <tm-rid@ietf.org>; Thu, 29 Oct 2020 21:44:24 -0700 (PDT)
Received: by mail-io1-xd34.google.com with SMTP id p7so6231491ioo.6 for <tm-rid@ietf.org>; Thu, 29 Oct 2020 21:44:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axenterprize.com; s=google; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=JwgiE3TV/wSesLiyIeIkUSh1i1n5NHepX8ZcEB0B8Ic=; b=lU9mvVDsL1H00XsMl/7vcNoNxUafxphh0gNKVfqZBBH0T7bbVeQqRXWCvQ6WomA8QE HS4jGYySSNtfi7gMkAgJY+yfyBL61buGaqSPDbE541Ft2z9LPW9OSJeDrokVVOu+MRUG fU/O4GGOdrxV4yBFNZ0HJDnmeNMZQqHglnG6I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=JwgiE3TV/wSesLiyIeIkUSh1i1n5NHepX8ZcEB0B8Ic=; b=t8qTcneMcYURXKV2pJ6lO1t1GPew82rHZpF0nmYlqS41yHQGURpX7f4hJLcLvSWZnz to/bWSpDabX/h+8xLhc9BGrqslnyUUklI1VITlu8CSq6bvBKXvZxQO380dqr2JQZt0ne 5+ZIdMrUoafKqztjvtQMItOdmc10w6u4nqgJrQ76MsDgw9KOnO88sGH5djnHnx8IdO+Z 1VlvD351pDyh2qCjb/ppFJJL7zbGguMqIcBKa4GdEjUNr9rvQ+tc2Wy3jC0BdGOCVM38 PcPDlEyC2UP1+1inytLYEF2pxSNLT2LZ9vD8BV/2WEk4tDL0mR8mlQGrsXzpzkVK2UBE 4zXQ==
X-Gm-Message-State: AOAM531hholaGMiVEi7pcuRUGYub7id1/b2lWgzP+alD1cpRgtzwH4rv vbQVAFW3pXTmKCPfHZMwbM0J4jxv/6Voh9Cg
X-Google-Smtp-Source: ABdhPJypv8+9T8URDa+W9h1XOnLsTNZD2wRyeuyRQl5iBhk3zgoKpU7vn+ibKjUPBsPLr9MZ6ZS6yQ==
X-Received: by 2002:a02:b78b:: with SMTP id f11mr574033jam.57.1604033063946; Thu, 29 Oct 2020 21:44:23 -0700 (PDT)
Received: from [192.168.1.107] (ip-72-10-210-250.nwptny.ntcnet.net. [72.10.210.250]) by smtp.gmail.com with ESMTPSA id x13sm3662937iob.8.2020.10.29.21.44.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Oct 2020 21:44:22 -0700 (PDT)
To: tm-rid@ietf.org
References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc>
Cc: amelia.ietf@andersdotter.cc
From: "Stuart W. Card" <stu.card@axenterprize.com>
Message-ID: <b93a29d2-2fd6-a03c-a74d-4f0214cdfe05@axenterprize.com>
Date: Fri, 30 Oct 2020 00:44:22 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0
MIME-Version: 1.0
In-Reply-To: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tm-rid/YFhYRKpqoUXJUDlhkDcAeCQJ434>
Subject: Re: [Drip] [Tm-rid] Review of draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and other
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, 30 Oct 2020 04:44:48 -0000
I just went through this review one more time and want to reiterate to Amelia and to the working group not only how informative it was but also how refreshing I found this approach to gently criticizing a draft. On 7/6/2020 2:15 PM, Amelia Andersdotter wrote: > Dear all, > > Having recently read Jane Jacob's Nature of Economies, I was inspired to > write this review in the form of a platonic dialogue. It's based on my > personal, professional judgement and RFC6973 as well as RFC8280, and the > discussants will indicate which source materials are referenced when > appropriate. I'm hoping this will also make the review a bit lighter > than the human rights reviews based on RFC8280 that I produced back in > 2018, as well as remove ambiguities w.r.t. the obligations to take any > of these notes into account in further drafting. > > Scene I. The Scholar and the Apprentice are on a journey to the capital. > > - In some European languages, there is no language-inherent ways to > express the difference between safety and security, said the Scholar. In > some Scandinavian languages, for instance, the closest translation of > "safety" rather brings the mind to a state of personal comfort. It is > easy to get lost in translation when operating in fields that rely a lot > on the distinction. > > - Oh, you mean that restrictions in the source language might make > localization [RFC8280, 6.2.12] as well as internationalization [RFC8280, > 6.2.5] more difficult? said the Apprentice. > > - Indeed, and also accessibility [RFC8280, 6.2.11] and outcome > transparency [RFC8280, 6.2.19], the Scholar replied. It concerns not > only the direct encoding of an issue into an alphabet, abugida or abjad > that is in use in a place, but also the concepts given voice in target > communities. > > - In a heavily regulated field, such as airspace, there must be many > pitfalls, mused the Apprentice. I had actually already reflected along > these lines, perhaps since I myself speak such a language natively, when > reading [draft-drip-arch-02, 3.1.2]. The public internet DNS hierarchy > relies a lot on a single jurisdiction for guaranteeing, ultimately, > integrity [RFC8280, 6.2.16], authenticity [RFC8280, 6.2.17] and > confidentiality [RFC8280, 6.2.15] - so at least with safety features > such as DNSSEC, the trustworthiness of which intrinsically relies on a > process dependent on the entry visas into a single jurisdiction. Was > this the type of ambiguity you wanted to avoid? > > - Ah, security features, safety features, and trade-offs, especially > with privacy [RFC6973, 7.4] - and it doesn't even obviously map to any > of the requirements in [draft-drip-reqs-02] where the only guidance > contained in [draft-drip-reqs-02, 4.4] concerns the public nature of the > registry itself, said the Scholar. They're barely touched upon, but > within the understanding that safety and security must be different and > perceived differently. Does control over an airspace identifier or the > ability to provision it imply control over an airspace as such [RFC8280 > 6.2.6]? And who may have preferences in these matters? And why? > > - Indeed, continues the Scholar. It is advisable to steer clear of such > waters, and maybe this ontological ambiguity is not the only troubled > stream. Many endeavours exist, like DiNS in France (AFNIC) or SHG in > Canada (CIRA), which rather than building DNS-based technology > registries into the global internet architecture, build them in parallel > using the same open standards [RFC8280 6.2.7]. But this is optional in > [draft-drip-arch-02, 3.1.2], even receommended against! And a similar > recommendation occurs in [draft-drip-arch-02, 3.2.2] - why not leave the > door more open to private registries? [draft-drip-arch-02, 7] would have > us think that architectural implications mostly impact the content of > the identifiers in [draft-drip-arch-02, 4]. Indeed, even > [draft-drip-arch-02, 4] would have us think that the ASTM requirements > mostly relate to ID bit sizes and the special adaptions required to fit > what must be fit in a constrained space. [draft-drip-arch-02, 6] even > leads our thoughts down this path! Although I'll have to return to the > subject of [draft-drip-arch-02, 6] later... > > - Size matters, said the Apprentice cheerfully. And maps unspokedly to > [draft-drip-reqs-01, 4.2 ID-1]. > > The two stood in silence for a few moments as the wind picked up. > > - While it's true that centralization sometimes suffers an unnecessarily > bad name, continued the Scholar, it is equally true that > decentralization [RFC8280, 6.2.13] affords a certain adaptability > [RFC8280, 6.2.18]. Was there not a private registry in figure 1 of > section 1 Introduction anyway? > > - What is it that you normally say? said the Apprentice, grasping for a > words. > > - Every country needs a flag, an anthem and airline, said the Scholar. > But the figure, the figure. > > - I have it here, said the Apprentice. There is a private registry. It's > also in [draft-drip-reqs-01, 4.4 REG-2]. I did not easily see the > connection at first, but it is there. And then there is the... > > - Yes? said the Scholar. > > - Well, said the Apprentice. Why is there an illustration of Net-RID in > figure 2, but not of Broadcast RID? I could not work it out. It actually > did not seem sensible to me to re-iterate from [draft-drip-reqs-02] the > RID classifications from ASTM [F3411-19] at all. > > - Maybe it was included for extra clarity? said the Scholar. Personally, > I found myself objecting more strongly to the second paragraph of the > Introduction - it does not seem to me an architectural issue that "many > considerations" dictate anything in particular, nor do I see the need to > clarify that "CAAs worldwide" without further qualification request some > thing. Maybe it could be removed. Similarly, I did not immediately see > the usefulness of speculating on the work of other SDOs, such as 3GPP. > > - "Network and Broadcast RIDs are expected to be similarly constrained > irrespective of the methods used to transmit them"? said the Apprentice. > > - Your rephrasing makes it more digestible, indeed, responded the > Scholar. I suppose in either case it counts as an example of upholding > heterogeneity [RFC8280, 6.2.8]. > > - And I was worried about some aspects of [draft-drip-arch-02, 7] too, > said the Apprentice. Like whether the UAS registration number and the > unique physical serial numbers are both permanent, or whether they could > be transiently linkable as suggested in [draft-drip-arch-02, 5]? > > - Who knows? said the Scholar. In the capital, they may have better > knowledge on these topics. As far as I have understood the architectural > descriptions of U-space, federation, modularity and privacy are sought > after features in any ID carrying scheme for UAS under EASA regulations > and indeed the broader corpus of EU regulations - whether it be GOF or > SAFIR or something else. It even seems to me that these are topics > better left for a requirements document and not an architecture document! > > - It was already said, said the Apprentice. Hold on, I have the e-mail > here somewhere... > > - To the point, said the Scholar. It remains to be seen if any submodule > of the short-listed U-Space architecture, such as the FIMS, is equally > under assumptions of federation, modularity and privacy as the entirety > of the architecture. Some internet standards would appear to have a big > advantage if these federation requirements apply to sub-modules such as > the FIMS too. [draft-drip-arch-02, 7] does not yet resolve it, and maybe > even can't. The [draft-drip-reqs-01, 4] does a good job of laying down > requirements on identifiers to be transmitted. > > - What I did miss too, said the Scholar, was the more direct references > to the benefits of using this system in terms of data, persistence of > identifiers and control over information sharing. What if the > registration number were transient [RFC6973, 7.1, RFC8280 6.2.10]? We > see the effort to reduce the risk of mis-attributions and intrusions > [RFC6973, 7.3], yes [draft-drip-arch-02, 4 and 5]. But the architecture > makes no mention of data minimization [RFC6973, 7.1, RFC8280 6.2.2, > 6.2.9] - and it could otherwise be seen as quite natural to have a > regulatory mandated minimum set of data provided, with options for > additional data provision should the user so prefer [RFC6973, 7.2]? > Maybe some cross-referencing to the [draft-drip-reqs-01 4] requirements > would facilitate understanding the motivation for the choices made. > > - How would such additional bits be included [RFC8280, 6.2.3]? asks the > Apprentice, but the Scholar is already off into their own rabbit hole. > > - One wonders, says the Scholar, in the end, if there are lessons to be > learned from the LPWAN or IPWAVE. And one wonders, if > [draft-drip-arch-02, 6] adds anything, really. The second paragraph of > [draft-drip-arch-02, 6] should surely be in [draft-drip-arch-02, 1] if > it were a high-level architectural point. I think I'd prefer such a change. > > - One wonders if it is the identifier message as such, or the method for > its provisioning [RFC8280, 6.2.1], which is the primary subject matter > of this architecture, the Apprentice chimes in. > > - One wonders, says the Scholar, what the specific connections are > between the requirements in the requirements document and the specific > proposed approaches in [draft-drip-arch-02, 3]. > > The two walk off into the field, ready to reflect on other drafts, > identifiers and checklists. > > End Scene I. > -- ----------------------------------------- Stuart W. Card, PhD, Principal Engineer AX Enterprize, LLC www.axenterprize.com 4947 Commercial Drive, Yorkville NY 13495
- [Tm-rid] Review of draft-drip-arch-02 w.r.t. RFC6… Amelia Andersdotter
- Re: [Tm-rid] Review of draft-drip-arch-02 w.r.t. … Carsten Bormann
- Re: [Tm-rid] Review of draft-drip-arch-02 w.r.t. … Alexandre Petrescu
- Re: [Tm-rid] Review of draft-drip-arch-02 w.r.t. … Robert Moskowitz
- Re: [Tm-rid] Review of draft-drip-arch-02 w.r.t. … Amelia Andersdotter
- Re: [Tm-rid] Review of draft-drip-arch-02 w.r.t. … Robert Moskowitz
- Re: [Tm-rid] Review of draft-drip-arch-02 w.r.t. … Alexandre Petrescu
- Re: [Tm-rid] Review of draft-drip-arch-02 w.r.t. … Robert Moskowitz
- Re: [Tm-rid] Review of draft-drip-arch-02 w.r.t. … Robert Moskowitz
- Re: [Tm-rid] Review of draft-drip-arch-02 w.r.t. … Alexandre Petrescu
- Re: [Tm-rid] Review of draft-drip-arch-02 w.r.t. … Robert Moskowitz
- Re: [Tm-rid] Review of draft-drip-arch-02 w.r.t. … Alexandre Petrescu
- Re: [Tm-rid] Review of draft-drip-arch-02 w.r.t. … Robert Moskowitz
- Re: [Tm-rid] Review of draft-drip-arch-02 w.r.t. … Stuart W. Card
- Re: [Tm-rid] Review of draft-drip-arch-02 w.r.t. … Alexandre Petrescu
- Re: [Tm-rid] Review of draft-drip-arch-02 w.r.t. … Robert Moskowitz
- Re: [Tm-rid] Review of draft-drip-arch-02 w.r.t. … Da Silva, Saulo
- Re: [Tm-rid] Review of draft-drip-arch-02 w.r.t. … Alexandre Petrescu
- Re: [Tm-rid] Review of draft-drip-arch-02 w.r.t. … Robert Moskowitz
- Re: [Tm-rid] Review of draft-drip-arch-02 w.r.t. … Robert Moskowitz
- [Drip] ADSB (was: Review of draft-drip-arch-02 w.… Stuart W. Card
- Re: [Drip] ADSB (was: Review of draft-drip-arch-0… shuaiizhao(Shuai Zhao)
- Re: [Drip] ADSB Robert Moskowitz
- Re: [Drip] ADSB(Internet mail) shuaiizhao(Shuai Zhao)
- Re: [Drip] ADSB(Internet mail) Robert Moskowitz
- Re: [Drip] ADSB(Internet mail) shuaiizhao(Shuai Zhao)
- Re: [Drip] ADSB(Internet mail) Robert Moskowitz
- Re: [Drip] ADSB(Internet mail) Jarvenpaa, Mika (Nokia - FI/Espoo)
- Re: [Drip] ADSB Alexandre Petrescu
- Re: [Drip] ADSB Alexandre Petrescu
- Re: [Drip] ADSB Stephan Wenger
- Re: [Drip] ADSB Stuart W. Card
- Re: [Drip] ADSB Alexandre Petrescu
- Re: [Drip] ADSB Robert Moskowitz
- Re: [Drip] ADSB Robert Moskowitz
- Re: [Drip] ADSB Stuart W. Card
- Re: [Drip] ADSB mohamed.boucadair
- Re: [Drip] ADSB Alexandre Petrescu
- Re: [Drip] ADSB Alexandre Petrescu
- Re: [Drip] ADSB Robert Moskowitz
- Re: [Drip] ADSB Robert Moskowitz
- Re: [Drip] ADSB Alexandre Petrescu
- Re: [Drip] ADSB Robert Moskowitz
- Re: [Drip] ADSB Alexandre Petrescu
- Re: [Drip] ADSB Card, Stu
- Re: [Drip] ADSB Card, Stu
- Re: [Drip] ADSB Robert Moskowitz
- Re: [Drip] ADSB Card, Stu
- Re: [Drip] ADSB Alexandre Petrescu
- Re: [Drip] ADSB Alexandre Petrescu
- Re: [Drip] ADSB Robert Moskowitz
- Re: [Drip] ADSB Robert Moskowitz
- Re: [Drip] ADSB Card, Stu
- [Drip] ASTM on UDP/IP - an (im)possibility Alexandre Petrescu
- Re: [Drip] ASTM on UDP/IP - an (im)possibility Robert Moskowitz
- Re: [Drip] ASTM on UDP/IP - an (im)possibility Card, Stu
- Re: [Drip] ADSB Alexandre Petrescu
- Re: [Drip] ADSB mohamed.boucadair
- Re: [Drip] ADSB Card, Stu
- Re: [Drip] ADSB Stephan Wenger
- Re: [Drip] ADSB Robert Moskowitz
- Re: [Drip] ADSB mohamed.boucadair
- Re: [Drip] [Tm-rid] Review of draft-drip-arch-02 … Stuart W. Card
- [Drip] Fwd: ADSB Alexandre PETRESCU
- Re: [Drip] Fwd: ADSB Alexandre PETRESCU
- Re: [Drip] Fwd: ADSB Robert Moskowitz
- Re: [Drip] Fwd: ADSB Eric Vyncke (evyncke)
- Re: [Drip] Fwd: ADSB Robert Moskowitz
- Re: [Drip] Fwd: ADSB Robert Moskowitz
- Re: [Drip] Fwd: ADSB Stu Card
- Re: [Drip] Fwd: ADSB Stu Card
- Re: [Drip] Fwd: ADSB Robert Moskowitz
- Re: [Drip] Fwd: ADSB Alexandre Petrescu
- Re: [Drip] ADSB Carsten Bormann
- Re: [Drip] ADSB Robert Moskowitz
- Re: [Drip] ADSB Eric Vyncke (evyncke)
- Re: [Drip] ADSB Alexandre Petrescu
- Re: [Drip] ADSB Alexandre Petrescu
- Re: [Drip] ADSB Stu Card
- Re: [Drip] ADSB Alexandre Petrescu
- Re: [Drip] ADSB Robert Moskowitz
- Re: [Drip] ADSB Stu Card
- Re: [Drip] ADSB Robert Moskowitz
- Re: [Drip] ADSB Alexandre Petrescu
- Re: [Drip] ADSB Robert Moskowitz
- Re: [Drip] ADSB Alexandre Petrescu
- Re: [Drip] ADSB Robert Moskowitz
- Re: [Drip] ADSB Alexandre Petrescu
- [Drip] how you can help (was: ADSB) Stu Card
- Re: [Drip] ADSB Robert Moskowitz
- Re: [Drip] how you can help (was: ADSB) Robert Moskowitz
- Re: [Drip] how you can help (was: ADSB) Alexandre Petrescu
- Re: [Drip] how you can help (was: ADSB) Robert Moskowitz
- Re: [Drip] how you can help (was: ADSB) Alexandre Petrescu
- Re: [Drip] how you can help (was: ADSB) Robert Moskowitz
- Re: [Drip] how you can help (was: ADSB) Stu Card
- Re: [Drip] how you can help (was: ADSB) Robert Moskowitz
- Re: [Drip] how you can help (was: ADSB) Robert Moskowitz
- Re: [Drip] ADSB Stephan Wenger
- Re: [Drip] ADSB - draft-moskowitz-drip-crowd-sour… Alexandre Petrescu
- Re: [Drip] ADSB - draft-moskowitz-drip-crowd-sour… Robert Moskowitz
- Re: [Drip] ADSB - draft-moskowitz-drip-crowd-sour… Stephan Wenger
- Re: [Drip] ADSB - draft-moskowitz-drip-crowd-sour… Robert Moskowitz
- Re: [Drip] ADSB - draft-moskowitz-drip-crowd-sour… Stephan Wenger
- Re: [Drip] ADSB - draft-moskowitz-drip-crowd-sour… Alexandre Petrescu
- Re: [Drip] ADSB - draft-moskowitz-drip-crowd-sour… Robert Moskowitz
- Re: [Drip] how you can help (was: ADSB) Alexandre Petrescu
- Re: [Drip] how you can help (was: ADSB) Stu Card
- Re: [Drip] how you can help (was: ADSB) Robert Moskowitz