IETF Logo Mail Archive

Re: [Drip] DRIP UAS RID

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 14 August 2020 03:26 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 CC5793A0C7E for <tm-rid@ietfa.amsl.com>; Thu, 13 Aug 2020 20:26:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8Gkji-qkXaa for <tm-rid@ietfa.amsl.com>; Thu, 13 Aug 2020 20:26:14 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F67C3A0C7B for <tm-rid@ietf.org>; Thu, 13 Aug 2020 20:26:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 68D88389B1; Thu, 13 Aug 2020 23:05:24 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rwT5Y9tRz8vg; Thu, 13 Aug 2020 23:05:23 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 9B0AA389B0; Thu, 13 Aug 2020 23:05:22 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 604712B3; Thu, 13 Aug 2020 23:26:09 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Robert Moskowitz <rgm@labs.htt-consult.com>, "tm-rid@ietf.org" <tm-rid@ietf.org>
In-Reply-To: <21b0bbc3-6582-45a5-f13f-1f1fb06885b4@labs.htt-consult.com>
References: <21b0bbc3-6582-45a5-f13f-1f1fb06885b4@labs.htt-consult.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Thu, 13 Aug 2020 23:26:09 -0400
Message-ID: <6416.1597375569@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tm-rid/6QOqdAWJf8vRVEs8hW4In2GFwLI>
Subject: Re: [Drip] DRIP UAS RID
X-BeenThere: tm-rid@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 14 Aug 2020 03:26:16 -0000

Robert Moskowitz <rgm@labs.htt-consult.com> wrote:
    > Please review and comment on:

    >     draft-moskowitz-drip-uas-rid-03

I found section 5 to be too nebulous.
I guess this is discussion about possibilities... but which one do your
favour?  I found the DNSSEC comment odd. yes, 63M is a bit zone.
But, .com has 359M names, and it seems like the pieces under hhit.arpa could
be sharded quite easily.

    > This draft references:
    > The actual format of HHIT in:

    >     draft-moskowitz-hip-hierarchical-hit-05

    > Please comment on the division of the 96 bits allocation and 2 levels of
    > hierarchy.

okay.

I had to read through things a bit, including into RFC6890 to understand the
allocation rules for 2001::/23.  I was thinking, if there are 182 authorities
(if I heard that right, i.e. less than 2^8) in the world, maybe they could
all just ask IANA directly, leaving us with 16 more bits for the hash.   But
our process won't allow that.
I'm also a bit unclear about how much space they actually have here, since
ORCHID got a /28 here under 2001:00_00::/23, while 2001:db8::/32 is not
actually inside 2001:00_00::/23, if I'm doing my math right :-)

If you want more bits for the hash, then I would go for:
   *  28 bit IANA prefix
   *  12 bit Registered Assigning Authority (RAA)
   *  16 bit Hierarchical HIT Domain Authority (HDA)
   *  4 bit HIT Suite ID
   *  68 bit ORCHID hash

>   Suite ID can be used for HHITs, provided that the prefix for HHITs is
>   different from flat space HITs.  Without a unique prefix,
>   Section 4.1, additional HIT Suite IDs would be needed for HHITs.
>   This would risk exhausting the limited Suite ID space of only 15 IDs.

Either I don't understand, or this text is confusing.
I think the point is that if we don't have SuiteID, as we didn't for ORCHIDv1 (?)
then we'd have to go back to IANA for a new prefix every time we wanted a new
set of algorihms.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email