Subject: Re: [Drip] WGLC of draft-ietf-drip-rid-13 (Ends 29/11/2021) ( was IETF 112 drip-rid presentation comment)

From: <[email-masked]>
Date: Mon, 29 Nov 2021 14:54:10 +0000

Hi Stu, all,

(as individual; changing the subject so that this comment is tagged for the ongoing WGLC)

I guess you meant 16 bits (not 8 bits) for the RAA and 16 bits (not 8 bits) for the HDA.

With the current structure, an RAA can be easily identified. Isn’t that a feature?

I’m not sure to understand the flexibility argument given that an organization (e.g., FAA) can get one or bocks of RAAs (represented as /16 if you will).

BTW, I wonder whether the document should discuss prevention means so that the space is not abused/exhausted by a same organization. Also, shouldn’t the document ask IANA to maintain RAA assignment registry? The current wording is weak: “perhaps ICANN's IANA service”

Cheers,
Med

De : Card, Stu <[email-masked]>
Envoyé : dimanche 21 novembre 2021 00:16
À : Robert Moskowitz <[email-masked]>
Cc : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; Jaime Jiménez <[email-masked]>; [email-masked]; Jeff Ahrenholz <[email-masked]>
Objet : Re: [Drip] IETF 112 drip-rid presentation comment

I have a comment on the substance, not the presentation.

Adam & I would really like to see a CIDR-like structure here rather than a strict 8 bit RAA + 8 bit HDA.
That would support flexible efficient allocation of the space, as IANA and the regional routing registries do with IP addresses.

We also would like to move away from the severely limiting 4.5 bit HIT Suite ID.
The compromise of 20 years ago does _not_ provide an optional 8 bit range as might appear.
It provides 4 bits, of which 1 value means look at the other 4 bits, so only 31 values total, not 256.
Trying to maintain backwards compatibility with an essentially non-existent installed base is not worth limiting us going forward.
Tempered Networks are the primary actual users. Their systems are in walled gardens, so can migrate on their own schedule. Jeff?

On Fri, Nov 19, 2021 at 10:35 AM Robert Moskowitz <[email-masked]<mailto:[email-masked]>> wrote:
This ended up in junk as well.  :(

Med,

this looks good.  I will see how I can incorporate it in ver -14

Bob
On 11/12/21 02:02, [email-masked]<mailto:[email-masked]> wrote:
Hi Bob, all,

Adding Jaime as I’m not sure he is on the list.

FWIW, here is another proposal that includes also RAA and HDA parts:

               16 bits| 16 bits           4 or 8 bits

              +-------+-------+         +--------------+

              |  RAA  | HDA   |         | HIT Suite ID |

              +-------+-------+         +--------------+

               \              /    ____/   ___________/

                \             \  _/  _____/

                  \            \/   /
   |    p bits    |  32 bits   |s  |   o=96-p-s bits        |
   +--------------+------------+---+------------------------+
   | IANA Prefix |    HID     |HSI|      ORCHID hash      |
   +--------------+------------+---+------------------------+

Cheers,
Med

De : Tm-rid <[email-masked]><mailto:[email-masked]> De la part de Robert Moskowitz
Envoyé : jeudi 11 novembre 2021 22:13
À : [email-masked]<mailto:[email-masked]>
Objet : [Drip] IETF 112 drip-rid presentation comment

<Jaime Jimenez_web_478> asked:

@Bob I had a look at draft-ietf-drip-rid-13. As a complete outsider it would help to see some table for section 3 with the fields involved (if possible).

Does this help?

   +=============+=========+===============+==========================+
   | IANA Prefix | HID     | HIT Suite ID  | ORCHID hash              |
   +=============+=========+===============+==========================+
   | max 28 bits | 32 bits | 4 (or 8) bits | 96 - L(prefix) - L(Suite |
   |             |         |               | ID), e.g. 64 bits        |
   +-------------+---------+---------------+--------------------------+

                           Table 1: HHIT Format

rather than:

   *  IANA prefix (max 28 bit)

   *  32 bit Hierarchy ID (HID)

   *  4 (or 8) bit HIT Suite ID

   *  ORCHID hash (96 - prefix length - Suite ID length bits, e.g. 64)
      See Section 3.5

Then I would have to work out what to do with HID...

There is nothing to "lift" from 7401 or 7343.

Bob

_________________________________________________________________________________________________________________________

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.

--
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: "Stuart W. Card" <[email-masked]>
Date: Mon, 29 Nov 2021 12:48:23 -0500

First, yes, I must have been emailing late at night or something, indeed 
it is currently 16+16 (not 8+8), thanks for catching that. :-/

I worry any time anyone says anything like "640 kB will always be more 
than enough RAM address space". Maybe 64k RAAs, and 64k HDAs per RAA, is 
flexible enough, _for UAS RID alone_, especially if a single RAA can get 
more than one hi-16.

I am really more interested in the possibility of a multi-layer 
hierarchy. E.g., an 11 bit RAA identifier, an 11 bit HDA identifier, and 
a third 10 bit identifier for an as yet unnamed thing between the RAA 
and the HDA. If you consider just aviation, maybe this is not needed; 
but we need a prefix from IANA for this to work. If that prefix is for 
_all_ HHITs, we have a problem: a 2 layer hierarchy won't support 
numerous industries cutting across numerous jurisdictions, with multiple 
registries in many industry * jurisdiction cross-product intersections.

If we intend to ask IANA for a prefix _dedicated to UAS RID_, I will 
shut up about this. If we intend to ask IANA for a prefix for _HHITs_ in 
general, my point needs to be addressed in vigorous WG debate.

I believe the total registration hierarchy will be something like this, 
in the case of UAS RID --

IANA : ICAO : RAA = CAA (e.g. FAA) : HDA = USS (e.g. ANRA, OneSky)

How do we generalize that for not just UAS RID but all aviation related 
use of HHITs, as in the ICAO Aviation Trust Framework (IATF) Global 
Resilient Aviation Interoperable Network (GRAIN)?

How do we further generalize that for sectors other than aviation?

IANA needs to be the root, and needs some flexibility to enable them to 
work. That's why I think the HHIT format needs to be generalized to 
allow for an arbitrary prefix length and a multi-layer RAA/HDA/etc. 
structure. CIDR provides a working example.

I grant your point that this would make it less trivial to identify an 
RAA from the HHIT alone, but I am not sure that is necessary: global IP 
routing works despite the inability from a CIDR IP address alone (w/o 
lookup) to identify the RIR (just beneath IANA) responsible for it.

There are likely some other RID draft issues that we should discuss, but 
I must deal with the RFC Editor AUTH48 on DRIP Requirements and my 
post-IETF112 action items on DRIP Architecture first (as well as some 
other critical deadlines in the coming week).

On 11/29/2021 9:54 AM, [email-masked] wrote:
> I’m not sure to understand the flexibility argument given that an 
> organization (e.g., FAA) can get one or bocks of RAAs (represented as 
> /16 if you will).
> 
> BTW, I wonder whether the document should discuss prevention means so 
> that the space is not abused/exhausted by a same organization. Also, 
> shouldn’t the document ask IANA to maintain RAA assignment registry? The 
> current wording is weak: “perhaps ICANN's IANA service”
> 
> Cheers,
> 
> Med
> 
> *De :* Card, Stu <[email-masked]>
> *Envoyé :* dimanche 21 novembre 2021 00:16
> *À :* Robert Moskowitz <[email-masked]>
> *Cc :* BOUCADAIR Mohamed INNOV/NET <[email-masked]>; Jaime 
> Jiménez <[email-masked]>; [email-masked]; Jeff Ahrenholz 
> <[email-masked]>
> *Objet :* Re: [Drip] IETF 112 drip-rid presentation comment
> 
> That would support flexible efficient allocation of the space, as IANA 
> and the regional routing registries do with IP addresses.
> 
> Trying to maintain backwards compatibility with an essentially 
> non-existent installed base is not worth limiting us going forward.
> 
> Tempered Networks are the primary actual users. Their systems are in 
> walled gardens, so can migrate on their own schedule. Jeff?
> 
> On Fri, Nov 19, 2021 at 10:35 AM Robert Moskowitz 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     On 11/12/21 02:02, [email-masked]
>     <mailto:[email-masked]>wrote:
> 
>         Hi Bob, all,
> 
>         *De :* Tm-rid <[email-masked]>
>         <mailto:[email-masked]> *De la part de* Robert Moskowitz
>         *Envoyé :* jeudi 11 novembre 2021 22:13
>         *À :* [email-masked] <mailto:[email-masked]>
>         *Objet :* [Drip] IETF 112 drip-rid presentation comment
> 
>         @Bob I had a look at draft-ietf-drip-rid-13. As a complete
>         outsider it would help to see some table for section 3 with the
>         fields involved (if possible).
> 
>         Does this help?
> 
>            
-- 
-----------------------------------------
Stuart W. Card, PhD, Principal Engineer
AX Enterprize, LLC  www.axenterprize.com
4947 Commercial Drive, Yorkville NY 13495

---

From: "Stuart W. Card" <[email-masked]>
Date: Mon, 29 Nov 2021 12:59:49 -0500

Reminder: I raised another issue in the email to which Med was 
responding, not just a CIDR structure for prefix/RAA/HDA...

The horrible HIT Suite ID hack of 20 years ago!

That _may_ have been appropriate for an _experimental_ protocol.

It _may_ have been appropriate for HITs rather than HHITs.

With the registration of HHITs, hash collisions can be detected, so 
while it not desirable to shrink the ORCHID hash, we could if we needed 
the space.

So the HIT Suite ID should be 8 bits, not this {4|8} bit kludge that 
yields just under 5 bits worth of unique choices, several of which are 
already consumed.

These 2 suggestions (CIDR structure & 8 bit HHIT Suite ID) are separate 
but related: if the prefix/RAA/HDA structure is CIDR-like, there is 
flexibility to juggle field lengths as part of the allocation/assignment 
process, avoiding the need to shrink the ORCHID hash as long as possible 
(possibly avoiding it entirely).

I'd just like to see some discussion on these 2 points by folks beyond 
Bob, Adam, me and now Med. Thanks!

On 11/29/2021 12:48 PM, Stuart W. Card wrote:
>> shouldn’t the document ask IANA to maintain RAA assignment registry? 
>> The current wording is weak: “perhaps ICANN's IANA service”
>>
>> Cheers,
>>
>> Med
>>
>> *Cc :* BOUCADAIR Mohamed INNOV/NET <[email-masked]>; 
>> Jaime Jiménez <[email-masked]>; [email-masked]; Jeff Ahrenholz

---

From: <[email-masked]>
Date: Tue, 30 Nov 2021 08:20:47 +0000

Hi Stu, all

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Tm-rid <[email-masked]> De la part de Stuart W. Card
> Envoyé : lundi 29 novembre 2021 18:48
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; Robert
> Moskowitz <[email-masked]>
> Cc : [email-masked]; Jeff Ahrenholz <[email-masked]>
> Objet : Re: [Drip] WGLC of draft-ietf-drip-rid-13 (Ends 29/11/2021) ( was
> IETF 112 drip-rid presentation comment)
> 
> I am really more interested in the possibility of a multi-layer hierarchy.
> E.g., an 11 bit RAA identifier, an 11 bit HDA identifier, and a third 10
> bit identifier for an as yet unnamed thing between the RAA and the HDA. If
> you consider just aviation, maybe this is not needed; but we need a prefix
> from IANA for this to work. If that prefix is for _all_ HHITs, we have a
> problem: a 2 layer hierarchy won't support numerous industries cutting
> across numerous jurisdictions, with multiple registries in many industry *
> jurisdiction cross-product intersections.
> 
> If we intend to ask IANA for a prefix _dedicated to UAS RID_, I will shut
> up about this.

[Med] What I had in mind is the prefix is requested for the drip usage: UAS RID. 

 If we intend to ask IANA for a prefix for _HHITs_ in
> I believe the total registration hierarchy will be something like this, in
> the case of UAS RID --
> 

[Med] These are beyond the scope of the WG.