Re: Inverse queries on EID; autoconfiguration

[Paul Francis--formerly Tsuchiya <[e-mail]>]

>  
>  Taking the concept of the EID to heart, I don't want ``normal''
>  application programs to ever see the Pip address of any host.  What I
>  would do is the following:
>  
>  ..............
>  ------------------------------------
>  So, you can see, the user program would never see the addressing
>  information, only the EID.

This should be possible without doing the separate lookup on
ID.  The idea is that the "host" gets back all the relavent
info from DNS on the first DNS lookup (ID and addresses), but
if the application doesn't want to look at addresses, they
are just passed down to the Pip layer.  Later, when the application
sends a packet down to the Pip layer with an ID, the Pip layer
looks up the addresses locally and creates the Pip header.

>  
>  > I agree that the autoconfiguration of hierarchical IDs isn't that bad, but
>  > it can be avoided altogether if the IDs are flat.  Also, with flat IDs
>  > you don't have to worry about changing them when the host joins a new
>  > organization.
>  
>  When a ``host joins a new organization'', somebody is going to have to
>  go in there and update the DNS to reflect that the host has moved from
>  organization A to organization B.  It's no easier to update the DNS to
>  stick in an 802 number than it is to update the DNS to stick in the
>  next number in the organization's assigned ID space; indeed, the
>  latter can be much more easily automated than the former.

I don't think so.  When you have a hierarchical space, you have
all the questions of how much space to allocate to each part of
the hierarchy, what do you do when you under-allocate, and so on.
I don't think this aspect is a show stopper one way or the other.....

>  
>  Dynamic updates to the DNS open up a whole new can of security worms
>  which we really shouldn't be dealing with.

Hmmmmm.  I don't disagree about the security worms, but I
don't think we should eliminate

>  
>  > Also, if the ID has organizational significance, what is the meaning
>  > of a mobile host temporarily moving to another organization?  Does
>  > it get a new ID?  Of course it shouldn't, but what if the
>  > organization is filtering based on ID?
>  
>  Pip does not, in its present form, provide any mechanism by which this
>  sort of filtering can be accomplished securely.  Any conceivable
>  security mechanism which could do this would require setup work
>  comparable to adding a new ID to a filter expression somewhere anyway.
>  You get what you pay for...

I think my statement was confusing.  I wasn't implying that one
should filter on ID.  If fact, I don't think one should, but if we
have organizational IDs, I suspect someone will start filtering
on IDs, or start depending on their organizational content for
one thing or another (billing or accounting or something).  Once
this kind of dependency starts, then one loses much of the freedom of
mobility that flat IDs buy.

>  
>  > The hierarchical ID introduces a number of questions that I didn't
>  > find easy answers for.....
>  
>  Fire away, and I'll see if I can't demolish them all (or at least
>  point out where they are inconsistent).
>  

I think the two major difficulties I had were how to assign 
them, including auto-configuration, and a general concern that
we would lose things such as mobility once parts of the internet
started depending on the structure of IDs for "non-Pip" functions.

Perhaps dealing with hierarchical IDs was just too much work for
me to handle, so I jettisoned them (not for good, mind you, but
for now).  I think auto-configuration is important, and it is so
much easier with flat IDs.  I didn't say I couldn't find answers
for hierarchical IDs, I just said they weren't easy....

PF