[Drip] Re: I-D Action: draft-ietf-drip-registries-18.txt

Robert Moskowitz <rgm@labs.htt-consult.com> Wed, 02 October 2024 12:35 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 32B67C16941B for <tm-rid@ietfa.amsl.com>; Wed, 2 Oct 2024 05:35:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable 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 1pMEI1yf3Zbr for <tm-rid@ietfa.amsl.com>; Wed, 2 Oct 2024 05:35:39 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C247DC14F6BF for <tm-rid@ietf.org>; Wed, 2 Oct 2024 05:35:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id BCFB362984; Wed, 2 Oct 2024 08:34:46 -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 Y2vyXbRdp2Dq; Wed, 2 Oct 2024 08:34:34 -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 76004627B0; Wed, 2 Oct 2024 08:34:34 -0400 (EDT)
Content-Type: multipart/alternative; boundary="------------TNJQxjzKd3riFXtkfVzeZyXu"
Message-ID: <37a7a14e-a8cb-4ece-83c4-2ebfa056addb@labs.htt-consult.com>
Date: Wed, 02 Oct 2024 08:35:23 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Maarten Wullink <maarten.wullink=40sidn.nl@dmarc.ietf.org>, "tm-rid@ietf.org" <tm-rid@ietf.org>
References: <BAC3AD50-A86B-452B-AD63-69898256BCBC@sidn.nl>
Content-Language: en-US
From: Robert Moskowitz <rgm@labs.htt-consult.com>
In-Reply-To: <BAC3AD50-A86B-452B-AD63-69898256BCBC@sidn.nl>
Message-ID-Hash: S7RFDGFGULJSBYGDB65GJUGPYDEDRTT5
X-Message-ID-Hash: S7RFDGFGULJSBYGDB65GJUGPYDEDRTT5
X-MailFrom: rgm@labs.htt-consult.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Drip] Re: I-D Action: draft-ietf-drip-registries-18.txt
List-Id: Drone Remote Identification Protocol <tm-rid.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tm-rid/2L4iqiwFlylELEd_1wMMwV1UYiU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tm-rid>
List-Help: <mailto:tm-rid-request@ietf.org?subject=help>
List-Owner: <mailto:tm-rid-owner@ietf.org>
List-Post: <mailto:tm-rid@ietf.org>
List-Subscribe: <mailto:tm-rid-join@ietf.org>
List-Unsubscribe: <mailto:tm-rid-leave@ietf.org>


On 10/2/24 03:56, Maarten Wullink wrote:
> Hi,
>
> i like this work, some questions and comments:
>
> - rfc9374 describes 2 different methods for putting DETs in the DNS, fqdn and reverse ipv6 lookup, why was the latter chosen?
> https://www.rfc-editor.org/rfc/rfc9374.html#name-drip-entity-tags-dets-in-dn

Reverse was a given.  The fqdn was perhaps speculative at that time.  We 
have, for now, dropped the fqdn approach, and I don't think we will 
revisit it.  It was my thoughts, and I have come around to the reverse 
approach.

> - The special 2001:30::/28 prefix for DETS is assigned to the IAB and this zone contains the NS records that point to  the RAA the has the authority for a part of the zone?
> who is going to be responsible for running and management of the apex zone?

Everyone involved would like this to be ICAO.  But that gets wrapped up 
in ICAO policies that will take a process, driven by at least 
half-a-dozen member countries to get proper attention.  Sigh.  So until 
then, IANA has agreed to handle this.  We have had a number of meetings 
with them and will be formalizing the methodology on how they will be 
able to vet a valid CAA request for allocation.

> - If i understand it correctly, some information is also encoded into the identifier using the ORCHID scheme?
> Would it not be cleaner to have to information available as a Resource Record instead of encoded in the identifier? If the encoded information can never be changed in the identifier name but the RR value can be modified if required.

The information is needed in the DET for how rfc9575 works and other 
uses of DETs being developed.  We bandied about also having this 
information separately in the RR, but in the end decided to not expand 
on the RR content size.  The info MUST be in the DET.

> - The allocation of a RAA is going to be the responsibility of IANA, and there is a link to a mapping csv file which is on Github, what if the file is no longer available on GH some time after the document is completed? and also why are nations assigned only 4 RAAs? sounds very limited.
> https://www.ietf.org/archive/id/draft-ietf-drip-registries-18.html#name-drip-raa-allocations

TBD in a separate document.

> - The use of the registrant-registrar-registry (RRR) model is interesting, what i’m missing is some text about the economics supporting all of this (fees), what would be the incentive for registrars to offer a service such as this?  i’m a total n00b when it comes to drones, but is there currently a fee drone owner must be to register a drone and this will be the same when use RRR model?

In the US, Canada, and EU U-Space (and probably others, Japan and Israel 
are even stricter) a person gets their Drone operator license (FAA part 
107) and as such is registered to the FAA.

They then register their drone (s) to their CAA and are issued a CAAid 
for them.

They then SHOULD select a USS as their operational contact. Recreational 
operators that only fly in designated recreational areas do not have to 
do this.  Rural operators is a tossup of processes by CAA.

The Operator, using their USS credentials (could be a DET), then 
register their UA, typically getting a USS assigned ID (In DRIP this 
could be a permanent DET).

Then for EACH operation (that is flight/mission) the Operator gets a 
Session ID (UUID with some USS, DETs for us here).

Then fly!


> - Appendix A1, the example contains a “TBD"
> https://www.ietf.org/archive/id/draft-ietf-drip-registries-18.html#hhit-wire-cddl

Adam will need to answer this.

> - The document mentions EPP for provisioning of DETs, i just want to let you know that we are working on forming a new working group “RESTful Provisioning Protocol” as an alternative for EPP. You might want to consider this also and maybe also drop by at the BoF we are organizing next month in Dublin.
>
> https://mailarchive.ietf.org/arch/browse/rpp/
> https://github.com/SIDN/ietf-wg-rpp-charter/blob/main/rpp-charter.md

I will only be at Dublin noon Monday until evening Wednesday.  I hope to 
be able to attend.  Others may attend remotely.

> Cheers,
> Maarten

Thank you for your review.


-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:rgm@labs.htt-consult.com

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit