Re: [Drip] Comments on draft-ietf-drip-registries-09

Robert Moskowitz <rgm@labs.htt-consult.com> Tue, 30 May 2023 23:36 UTC

Return-Path: <rgm@labs.htt-consult.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 6CF80C14CEFF for <tm-rid@ietfa.amsl.com>; Tue, 30 May 2023 16:36:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5w784ZLQtIu7 for <tm-rid@ietfa.amsl.com>; Tue, 30 May 2023 16:36:39 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 F0FA9C14CE36 for <tm-rid@ietf.org>; Tue, 30 May 2023 16:36:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id CB4E662434 for <tm-rid@ietf.org>; Tue, 30 May 2023 19:36:15 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5UJWqXF6Mlbr for <tm-rid@ietf.org>; Tue, 30 May 2023 19:36:08 -0400 (EDT)
Received: from [192.168.160.29] (unknown [192.168.160.29]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 611D760944 for <tm-rid@ietf.org>; Tue, 30 May 2023 19:36:06 -0400 (EDT)
Message-ID: <a603c99d-f8cd-61e9-21af-9cd32fb7b322@labs.htt-consult.com>
Date: Tue, 30 May 2023 18:51:50 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0
Content-Language: en-US
From: Robert Moskowitz <rgm@labs.htt-consult.com>
To: "tm-rid@ietf.org" <tm-rid@ietf.org>
References: <207be6fa-4df0-c0c0-b67d-12d2f7a13220@labs.htt-consult.com>
In-Reply-To: <207be6fa-4df0-c0c0-b67d-12d2f7a13220@labs.htt-consult.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tm-rid/YzlYLx99H1JT33muZ_xBZr4m2SE>
Subject: Re: [Drip] Comments on draft-ietf-drip-registries-09
X-BeenThere: tm-rid@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 30 May 2023 23:36:43 -0000

DIME Roles

In first para, perhaps needs to mention that vetting is not assured?  
Perhaps:

and delivers, to successful registrations,

Apex

We should not be using "HHIT" in this document.  All references are to 
the specific HHIT of DETs.  So pretty much global replace of HHIT with DET.

"assigned by IANA from the non-routable special IPv6 address space for 
ORCHIDs"

"non-routable" is NOT a term used in

https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

And rfc 4193 says:

"These addresses are not expected to be routable on the global Internet."

Given some side discussions occurring, please drop "non-routable". It 
does not add anything.  Perhaps reference above IANA url as in 9374.

Although ICAO is defined in 9153, it might be worthwhile to expand it 
here the first usage.

and "as the Apex"

(denoted by a 14-bit field (16,384 RAAs) of an DET).

nested parans not good style.  perhaps:

(denoted by a 14-bit field, i.e. 16,384 RAAs, of an DET).

All RAA's have two reserved HDA values. 0 (0x0000) for itself in its 
role as an RAA and 1 (0x0001) if it wishes to offer HDA services.

In drip-dki, I am seeing this all come under HDA=0.  I do not see the 
need of a separation.  It works well, I think, for a number of reasons 
for the Issuing function of the RAA to run out of HDA=0.

For the Note, please note that drip-dki is proposing 4 RAAs per ISO 3611 
entity.  Or at least they are available to those entities.

I think that experience may find that a CAA may block groups of HDAs to 
provide things like regional services.  I think that this would be a 
better way, but we will need experience.

"Manufacturer's that hold an ICAO Manufacturer Code used in"

Well, actually, these are ANSI/CTA codes:

https://shop.cta.tech/products/small-unmanned-aerial-systems-serial-numbers

Do we have two organizations issuing these numbers and maybe not 
coordinating?

https://www.icao.int/publications/DOC8643/Pages/Manufacturers-Codes.aspx

Oy vey.

But anyway, we probably need to say these are CTA codes issued by whomever.

In fact your reference CTA2063A is to the CTA page, not ICAO page.

So don't call them "ICAO Manufacturer Code".

section heading of Hierarchial HIT Domain Authority (HDA) does not get 
changed to DET Domain Authority.  :)

We goofed, perhaps, in 9374 with this one in trying to make everything 
DET but not.  So I think this is the only place that HHIT appears.  
Where we define HDA and then leave it as HDA without using Hierarchial 
HIT.  Grumble.


These are the RAA values of 2 (0x0002) up to 96 (0x0060). This allows a 
single HDA for each Manufacturer Code.

I would rather this be 4096 - 4191.  I prefer that the first range of 
RAAs be for CAAs as specified in drip-dki.  It works "better" for people 
and software that see DETs in the field.  IMO.

Also I am thinking that RAA 0 - 3 is for the Apex.  If the Apex DOES end 
up being ICAO, then for example RAA=1 is UN agencies other than ICAO 
(e.g. UNESCO, UN Peace Keepers?,,,).

Obviously we need discussion to come up with what to do, and I am 
concerned we will be working in a vacumn with appropriate echo effects.

An HDA may be an USS, ISP, or any third party that takes on the business 
to register the actual UAS entities that need DETs.

It is more than UAS.  It is various SDSPs (as in 
draft-moskowitz-drip-crowd-sourced-rid) and infrastructure (as in 
draft-moskowitz-drip-efficient-a2g-comm).  So wording here needs to 
reflect this larger usage of DETs.

thus

business to register the actual entities that need DETs.

And add infrastructure equip and SDSPs to your example list.

And MAAs have codes assigned by ANSI/CTA as mentioned above, not ICAO.  
Or maybe yes.  We do need to get this right.

Oh, and do MAAs come out of the 96 RAAs above or have their own range?  
Please clarify.

Session ID Authority (SIDA)

If I understand this section aright, it steps into the do-do of, in the 
US, of the FAA tracking such linkage.  I don't know how we want to 
handle this...

I might assume these HDAs are within the CAA's RAA?  Say so.


On receiver devices a DET can be translated to a more human readable 
form such as:

Note that drip-dki makes it "easy" for translation of RAA to 3166 char...

Sec 5 onward for later.....

Bob