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

From: Robert Moskowitz <[email-masked]>
Date: Wed, 1 Dec 2021 12:19:59 -0500

We MUST NOT in the broader use have a hash less than 64 bits. Enough 
issues with this.  So either go with my 'closed enclave' 60 bits for the 
8 bit Suite ID, or take 4 bits out of the stuff to the left.  Smaller 
HID space or smaller prefix.

I can't budge on a 64 bit hash as the MINIMUM.  I really don't like the 
60 bit closed enclave hack.

Bob

On 11/29/21 12:59, Stuart W. Card wrote:
> 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:
>> 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:
>>> 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
>
>

---

From: <[email-masked]>
Date: Thu, 2 Dec 2021 09:44:16 +0000

Hi Bob, all, 

I'm afraid that we don't have strong justification to ask for a shorter prefix vs the length that is used for ORCHID. No?

BTW, Bob can you please update the draft to follow this template for the prefix request from 2001::/23?  

=====
   o  Address Block - A block of IPv6 addresses that has been
      registered for a special purpose.

   o  Name - A descriptive name for the special-purpose address block.

   o  RFC - The RFC through which the special-purpose address block was
      requested.

   o  Allocation Date - The date upon which the special-purpose address
      block was allocated.

   o  Termination Date - The date upon which the allocation is to be
      terminated.  This field is applicable for limited-use allocations
      only.

   o  Source - A boolean value indicating whether an address from the
      allocated special-purpose address block is valid when used as the
      source address of an IP datagram that transits two devices.

   o  Destination - A boolean value indicating whether an address from
      the allocated special-purpose address block is valid when used as
      the destination address of an IP datagram that transits two
      devices.

   o  Forwardable - A boolean value indicating whether a router may
      forward an IP datagram whose destination address is drawn from the
      allocated special-purpose address block between external
      interfaces.

   o  Global - A boolean value indicating whether an IP datagram whose
      destination address is drawn from the allocated special-purpose
      address block is forwardable beyond a specified administrative
      domain.

   o  Reserved-by-Protocol - A boolean value indicating whether the
      special-purpose address block is reserved by IP, itself.  This
      value is "TRUE" if the RFC that created the special-purpose
      address block requires all compliant IP implementations to behave
      in a special way when processing packets either to or from
      addresses contained by the address block.
======

Thank you. 

Cheers,
Med

> -----Message d'origine-----
> De : Robert Moskowitz <[email-masked]>
> Envoyé : mercredi 1 décembre 2021 18:20
> À : Stuart W. Card <[email-masked]>; BOUCADAIR Mohamed
> INNOV/NET <[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)
> 
> 8 bit Suite ID, or take 4 bits out of the stuff to the left.  Smaller HID
> space or smaller prefix.
> 

_________________________________________________________________________________________________________________________

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: Robert Moskowitz <[email-masked]>
Date: Thu, 2 Dec 2021 05:48:54 -0500

Med,

No, we don't have a strong justification for a shorter prefix.  We have 
precedence for /28 (over LISP's /32) so we ask for that.  And worst 
case, IANA repurposes HIPv1 prefix.

I am updating drip-rid today, and will look at this template.

I am not making any change to the HHIT structure, thanks for your ascii 
art, with this ver.

Bob

---

From: <[email-masked]>
Date: Thu, 2 Dec 2021 13:37:33 +0000

Re-,

Thanks, Bob. 

As you are updating the draft, you may want address the (pre-)Shepherd review available at :-)

* pdf: https://raw.githubusercontent.com/boucadair/IETF-Drafts-Reviews/master/draft-ietf-drip-rid-13-rev%20Med.pdf
* doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-drip-rid-13-rev%20Med.doc 

Thank you. 

Cheers,
Med

> Envoyé : jeudi 2 décembre 2021 11:49
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; Stuart W.
> Card <[email-masked]>
> precedence for /28 (over LISP's /32) so we ask for that.  And worst case,
> IANA repurposes HIPv1 prefix.
> 
> > I'm afraid that we don't have strong justification to ask for a shorter
> prefix vs the length that is used for ORCHID. No?
> >
> >> De : Robert Moskowitz <[email-masked]> Envoyé : mercredi 1
> >> décembre 2021 18:20 À : Stuart W. Card <[email-masked]>;
> >> BOUCADAIR Mohamed INNOV/NET <[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)
> >>
> > ______________________________________________________________________
> > ___________________________________________________
> >
> > 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.

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 2 Dec 2021 08:52:16 -0500

Med,

AFTER I get the changes done I know about, I will read this and see 
about including your review.

Thank you for doing that.

Bob

On 12/2/21 08:37, [email-masked] wrote:
> * pdf:https://raw.githubusercontent.com/boucadair/IETF-Drafts-Reviews/master/draft-ietf-drip-rid-13-rev%20Med.pdf
> * doc:https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-drip-rid-13-rev%20Med.doc  
>
> Thank you.
>
> Cheers,
> Med
>
>> De : Robert Moskowitz<[email-masked]>
>> À : BOUCADAIR Mohamed INNOV/NET<[email-masked]>; Stuart W.
>> Card<[email-masked]>
>> Cc :[email-masked]; Jeff Ahrenholz<[email-masked]>
>> On 12/2/21 04:44,[email-masked]  wrote:
>>> Hi Bob, all,
>>>
>>>> De : Robert Moskowitz<[email-masked]>  Envoyé : mercredi 1
>>>> décembre 2021 18:20 À : Stuart W. Card<[email-masked]>;
>>>> BOUCADAIR Mohamed INNOV/NET<[email-masked]>  Cc :
>>>> [email-masked]; Jeff Ahrenholz<[email-masked]>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[email-masked]

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

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 2 Dec 2021 14:29:41 -0500

I just finished a ver 14 to post.  Attached is my comments on your 
review.  I got most of it...

Submitting shortly.

Bob