Subject: [Drip] draft-ietf-drip-arch-13

From: Daniel Migault <[email-masked]>
Date: Mon, 7 Jun 2021 11:10:58 -0400

Hi,

I have reviewed the arch-13 document - at least the first 5 sections - and
opened some issues [1].

Yours,
Daniel

[1] https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues

-- 
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Mon, 14 Jun 2021 11:18:03 -0400

Hi,

I am wondering if we could plan to have these issues resolved and a new
version published for the next IETF meeting. Remaining issues may also be
discussed during the meeting itself, but we need to make sure most of them
have been cleaned out. Stu made also some comments that we need to keep
track with and address.

Yours,
Daniel

-- 
Daniel Migault
Ericsson

---

From: "Card, Stu" <[email-masked]>
Date: Mon, 14 Jun 2021 13:42:09 -0400

Yes, please, I invite list discussion ASAP, as some of my comments were on
what I consider major issues.

I feel we have gutted our Architecture document so that it does not
actually describe an architecture.

Fixing that is fundamental, not a nit.

On Mon, Jun 14, 2021 at 11:18 AM Daniel Migault <[email-masked]> wrote:

>> I have reviewed the arch-13 document - at least the first 5 sections -
>> and opened some issues [1].
>>
>> Yours,
>> Daniel
>>
> Tm-rid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tm-rid
>

---

From: <[email-masked]>
Date: Tue, 15 Jun 2021 07:26:47 +0000

Hi Stu,

Can you please share the major issues you were referring to? Thank you.

Cheers,
Med

De : Tm-rid [mailto:[email-masked]] De la part de Card, Stu
Envoyé : lundi 14 juin 2021 19:42
À : Daniel Migault <[email-masked]>
Cc : [email-masked]
Objet : Re: [Drip] draft-ietf-drip-arch-13

Yes, please, I invite list discussion ASAP, as some of my comments were on what I consider major issues.

I feel we have gutted our Architecture document so that it does not actually describe an architecture.

On Mon, Jun 14, 2021 at 11:18 AM Daniel Migault <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

I am wondering if we could plan to have these issues resolved and a new version published for the next IETF meeting. Remaining issues may also be discussed during the meeting itself, but we need to make sure most of them have been cleaned out. Stu made also some comments that we need to keep track with and address.

Yours,
Daniel

On Mon, Jun 7, 2021 at 11:10 AM Daniel Migault <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

I have reviewed the arch-13 document - at least the first 5 sections - and opened some issues [1].

Yours,
Daniel

--
Daniel Migault
Ericsson

--
Daniel Migault
Ericsson
--
Tm-rid mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tm-rid

_________________________________________________________________________________________________________________________

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: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Tue, 15 Jun 2021 16:13:42 +0000

Hi,

I am still on PTO. Will be back in a few days. Hopefully, we all find the time for the next revision. 😊

Best,
Shuai

From: Tm-rid <[email-masked]> on behalf of "Card, Stu" <[email-masked]>
Date: Monday, June 14, 2021 at 10:42 AM
To: Daniel Migault <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [Internet]Re: [Drip] draft-ietf-drip-arch-13

Yours,
Daniel

Yours,
Daniel

--
Daniel Migault
Ericsson

---

From: "Card, Stu" <[email-masked]>
Date: Sun, 20 Jun 2021 23:35:52 -0400

previously sent to a smaller distribution, mostly co-authors --

Sorry this thorough review is so late!
I've been more focused on the ASTM F3411 update for the past few months.
Fortunately, that is now mostly "in the bag",
including all we need for DRIP to be a recognized set of extensions.
:-)

In the course of reviewing -arch, I had to reference -reqs,
where I discovered a couple of issues, which I list first below.

The vast majority of my comments are editorial.

*** My only major objection, and it is a big fundamental one, is
to the gutting of all actual architectural specifications, especially
registries in Section 5. ***

You may recall my saying in WG presentations that the high level UAS RID
architecture is already defined external to IETF, so we need to document
a specific DRIP solution architecture, how it fits into the pre-existing
high level architecture, and how it provides benefits otherwise lacking.

As yet, we here have only promised such benefits, not actually defined
an architecture.

I do _not_ blame editor Shuai: he only did as he understood direction
based on others' comments.

If you do not have time for this whole review, please just consider my
comments on Sections 4 & 5.

<-- snip: minor editorial comments not requiring attention from WG just
authors & editor -->

-arch Section 4

"HHIT for DRIP Entity Identifier
This section describes the basic requirements of a DRIP entity
identifier per regulation constrains from ASTM [F3411-19] and
explains the use of Hierarchical Host Identity Tags (HHITs) as self-
asserting IPv6 addresses and thereby a trustable DRIP identifier for
use as the UAS Remote ID.  HHITs self-attest to the included explicit
hierarchy that provides Registrar discovery for 3rd-party ID
attestation."
->
"HHIT as the Primary DRIP Entity Identifier
This section describes the DRIP architectural approach to meeting
the basic requirements of a DRIP entity identifier within external
technical standard ASTM [F3411-19] and regulatory constraints. It
justifies and explains the use of Hierarchical Host Identity Tags
(HHITs) as self-asserting IPv6 addresses suitable as a UAS ID type
and more generally as trustworthy multipurpose remote identifiers.
A HHIT, together with the Host Identity (HI) from which it is partly
derived, self-attests to its included explicit registration hierarchy,
providing Registrar discovery for 3rd-party attestation of identity
and lookup of related information."

==

-arch Section 4.1

This section does 2 things: recapitulate some of what is in -reqs;
and begin to introduce/justify HHITs. I would be much happier if it
cited -reqs generally for the motivation, then one by one went through
its specific numbered requirements and showed how HHITs, together with
private and public registries (inc. DNS) satisfy them.

==

-arch Section 4.2

good, but should be merged with Section 4.4

==

-arch Section 4.3

This is the closest we come, in this nominally Architecture document,
to actually specifying an architecture, so to that extent it is good.
However, even here, the focus is entirely on the HHIT (none of the
other entities or their interfaces), and the language is always "can"
rather than "must", "should", "may", "shall", "will", "does" or "is".

==

-arch Section 4.4

should be merged wih Section 4.2

"HHIT for DRIP Identifier Cryptographic
The only (known to the authors of this document at the time of its
writing) extant fixed-length ID cryptographically derived from a
public key are the Host Identity Tag [RFC7401], HITs, and
Cryptographically Generated Addresses [RFC3972], CGAs.  However, both
HITs and CGAs lack registration/retrieval capability.  HHIT, on the
other hand, is capable of providing a cryptographic hashing function,
along with a registration process to mitigate the probability of a
hash collision (first registered, first allowed)."
->
"HHIT as a Cryptographic Identifier
The only (known to the authors at the time of this writing) extant
types of IP address compatible identifiers cryptographically derived
from the public keys of the identified entities are Cryptographically
Generated Addresses (CGAs) [RFC3972] and Host Identity Tags (HITs)
[RFC7401].  CGAs and HITs lack registration/retrieval capability.
To provide this, each HHIT embeds plaintext information designating
the hierarchy within which it is registered and a cryptographic hash
of that information concatenated with the entity's public key, etc.
Although hash collisions may occur, the registrar can detect them
and reject registration requests rather than issue credentials, e.g.,
by enforcing a first-claimed, first-attested policy."

==

-arch Section 5

I disagree strongly with removal of definitive specifications here.

It is not just that "UAS registries can hold both public and private UAS
information resulting from the DRIP identifier registration process";
they MUST hold such information, or they aren't registries at all, and
don't satisfy regulator or F3411 UAS RID, much less DRIP, requirements!

It is not just that "A DRIP identifier is amenable to handling as an
Internet domain name..." and "can be registered in at least a
pseudo-domain"; it MUST be so registered, or we miss the entire point
of DRIP as stated in the charter "The working group will primarily
leverage Internet standards (including HIP, EPP, RDAP, and DNS) and
infrastructure as well as domain name registration business models" and
restated in -arch Section 1.4 "DRIP is meant to leverage existing
Internet resources (standard protocols, services, infrastructures, and
business models) to meet UAS RID and closely related needs. DRIP will
specify how to apply IETF standards, complementing [F3411-19] and other
external standards, to satisfy UAS RID requirements. This document
outlines the UAS RID architecture into which DRIP must fit and the
architecture for DRIP itself." We don't actually do that here: the
entities and interfaces already present in the UAS RID architecture
into which DRIP must fit are not even listed; of those introduced by
DRIP, the identifier is justified, but nothing is actually specified,
much less positioned in an architecture. To see what I mean, just search
the text for architectural keywords, such as "interface".

I will not comment specifically on the details of the text in Section 5,
as I fundamentally disagree with not actually specifying an architecture
in the DRIP Architecture document. I am happy to support alternatives
to DNS, EPP, RDAP, etc. _in addition_ to those protocols (indeed, I am
fond of blockchain based approaches), but leveraging proven Internet
domain name registration and lookup processes is fundamental to DRIP.

On Tue, Jun 15, 2021 at 3:26 AM <[email-masked]> wrote:

> *De :* Tm-rid [mailto:[email-masked]] *De la part de* Card, Stu
> *Envoyé :* lundi 14 juin 2021 19:42
> *À :* Daniel Migault <[email-masked]>
> *Cc :* [email-masked]
> *Objet :* Re: [Drip] draft-ietf-drip-arch-13
>
>
>

---

From: <[email-masked]>
Date: Fri, 25 Jun 2021 07:19:41 +0000

Hi Stu, all,

Thank you for sharing these comments. I will focus on the key one below:

==

·         We discussed this in the past and the agreement is to describe all the components that we are grafting + their corresponding interfaces for DRIP to meet its promises. So, this will cover the registry part, authentication, etc. Of course, the scope will the one of the DRIP WG.

·         In the meantime, we agreed to avoid diving into low-level details (e.g., specify what is an HHIT and how it works). Moreover, the architecture should not depend on HHIT. If we can insist on the external behavior, rather than assuming/mandating HHIT, this will allow to architecture to survive even if another ID scheme is proposed in the future.

·         The normative language can be used even in an Informational Track document. We can decide such use in the arch I-D if we think this is better for clarity or to insist on key components/behaviors so that the DRIP architecture can be effective. I have seen some comments saying that the normative language is only reserved for “Standards Track” document, but I disagree with those comments. So, this is a decision we can make together with the WG.

Cheers,
Med

De : Tm-rid [mailto:[email-masked]] De la part de Card, Stu
Envoyé : lundi 21 juin 2021 05:36
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
Cc : [email-masked]
Objet : Re: [Drip] draft-ietf-drip-arch-13

<-- snip: minor editorial comments not requiring attention from WG just authors & editor -->

-arch Section 4

==

-arch Section 4.1

==

-arch Section 4.2

==

-arch Section 4.3

==

-arch Section 4.4

==

-arch Section 5

On Tue, Jun 15, 2021 at 3:26 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Stu,

Cheers,
Med

De : Tm-rid [mailto:[email-masked]<mailto:[email-masked]>] De la part de Card, Stu
Envoyé : lundi 14 juin 2021 19:42
À : Daniel Migault <[email-masked]<mailto:[email-masked]>>
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [Drip] draft-ietf-drip-arch-13

Yours,
Daniel

Yours,
Daniel

--
Daniel Migault
Ericsson

Thank you.