Subject: [Tm-rid] Fwd: New Version Notification for draft-moskowitz-hip-hierarchical-hit-00.txt

From: Robert Moskowitz <[email-masked]>
Date: Thu, 12 Sep 2019 12:52:52 -0400

Hello all.

Finally we are now funded to work on this project.  I am very unhappy at 
what it took to get to this point.   Fortunately, I have been using the 
time to put together some notes that I am quickly turning into drafts.

So work on tm-rid is now open.  Two more drafts will be posted in the 
next couple days.  I welcome reviews and comments.

Also I will be working with the AD for time at IETF106.

Bob

-------- Forwarded Message --------
Subject: 	New Version Notification for 
draft-moskowitz-hip-hierarchical-hit-00.txt
Date: 	Thu, 12 Sep 2019 09:49:01 -0700
From: 	[email-masked]
To: 	Stuart Card <[email-masked]>, Adam Wiethuechter 
<[email-masked]>, Robert Moskowitz 
<[email-masked]>, Stuart W. Card <[email-masked]>

A new version of I-D, draft-moskowitz-hip-hierarchical-hit-00.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-hip-hierarchical-hit
Revision: 00
Title: Hierarchical HITs for HIPv2
Document date: 2019-09-12
Group: Individual Submission
Pages: 9
URL: 
https://www.ietf.org/internet-drafts/draft-moskowitz-hip-hierarchical-hit-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-moskowitz-hip-hierarchical-hit/
Htmlized: 
https://tools.ietf.org/html/draft-moskowitz-hip-hierarchical-hit-00
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-hierarchical-hit

Abstract:
This document describes using a hierarchical HIT to facilitate large
deployments of managed devices. Hierarchical HITs differ from HIPv2
flat HITs by only using 64 bits for mapping the Host Identity,
freeing 32 bits to bind in a hierarchy of Registering Entities that
provide services to the consumers of hierarchical HITs.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 12 Sep 2019 14:32:40 -0400

Some points about Hierarchical HITs.

The idea is not new.  See draft-moskowitz-hip-04 from 7/01.  One bit was 
used to identity Hierarchical HITs (HHITs) over flat HITs.

Since this concept was removed I am now faced with how to tell the 
difference in the HIT encoding?

HHITs use a different ORCHID construction.  Kind of violation the ORCHID 
rules.  Remains to be seen if it will take a direct addendum to ORCHID 
for this.  The HID is included with the HI in computing the ORCHID.  I 
often wondered if the HIT Suite should have been included.  Since it 
wasn't we do have to be careful in specifying HIT Suites so it is not 
possible to have identical BIT-level HIs for different HIT Suites.  I am 
not attempting to change this part; maybe I should.

So given a HIT in the wild (I1, or UAS RID broadcast), how do you know 
if it is a HHIT.  Instead of burning through HIT suites as I first 
thought in draft-moskowitz-hierarchical-hip, I am specifying a unique 
HIT prefix for HHITs.

If anyone can see any other way, please speak up.  Again, the ORCHID 
prefix is specified in the ORCHID RFC.  Will we best do an update to ORCHID?

Please chime in.

Bob

On 9/12/19 12:52 PM, Robert Moskowitz wrote:
> Hello all.
>
> Finally we are now funded to work on this project.  I am very unhappy 
> at what it took to get to this point.   Fortunately, I have been using 
> the time to put together some notes that I am quickly turning into drafts.
>

-- 
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: "Wiethuechter, Adam" <[email-masked]>
Date: Wed, 18 Sep 2019 14:54:23 -0400

Bob,

Some comments from me that could be useful.

Section 3.1: "... provide an assertion as to why the claim should be
trusted and any additional side information about the device." To me this
is a series of secondary look-ups to other sources of information that the
party in question trusts to be valid and up to date. It is out of scope in
a sense as this can vary from use case to use case. Bringing it up how you
did I think is perfect to setup the discussion of why this draft is being
made.

Seeing as I created the python script to create HHITs nothing is new here
for me either - its just formalized more. I have nothing much to add here
other than to confront the question you have brought up in your recent
email. I vote that we strongly consider (if my idea below does not seem
sound) a new prefix for HHITs on an initial reading.

Reading 7401 (Section 5.2.10) it is noted that Suite ID is an octet in
length with the top 4 bits being the Suite ID and the lower bits set to 0.
This was done purposefully to fulfill this quote out out 7401: "This
difference is a measure to accommodate larger HIT Suite IDs if the 16
available values prove insufficient.  In that case, one of the 16 values,
zero, will be used to indicate that four additional bits of the ORCHID will
be used to encode the HIT Suite ID.  Hence, the current four-bit HIT Suite
IDs only use the four higher-order bits in the ID field.  Future documents
may define the use of the four lower-order bits in the ID field."

Perhaps the lower field could denote if we are an HHIT (or something else)
and the upper field stays as is as not to exhaust the list? I may need to
think of this more, perhaps this was your first idea but rejected it for a
reason I don't see yet. From a programming stand point things could get a
bit messy if not standardized correctly, I am hesitant because of this.

If we need to update ORCHID RFC for a new prefix does it hurt to also fold
in the construction changes as well in that update?

On Thu, Sep 12, 2019 at 2:33 PM Robert Moskowitz <[email-masked]>
wrote:

> rules.  Remains to be seen if it will take a direct addendum to ORCHID for
> this.  The HID is included with the HI in computing the ORCHID.  I often
> wondered if the HIT Suite should have been included.  Since it wasn't we do
> have to be careful in specifying HIT Suites so it is not possible to have
> identical BIT-level HIs for different HIT Suites.  I am not attempting to
> change this part; maybe I should.
>
> So given a HIT in the wild (I1, or UAS RID broadcast), how do you know if
> it is a HHIT.  Instead of burning through HIT suites as I first thought in
> draft-moskowitz-hierarchical-hip, I am specifying a unique HIT prefix for
> HHITs.
>
> So work on tm-rid is now open.  Two more drafts will be posted in the next
> couple days.  I welcome reviews and comments.
>
> To: Stuart Card <[email-masked]> <[email-masked]>,
> Adam Wiethuechter <[email-masked]>
> <[email-masked]> <[email-masked]>, Stuart W. Card
> <[email-masked]> <[email-masked]>
>
>
> 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
> --
> Tm-rid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tm-rid
>

-- 
73's,
Adam T. Wiethuechter

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 18 Sep 2019 23:11:04 -0400

On 9/18/19 2:54 PM, Wiethuechter, Adam wrote:
> trusted and any additional side information about the device." To me 
> this is a series of secondary look-ups to other sources of information 
> that the party in question trusts to be valid and up to date. It is 
> out of scope in a sense as this can vary from use case to use case. 
> Bringing it up how you did I think is perfect to setup the discussion 
> of why this draft is being made.

This is not so uncommon in an Introduction that provides some of the 
justification for the rest of the document.  It basically states why 
have a hierarchy in the HITs at all.  I feel we have a better 
understanding of where HHITs can be used today then we did when I first 
proposed this back in Dec '99:

draft-moskowitz-hip-arch-00

>
> Seeing as I created the python script to create HHITs nothing is new 
> here for me either - its just formalized more. I have nothing much to 
> add here other than to confront the question you have brought up in 
> your recent email. I vote that we strongly consider (if my idea below 
> does not seem sound) a new prefix for HHITs on an initial reading.
>
> length with the top 4 bits being the Suite ID and the lower bits set 
> to 0. This was done purposefully to fulfill this quote out out 7401: 
> "This difference is a measure to accommodate larger HIT Suite IDs if 
> the 16 available values prove insufficient.  In that case, one of the 
> 16 values, zero, will be used to indicate that four additional bits of 
> the ORCHID will be used to encode the HIT Suite ID.  Hence, the 
> current four-bit HIT Suite IDs only use the four higher-order bits in 
> the ID field.  Future documents may define the use of the four 
> lower-order bits in the ID field."
>
> Perhaps the lower field could denote if we are an HHIT (or something 
> else) and the upper field stays as is as not to exhaust the list? I 
> may need to think of this more, perhaps this was your first idea but 
> rejected it for a reason I don't see yet. From a programming stand 
> point things could get a bit messy if not standardized correctly, I am 
> hesitant because of this.

I am very hesitant to define HHIT suites by in a sense burning up the 
whole 9 - 16 space.

Plus I would have to take those 4 bits from something.  Either the HID 
or the hash.

HHIT HIT suite ID can be any of the current, plus the new ones I am 
defining.  Thus, for now, I will stay with a new prefix.

>
> If we need to update ORCHID RFC for a new prefix does it hurt to also 
> fold in the construction changes as well in that update?

Possibly.  We will have to see what the sense is from the chairs and AD 
on what documents to update.

>
> On Thu, Sep 12, 2019 at 2:33 PM Robert Moskowitz 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     The idea is not new.  See draft-moskowitz-hip-04 from 7/01. One
>     bit was used to identity Hierarchical HITs (HHITs) over flat HITs.
>
>     HHITs use a different ORCHID construction.  Kind of violation the
>     ORCHID rules.  Remains to be seen if it will take a direct
>     addendum to ORCHID for this.  The HID is included with the HI in
>     computing the ORCHID.  I often wondered if the HIT Suite should
>     have been included.  Since it wasn't we do have to be careful in
>     specifying HIT Suites so it is not possible to have identical
>     BIT-level HIs for different HIT Suites.  I am not attempting to
>     So given a HIT in the wild (I1, or UAS RID broadcast), how do you
>     know if it is a HHIT.  Instead of burning through HIT suites as I
>     first thought in draft-moskowitz-hierarchical-hip, I am specifying
>     a unique HIT prefix for HHITs.
>
>     If anyone can see any other way, please speak up.  Again, the
>     ORCHID prefix is specified in the ORCHID RFC.  Will we best do an
>     update to ORCHID?
>
>     Please chime in.
>
>     Bob
>
>>     Finally we are now funded to work on this project.  I am very
>>     unhappy at what it took to get to this point. Fortunately, I have
>>     been using the time to put together some notes that I am quickly
>>     turning into drafts.
>>
>>     So work on tm-rid is now open.  Two more drafts will be posted in
>>     the next couple days.  I welcome reviews and comments.
>>
>>     From: 	[email-masked] <mailto:[email-masked]>
>>     To: 	Stuart Card <[email-masked]>
>>     <mailto:[email-masked]>, Adam Wiethuechter
>>     <[email-masked]>
>>     <mailto:[email-masked]>, Robert Moskowitz
>>     <[email-masked]> <mailto:[email-masked]>,
>>     Stuart W. Card <[email-masked]>
>>     <mailto:[email-masked]>
>>
>>
>>
>>
>>     until the htmlized version and diff are available at
>>     tools.ietf.org <http://tools.ietf.org>.
>>
>>     The IETF Secretariat
>>
>>
>
>     -- 
>     Robert Moskowitz
>     Owner
>     HTT Consulting
>     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
>     -- 
>     Tm-rid mailing list
>     [email-masked] <mailto:[email-masked]>