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

Robert Moskowitz <rgm@labs.htt-consult.com> Mon, 12 June 2023 02:38 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 802CAC14CEFD for <tm-rid@ietfa.amsl.com>; Sun, 11 Jun 2023 19:38:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.897
X-Spam-Level:
X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 crWxRtM8RkcD for <tm-rid@ietfa.amsl.com>; Sun, 11 Jun 2023 19:38:36 -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 F38DEC14F747 for <tm-rid@ietf.org>; Sun, 11 Jun 2023 19:38:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id DFAC2626A1; Sun, 11 Jun 2023 22:38:11 -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 VrzrDcJaJN6J; Sun, 11 Jun 2023 22:38:01 -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 6C4546256E; Sun, 11 Jun 2023 22:37:59 -0400 (EDT)
Message-ID: <80751dc2-a409-df39-ca3b-61f49f85705e@labs.htt-consult.com>
Date: Sun, 11 Jun 2023 22:38:16 -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
To: Stu Card <stu.card@axenterprize.com>, "tm-rid@ietf.org" <tm-rid@ietf.org>
References: <207be6fa-4df0-c0c0-b67d-12d2f7a13220@labs.htt-consult.com> <a603c99d-f8cd-61e9-21af-9cd32fb7b322@labs.htt-consult.com> <MN2PR13MB4207D9E6690B9940A1FC6283F854A@MN2PR13MB4207.namprd13.prod.outlook.com>
From: Robert Moskowitz <rgm@labs.htt-consult.com>
In-Reply-To: <MN2PR13MB4207D9E6690B9940A1FC6283F854A@MN2PR13MB4207.namprd13.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tm-rid/YYy6hfSYSqHZax3PBIc2ZUDGLII>
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: Mon, 12 Jun 2023 02:38:40 -0000

Since I wrote this, Adam and I have talked about it.  He pointed out 
that the ANSI/CTA page in references points to the ICAO process to 
assign the codes.  So some clarity should be provided here.

CTA defined the encoding of MC.  ICAO assigns them.

Bob

On 6/11/23 20:50, Stu Card wrote:
> ANSI/CTA-2063-A specifies the serial number format.
>
> The manufacturer codes uses in that format are assigned by ICAO.
>
> -----Original Message-----
> From: Tm-rid <tm-rid-bounces@ietf.org> On Behalf Of Robert Moskowitz
> Sent: Tuesday, May 30, 2023 6:52 PM
> To: tm-rid@ietf.org
> Subject: Re: [Drip] Comments on draft-ietf-drip-registries-09
>
> 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
>
> --
> Tm-rid mailing list
> Tm-rid@ietf.org
> https://www.ietf.org/mailman/listinfo/tm-rid