Re: Progress?

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

>  
>  Obviously we need to see more to understand what Paul means by all
>  this, but:
>  
>  To me the ID is in one-to-one correspondence with the name. A name has
>  no semantics. We make it hierarchical to make it unique but the
>  geography that *seems* to be implied by the hierarchical structure is
>  an illusion. For example there is nothing to stop me creating an entry
>  in the mel.dit.csiro.au namespace for a machine in America.

That's right, but I would characterize the hierarchy in there
to be both for the purpose of uniqueness and for being able
to traverse the domain name hierarchy.  I consider the latter
to be more important (well, not more important, since uniqueness
is obviously important, but I would say there are other ways to
insure uniqueness but not other ways to traverse the tree).

>  
>  In the same way I can't see how using the IP address space to build
>  unique IDs can constrain anything. If it is a mobile host you might
>  not want to use the IP address the host is currently using. And if you
>  do that then you have to be careful of what use you make of an IP
>  address in an ID for transitional semantics.

Yes, that's right, you have to because what use of the IP address you
make.  I'm finding that if it used "like an IP address", (meaning
that, once it is translated into an IP packet as used to route on),
then you suffer all the constraints of IP.  If it is not used as
an IP address, then there isn't much point to using it at all, because
it constrains auto-configuration.  I want a person to bring up a
host without having to do any administration.....

>  
>  And the thought of a completely unstructured ID leaves me bemused.
>  

Well, the whole issue of how much and what structure to put in the
ID is complex.  I can see arguments on both sides, but now that I
am getting round to really assigning IDs I'm balking at the cost of
putting in the structure, and at deciding just what the structure
should be.  I had been thinking that you want to put some kind of
organizational affiliation in the ID, for instance in order to do
inverse lookups on IDs or to do accounting on packets or something.
But, that puts constraints on IDs that, it seems inevitably, would
force you into having to change IDs over time when administrative
structure changes.  Thus, some (but by no means all) of the hassles
I was hoping to avoid in addressing by having the ID (and by making
the address an FTIF Chain rather than a single field) creep into
managing the ID.  If the ID is just flat (like an ethernet number,
understanding that an ethernet number has its own assignment
hierarchy) then it is very easy to deal with from a Pip layer perspective.
I can think of various ways to do such things as inverse lookups
if necessary (or, by and large, avoid them).

Well, its a trade off.  For now, I'm inclined to go with flat IDs,
with the understanding that we can always add structure to them
someday if it seems important......

PX