Re: [Drip] [Tm-rid] Review of draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and other

["Stuart W. Card" <[e-mail]>]

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