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

[Amelia Andersdotter <[e-mail]>]

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.