Subject: [Drip] 64bit comments on draft-moskowitz-drip-uas-rid-06.txt

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 9 Sep 2020 15:14:35 +0200

I would like to suggest that the draft uses a variable-length stance 
when needing to talk about limits within addresses.

E.g. instead of hardcoding a 64bit limit in an ORCHID hash, rather make 
it variable: be it 65, or 35bit hash.

'Pre-image' - yes, attacks.  I must say that I do not know what it 
means.  Maybe one knows that better.

>   A HHIT is built from the following fields:
>
>     *  28 bit IANA prefix
>
>     *  4 bit HIT Suite ID
>
>     *  32 bit Hierarchy ID (HID)
>
>     *  64 bit ORCHID hash

Consider that SLAAC might put a 65 plen in an RA, at which point the 
Drone might need to form an IID of length different than 64, which might 
need to contain an ORCHID.  That ORCHID is probably not of length 64.

This is what I think I am suggesting.

I am aware that if one wants to do this non-64 ORCHID then it might 
probably need to modify many other Identity and ORCHID RFCs, and that 
other parts of this I-D might also contain 64bit limits (that I think of 
as artificial).  Still, I think I am suggesting it that way...

Alex

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 9 Sep 2020 09:20:03 -0400

Alex,

Interesting recommendation.  I am going to 'park' this comment and see 
what others say.  For now I will leave things as is.  Variable encoding 
has to be decoded.  How do I designate that in the HHIT? Needs lots of 
thought.

Bob

On 9/9/20 9:14 AM, Alexandre Petrescu wrote:
> E.g. instead of hardcoding a 64bit limit in an ORCHID hash, rather 
> make it variable: be it 65, or 35bit hash.
>
> Drone might need to form an IID of length different than 64, which 
> might need to contain an ORCHID.  That ORCHID is probably not of 
> length 64.
>
> other parts of this I-D might also contain 64bit limits (that I think 
> of as artificial).  Still, I think I am suggesting it that way...
>
> Alex
>
>

---

From: "Stuart W. Card" <[email-masked]>
Date: Sun, 13 Sep 2020 19:39:50 -0400

Although I know how variable encodings create work for programmers,
which means more opportunities for error, I would love to be able to
expand some of these fields if IANA were to give us a shorter prefix =>
larger space.

-- 
-----------------------------------------
Stuart W. Card, PhD, Principal Engineer
AX Enterprize, LLC  www.axenterprize.com
4947 Commercial Drive, Yorkville NY 13495

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 14 Sep 2020 11:35:39 +0200

Le 14/09/2020 à 01:39, Stuart W. Card a écrit :
> expand some of these fields if IANA were to give us a shorter prefix
> => larger space.

It makes sense, in a way, to request more space from IANA for drones.
It is also true that variable encodings might create unnecessary work.

But I was thinkig of a more immediate need and necessary approach.

It might be that a drone connects to Internet by using a cellular link
(a 4G module with a SIM card).  That module a /64 from the cellular
network.  There is no cellular network that would give it a /56 for example.

Given that a drone might carry several computers, not just one, there is
a problem in using just one /64 for the module - SLAAC cant be used
_inside_ the Ethernet in the drone network.  At that point there might
be need to construct Interface IDentifiers (IIDs) whose length is not
64, such that SLAAC still works ok.

That is one potential reason why 64bit limits in address structures (for
drones, in this case) should be avoided.

Alex

>> Interesting recommendation.  I am going to 'park' this comment and
>> see what others say.  For now I will leave things as is.  Variable
>> encoding has to be decoded.  How do I designate that in the HHIT?
>> Needs lots of thought.
>> 
>> Bob
>> 
>>> I would like to suggest that the draft uses a variable-length
>>> stance when needing to talk about limits within addresses.
>>> 
>>> E.g. instead of hardcoding a 64bit limit in an ORCHID hash,
>>> rather make it variable: be it 65, or 35bit hash.
>>> 
>>> 'Pre-image' - yes, attacks.  I must say that I do not know what
>>> it means.  Maybe one knows that better.
>>> 
>>> Consider that SLAAC might put a 65 plen in an RA, at which point
>>> the Drone might need to form an IID of length different than 64,
>>> which might need to contain an ORCHID.  That ORCHID is probably
>>> not of length 64.
>>> 
>>> I am aware that if one wants to do this non-64 ORCHID then it
>>> might probably need to modify many other Identity and ORCHID
>>> RFCs, and that other parts of this I-D might also contain 64bit
>>> limits (that I think of as artificial).  Still, I think I am
>>> suggesting it that way...
>>> 
>>> Alex
>>> 
>>> 
>> 
>> 
> 
>

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 15 Sep 2020 09:59:15 -0400

> expand some of these fields if IANA were to give us a shorter prefix =>

I did some sketches and then some calculations.

Prefix size    Hash size    .01% coll.    1% coll.

28            64            63M        663M
24           68            250M       2.5B
20           72            1B          10B

And remember, this is for a single HDA.

A /28 is OK, but that would mean expect collisions for some HDAs and 
reuse over time.

With a /20, it will be the exceptional HDA that needs to deal with 
collisions unless HHITs are never removed.  FedEx and UPS could easily 
re-ID each of their UAs everyday for years.  even for each delivery.

I don't think I will have time to rework the draft before the Interim.  
I have too much to do for ICAO as well.  Plus the Holidays start this 
weekend.  But I will look at how to rework the draft for differing 
prefix and hash sizes.

-- 
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: "Card, Stu" <[email-masked]>
Date: Tue, 15 Sep 2020 12:21:25 -0400

Musings...

I actually worry about driving the probability of hash collision too low:
having dealt with too many software development managers, I am certain that
some of them will dismiss very low probability collisions as not worth
costly programmer time to address. :-(

I am more interested in expanding the HIT Suite / OGA ID to provide greater
crypto agility, to deal with future actual or feared compromise (inc. by
quantum methods) of current cryptosystems.

We could also consider a 3 level or flexible hierarchy, although this would
be more challenging WRT parsing structure w/variable length fields.

On Tue, Sep 15, 2020, 9:59 AM Robert Moskowitz <[email-masked]>
wrote:

> A /28 is OK, but that would mean expect collisions for some HDAs and reuse
> over time.
>
> I don't think I will have time to rework the draft before the Interim.  I
> have too much to do for ICAO as well.  Plus the Holidays start this
> weekend.  But I will look at how to rework the draft for differing prefix
> and hash sizes.
>
>
>
> Robert Moskowitz
> 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: Tue, 15 Sep 2020 12:41:21 -0400

On 9/15/20 12:21 PM, Card, Stu wrote:
> Musings...
>
> I actually worry about driving the probability of hash collision too 
> low: having dealt with too many software development managers, I am 
> certain that some of them will dismiss very low probability collisions 
> as not worth costly programmer time to address. :-(

this is more an operational issue IMHO.

UA generates a HHIT.  It registers it.  HDA rejects due to collision:  
try again...

So there is a practical point to collisions, and why I chose .01%. Kind 
of arbitrary, but the point is where IS the pain point to the HDA and 
UAs on registration.

Then given this, what is the operational model for the HDA?  Are the UAs 
getting a 'lifetime' HHIT, like for professional photographers or news 
services?  Or is UPS getting a 1M HHITs for its fleet to use for the 
day?  It is this latter case that I am considering.  Of course, it might 
make sense for UPS to work with 100 HDAs to spread its UAs across for 
business reasons....

Also the registration cost has to be 'right'.  Which means the 
registration process has to be low operational cost.

All this is SUPPOSE to be captured in the RID registry draft. (Hint, 
hint)  I did try to include some of these thoughts in the HHIT-registry 
draft that I originally wrote as a bit of a place holder.

>
> I am more interested in expanding the HIT Suite / OGA ID to provide 
> greater crypto agility, to deal with future actual or feared 
> compromise (inc. by quantum methods) of current cryptosystems.

I think we are ok here.  We are so far taking a conservative approach 
with cipher suites.  Only allocate for what really brings value.  Let 
TLS and IKE be the proving ground!  ;)

> We could also consider a 3 level or flexible hierarchy, although this 
> would be more challenging WRT parsing structure w/variable length fields.

No to flexible hierarchy IMHO.

I have considered 3rd level of 'local control'.  But this is almost like 
being your own little CA under say the CyberTrust CA.  Too much of a 
trust issue.  I think 2 will do, but it will take rubber on the road to 
know if this is correct.

>
> On Tue, Sep 15, 2020, 9:59 AM Robert Moskowitz 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
>     A /28 is OK, but that would mean expect collisions for some HDAs
>     and reuse over time.
>
>     collisions unless HHITs are never removed.  FedEx and UPS could
>     easily re-ID each of their UAs everyday for years.  even for each
>     delivery.
>
>     I don't think I will have time to rework the draft before the
>     Interim.  I have too much to do for ICAO as well.  Plus the
>     Holidays start this weekend.  But I will look at how to rework the
>     draft for differing prefix and hash sizes.
>

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 15 Sep 2020 13:17:15 -0400

More thoughts on registration.  Michael Palage and Amelia, I am 
interested in your insights (and get that registry draft going!):

On 9/15/20 12:41 PM, Robert Moskowitz wrote:
>> certain that some of them will dismiss very low probability 
>> collisions as not worth costly programmer time to address. :-(
>

Consider Acme Widgets that provides HDA services to some delivery 
services and forecasts dealing with 1M HHIT registrations per day. As 
currently defined, an HDA might be operationally 'full' in 2 months.  
Thus Acme would have requested from its RRA, Apex Widgets, a block of 
128 HDAs.  It might run the all at the same time or 1 at a time and 
'close' them as they get full.

Since these are 1-day use HHITs, the policy for the HDA could be to 
flush all content after 2 years and recycle the HDA.  Or with 2^16 HDAs 
available from Apex, keep them unused for 10 - 20 years (at which time 
we would be using a new HIT Suite anyway).

So what is the operational view for capacity of an HDA?  63M or 1B?

Other's thoughts?

>
> So there is a practical point to collisions, and why I chose .01%.  
> Kind of arbitrary, but the point is where IS the pain point to the HDA 
> and UAs on registration.
>
> Then given this, what is the operational model for the HDA?  Are the 
> UAs getting a 'lifetime' HHIT, like for professional photographers or 
> news services?  Or is UPS getting a 1M HHITs for its fleet to use for 
> the day?  It is this latter case that I am considering.  Of course, it 
> might make sense for UPS to work with 100 HDAs to spread its UAs 
> across for business reasons....
>
> hint)  I did try to include some of these thoughts in the 
> HHIT-registry draft that I originally wrote as a bit of a place holder.
>
>
>>
> I have considered 3rd level of 'local control'.  But this is almost 
> like being your own little CA under say the CyberTrust CA. Too much of 
> a trust issue.  I think 2 will do, but it will take rubber on the road 
> to know if this is correct.
>
>>
>>     With a /20, it will be the exceptional HDA that needs to deal
>>     with collisions unless HHITs are never removed. FedEx and UPS
>>     could easily re-ID each of their UAs everyday for years.  even
>>     for each delivery.
>>
>>     Holidays start this weekend.  But I will look at how to rework
>>     the draft for differing prefix and hash sizes.
>>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Sep 2020 16:02:54 -0400

Robert Moskowitz <[email-masked]> wrote:
    > Consider Acme Widgets that provides HDA services to some delivery services
    > and forecasts dealing with 1M HHIT registrations per day. As currently
    > defined, an HDA might be operationally 'full' in 2 months.  Thus Acme would
    > have requested from its RRA, Apex Widgets, a block of 128 HDAs.  It might run
    > the all at the same time or 1 at a time and 'close' them as they get full.

Does it generate an HHIT, and then look for an RRA in which there is no collision?

    > Since these are 1-day use HHITs, the policy for the HDA could be to flush all
    > content after 2 years and recycle the HDA.  Or with 2^16 HDAs available from
    > Apex, keep them unused for 10 - 20 years (at which time we would be using a
    > new HIT Suite anyway).

If they are going to only use the HHIT on a single day, then aside from the
latency of delivery, why do they have to wait 2 years?  Assuming that Acme
HDA Services delivers batches of 4096 or something HDAs to Acme Delivery
Widgets every month (around the 24th), for use in the following month, then
after the 1st the following month, they are either all used in an Operation,
or expired, right?

There are edge conditions in reporting... (that Operation at 23:47 could have
bleed into the next day, and then some report of problems got UTC and local
time confused, and was it Thursday or Tuesday, or some other day that starts
with a T...)

[https://www.goodreads.com/book/show/18138994-great-north-road includes a
very complex murder investigation in a snowy Newcastle SmartCity circa 2143,
where the otherwise identical looking autonomous taxi cabs keep [illegally]
swapping HDAs...]

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "Stuart W. Card" <[email-masked]>
Date: Tue, 15 Sep 2020 16:22:05 -0400

Data retention time for UAS RID and UTM proposed by US FAA is exactly 6
months, not a day less, not a day more (they have been pretty emphatic
on that balance between privacy and needs of law enforcement).

Our concept has been:

(0) UAS operator previously has subscribed to at least one USS that
either provides or resells/bundles registry/HDA services.

(1) UAS operator self-generates HHIT, but it isn't verifiable until
there is a corresponding cert from the registry/HDA, so operator
_proposes_ the HHIT to the HDA, either gets back a cert or doesn't.

(2..n) If there is a collision in the attempted registration, HDA
notifies operator, the latter self-generates a new keypair, hashes it
etc. to self-generate a new HHIT and proposes that, keeps trying until
succeeds or exceeds retry limit (presumably in operator contract w/USS).

Nothing precludes an operator from using the services of multiple USS,
as might be prudent for someone with severe privacy concerns. While the
same keypair might be re-used in different hierarchies, this seems silly
if the motivation for multiple USS was privacy; it might make sense if
there was some other motivation. Different keypairs that result in hash
collisions within the same HDA will be rejected at registration time;
different keypairs that result in hash collisions across different
hierarchies are of no apparent consequence.

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 15 Sep 2020 17:01:55 -0400

> Does it generate an HHIT, and then look for an RRA in which there is no collision?

No.  The RAA|HDA is part of the hashing input.  They HHIT is thus bound 
to the RRA|HDA.

Very important feature.  The prefix is ALSO part of the hashing input.

See Appendix C.

> after the 1st the following month, they are either all used in an Operation,

FAA is specifying 6 months retention of RID by USS/UTM.  I just 
lengthened it for worst case.

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 15 Sep 2020 17:07:15 -0400

> on that balance between privacy and needs of law enforcement).

It might be a different item between retention of information associated 
with a RID and reuse of an RID.

So all information about the RID is dropped after 6 mo.  But the RID is 
kept for m months for collision checking?

Be liberal in what you accept and conservative in what you send.....

> _proposes_ the HHIT to the HDA, either gets back a cert or doesn't.

You are adding the cert portion.  But the generated HHIT is for a 
specific RAA|HDA.  Nothing to stop UAS from using the same HI for 
multiple RAA|HDA, but they will be different HHIT.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Sep 2020 17:11:35 -0400

> on that balance between privacy and needs of law enforcement).

okay.
In my mind, the HHIT would be in DNS for the ~2 months until the HHIT is
purged.  Then it would be removed from public view, but that doesn't mean it
has to be deleted.

If you are saying that LEA is screwed if they don't serve a warrant within
six months, then I'm surprised by that, but okay. That still fits in my
timeline, and it still isn't 2yrs.

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 15 Sep 2020 17:17:18 -0400

> timeline, and it still isn't 2yrs.

I threw 2 yrs in there as a debate point.  Not a stake in the ground 
(did I ever tell you what I learned about the Iroquois origins?).

I was aware of the FAA 6mo position.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 16 Sep 2020 10:42:02 +0200

Le 15/09/2020 à 18:21, Card, Stu a écrit :
> low:

We can drive the probability of hash collisions up by reducing the 
prefix size, and implicitly increasing the IID size, from 64 to 65 for 
example.

Alex

  having dealt with too many software development managers, I am
> greater crypto agility, to deal with future actual or feared compromise 
> (inc. by quantum methods) of current cryptosystems.
> 
> On Tue, Sep 15, 2020, 9:59 AM Robert Moskowitz <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
> 
>     Interim.  I have too much to do for ICAO as well.  Plus the Holidays
>     start this weekend.  But I will look at how to rework the draft for
>     differing prefix and hash sizes.
> 
>     C:__ __248-219-2059
>     F:__ __248-968-2824
>     E:__ [email-masked] <mailto:[email-masked]>
> 
>     There's no limit to what can be accomplished if it doesn't matter
>     who gets the credit
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 16 Sep 2020 10:44:16 +0200

Le 15/09/2020 à 22:22, Stuart W. Card a écrit :
> months, not a day less, not a day more

One seems to want to be very precise here, but one might also wonder 
which 6 months?  Because they are not created equal.

Alex

  (they have been pretty emphatic

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 16 Sep 2020 08:18:03 -0400

> prefix size, and implicitly increasing the IID size, from 64 to 65 for 

The hash size will most likely be on nibble boundaries.  So 64 or 68 or 72.

>>>>> stance
>>>>> rather
>>>>> might
>>     --     Robert Moskowitz

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 16 Sep 2020 08:22:02 -0400

> which 6 months?  Because they are not created equal.

 From my reading of the FAA NPRM (Notice of Proposed Rule Making), it is 
6 months from last 'used'.  That is the last time it was recorded in a 
USS/UTM.

Thing is what about when the operator has put the UAS away in a closet 
and now wants to use it again?  Do they have to get a new RID or just 
restart using the old?  This question is potentially answered 
differently for each RID type.  And each USS management approach (e.g. 
RID in USS signed cert with expiry date).

>>>      > Consider Acme Widgets that provides HDA services to some 
>>> delivery services
>>>      > and forecasts dealing with 1M HHIT registrations per day. As 
>>> currently
>>>      > defined, an HDA might be operationally 'full' in 2 months.  
>>> Thus Acme would
>>>      > have requested from its RRA, Apex Widgets, a block of 128 
>>> HDAs.  It might run
>>>      > the all at the same time or 1 at a time and 'close' them as 
>>> they get full.
>>>
>>>      > Since these are 1-day use HHITs, the policy for the HDA could 
>>> be to flush all
>>>      > content after 2 years and recycle the HDA.  Or with 2^16 HDAs 
>>> available from
>>>      > Apex, keep them unused for 10 - 20 years (at which time we 
>>> would be using a
>>>      > new HIT Suite anyway).
>>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 16 Sep 2020 14:24:16 +0200

> The hash size will most likely be on nibble boundaries.  So 64 or 68 or 72.

It is indeed easier to fit the bit boundaries on the underlying 
computing architecture.  It is easier for programmmers.

But there are so many such architectures, and so many IP addressing 
architecture constraints in deployment (e.g. if ISP gives me a /57 
because they so wish I think I have much interest in not wasting any 
intermediary bit just to accommodate an RFC assumption).

Ideally, one would make these IID and prefix lengths just parameters 
that would work anywhere between 0 and 127.

Alex

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 16 Sep 2020 08:41:42 -0400

On 9/16/20 8:24 AM, Alexandre Petrescu wrote:
>>> prefix size, and implicitly increasing the IID size, from 64 to 65 
>>> for example.
>>

In the next rev of drip-uas-rid, I plan on making the ORCHID algorithm 
completely parameterized.  Then let a specific deployment model provide 
what is used.

However, the decoding rules have to be 'obvious' from the HHIT. Right 
now it is based on Prefix value.  And if prefix sizes are all over the 
map, how will an implementation determine the decoding rule?

So there are limitations on the ORCHID construction due to ORCHID 
deconstruction...

For example a HHIT receiver MUST be able to decode it to get the RRA/HDA 
values for retrieval purposes.  And 'obviously' the OGA...

Bob

>>>> We could also consider a 3 level or flexible hierarchy, although 
>>>> this would be more challenging WRT parsing structure w/variable 
>>>> length fields.
>>>>
>>>> Holidays

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 17 Sep 2020 15:24:19 +0200

Le 16/09/2020 à 14:41, Robert Moskowitz a écrit :
>>>> We can drive the probability of hash collisions up by reducing
>>>> the prefix size, and implicitly increasing the IID size, from
>>>> 64 to 65 for example.
>>> 
>>  because they so wish I think I have much interest in not wasting
>> any intermediary bit just to accommodate an RFC assumption).
>> 
>> Ideally, one would make these IID and prefix lengths just
>> parameters that would work anywhere between 0 and 127.
> 
> In the next rev of drip-uas-rid, I plan on making the ORCHID
> algorithm completely parameterized.  Then let a specific deployment
> model provide what is used.
> 
>  now it is based on Prefix value.  And if prefix sizes are all over
> the map, how will an implementation determine the decoding rule?

That is a problem indeed.  But it might be a problem because the bits in
the address are overloaded with significance, rather than letting them
be used for routing and addressing exclusively.  There is an RFC that
tells that the Significance of IPv6 Interface Identifiers - there is no
siginificance, they are opaque.

Maybe we want to add some significance to the bits, but keep it as low
as possible.

Also, there is this ULA space.  Maybe we want to work in the ULA space
and crowd these bits in there exclusively.

For example, a HHID IP address would be an address of the form
fd00:a:b:c:d:publickey.  'a' and 'b' would say that this is a HHIT.  All
the rest of the bits would be encoded the way the author wishes, but it
would all be within this ULA 'walled garden'.

Maybe there are other ways (other than ULA) to deal with the encoding
problem you mention above.  Maybe reserve a few bits to encode the way
to decode.

But it would be good to not impose again new 64limits in the address space.

Alex

> For example a HHIT receiver MUST be able to decode it to get the
> RRA/HDA values for retrieval purposes.  And 'obviously' the OGA...
> 
> Bob
> 
>> 
>> Alex
>> 
>>> 
>>>> 
>>>> Alex
>>>> 
>>>>> I am more interested in expanding the HIT Suite / OGA ID to
>>>>> provide greater crypto agility, to deal with future actual or
>>>>> feared compromise (inc. by quantum methods) of current
>>>>> cryptosystems.
>>>>> 
>>>>> We could also consider a 3 level or flexible hierarchy,
>>>>> although this would be more challenging WRT parsing structure
>>>>> w/variable length fields.
>>>>> 
>>>>>> Although I know how variable encodings create work for 
>>>>>> programmers, which means more opportunities for error, I
>>>>>> would love to be able to expand some of these fields if
>>>>>> IANA were to give us a shorter prefix => larger space.
>>>>> 
>>>>> 28            64            63M        663M 24           68
>>>>> 250M       2.5B 20           72            1B          10B
>>>>> A /28 is OK, but that would mean expect collisions for some 
>>>>> HDAs and reuse over time.
>>>>> 
>>>>> with collisions unless HHITs are never removed.  FedEx and
>>>>> UPS could easily re-ID each of their UAs everyday for years.
>>>>> even for each delivery.
>>>>> 
>>>>> I don't think I will have time to rework the draft before
>>>>> the Interim.  I have too much to do for ICAO as well.  Plus
>>>>> the Holidays start this weekend.  But I will look at how to
>>>>> rework the draft for differing prefix and hash sizes.
>>>>> 
>>>>>>> Interesting recommendation.  I am going to 'park' this 
>>>>>>> comment and see what others say.  For now I will leave
>>>>>>> things as is. Variable encoding has to be decoded.  How
>>>>>>> do I designate that in the HHIT? Needs lots of thought.
>>>>>>> 
>>>>>>> Bob
>>>>>>> 
>>>>>>>> I would like to suggest that the draft uses a 
>>>>>>>> variable-length stance when needing to talk about
>>>>>>>> limits within addresses.
>>>>>>>> 
>>>>>>>> E.g. instead of hardcoding a 64bit limit in an ORCHID
>>>>>>>> hash, rather make it variable: be it 65, or 35bit
>>>>>>>> hash.
>>>>>>>> 
>>>>>>>> 'Pre-image' - yes, attacks.  I must say that I do not
>>>>>>>> know what it means.  Maybe one knows that better.
>>>>>>>> 
>>>>>>>> Consider that SLAAC might put a 65 plen in an RA, at
>>>>>>>> which point the Drone might need to form an IID of
>>>>>>>> length different than 64, which might need to contain
>>>>>>>> an ORCHID.  That ORCHID is probably not of length 64.
>>>>>>>> 
>>>>>>>> I am aware that if one wants to do this non-64 ORCHID
>>>>>>>> then it might probably need to modify many other
>>>>>>>> Identity and ORCHID RFCs, and that other parts of this
>>>>>>>> I-D might also contain 64bit limits (that I think of as
>>>>>>>> artificial).  Still, I think I am suggesting it that 
>>>>>>>> way...
>>>>>>>> 
>>>>>>>> Alex
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>> 
>

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 17 Sep 2020 10:27:46 -0400

> siginificance, they are opaque.

Read

https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/

For the why for HITs.  They are NOT for routing.

There are stack reasons behind using IPv6 address space for HITs. HHIT 
expands on this.

> But it would be good to not impose again new 64limits in the address 

Not new.  Goes back to RFC 4423 and 5201.

>>>>>>>> Interesting recommendation.  I am going to 'park' this comment 
>>>>>>>> and see what others say.  For now I will leave
>>>>>>>>> artificial).  Still, I think I am suggesting it that way...
>>>>>>>>>
>>>>>>>>> Alex
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>
>

---

From: "Card, Stu" <[email-masked]>
Date: Thu, 17 Sep 2020 13:38:08 -0400

Bob's points are sound, but I don't think meant to dispute Alexandre's
major point, with which I agree:

Maybe we want to add some significance to the bits, but keep it as low as
 possible.

On Thu, Sep 17, 2020, 10:28 AM Robert Moskowitz <[email-masked]>
wrote:

> It is indeed easier to fit the bit boundaries on the underlying computing
> architecture.  It is easier for programmmers.
>
> certain that some of them will dismiss very low probability collisions as
> not worth costly programmer time to address.
> :-(
>
> <mailto:[email-masked]> <[email-masked]>>
> wrote:
>
>
>
> Although I know how variable encodings create work for programmers, which
> means more opportunities for error, I
> what others say.  For now I will leave
> I would like to suggest that the draft uses a variable-length stance when
> needing to talk about
> limits within addresses.
>