Re: [Tm-rid] RAA/HDA - drawing the line in 32 bits

[Robert Moskowitz <[e-mail]>]

And it is more than that.

The USS may run one HDA for the pilot system and not publish the HI for 
those systems.  Only authorized people need to know how to contact the 
piloting system.  Whereas the HHIT for the UA is public along with the 
HI.  Pilot systems will tend to be stable, though the binding to pilot 
will change but that is USS backend data.  It is the UA HHIT that may 
change.

I don't think the blockchain stuff helps here.

As to how to gen a new keypair it might just gen or use:

draft-barnes-cfrg-mult-for-7748

It is a tossup as to which is computationally and power cheaper.  I plan 
on referencing the above draft in the next ver of HHIT.

On 11/21/19 5:55 PM, Card, Stu wrote:
> I think we need to assume that many commercial UAS operators will use 
> 1 HHIT per flight. Given the large number of UAS & frequency of 
> flights, this will rapidly consume enough of even a large space that 
> collisions will rise. So HHITs will need lifetimes & to be reclaimed 
> for re-use.
>
> I know many will pillory me for saying this: maybe claim a HHIT by 
> appending it in a blinded form to a blockchain? For blinding, I'm 
> thinking back before Satoshi Nakamoto, to David Chaum's & Stefan 
> Brands' work... also more recently Jan Camenisch & Anna Lyskayana...
>
> On Thu, Nov 21, 2019, 5:09 PM Robert Moskowitz 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>
>
>     On 11/21/19 3:16 PM, Tero Kivinen wrote:
>>     Robert Moskowitz writes:
>>>     In draft-moskowitz-hip-hierarchical-hit-01.txt, I use 14 bits (16,384)
>>>     for the RAA space and 18 bits (262,144) for HDA within each RAA.  Seems
>>>     reasonable enough for me.  Good as any guess about the future.
>>>
>>>     Tero Kivinen suggested a soft separation with the HDA in little endian
>>>     order.  This way we might have time to figure out where we need more,
>>>     RAAs or HDAs.
>>>
>>>     Sounds interesting, but I see potential problem(s) if one RAA really
>>>     runs up its number of HDAs and thus limits the number of RAAs in total
>>>     as a result.
>>     I think we should be strict hard limit for RAAs for how many HDAs it
>>     can before it needs to come back for asking changing. For example say
>>     12-bits for HDAs and if it looks like there are going to be multiple
>>     RAAs running out of 12-bit space, then we can expand it to 16-bit etc.
>>
>>     If it just one RAA getting very large, we can of course give him
>>     2nd RAA number.
>
>     Another item to toss into the mix is an HDA requesting a second or
>     so number.  After registering so many HHITs, the collision rate
>     becomes 'unacceptable' and the move to a new HDA number for new
>     registrations.
>
>     How many deliveries might UPS make a day via UAs?  A new HHIT per
>     delivery or only per day?  This could run through a lot of HHITs.
>
>     Will some HDAs deprecate expired HHITs and allow reuse or keep the
>     numbers around even after they are released by the owner?
>
>     All policy issues that will impact the hierarchy space.
>
>
>>     The IPv4 addresses just showed that we can never get the split right
>>     on the first time...
>>
>>>     Oh, and the 32bit space will be represented in DNS as nibbles.
>
>     -- 
>     Robert Moskowitz
>     Owner
>     HTT Consulting
>     C: 248-219-2059
>     F: 248-968-2824
>     E: [e-mail] <mailto:[e-mail]>
>
>     There's no limit to what can be accomplished if it doesn't matter
>     who gets the credit
>     -- 
>     Tm-rid mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/tm-rid
>

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

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