> From: Michael Menth <[email protected]>
>> "locator and identifier" is not really optimal terminology, because
>> those refer to specific kinds of names, and it's better to refer to
>> the generic concepts, i.e. 'identity' and 'location'.
> Many proposals actually deal with network attachment points (RLOCs)
> and names of endpoints (EIDs) which both serve to find the desired
> endpoint/interface. ... They usually do not imply an identity that
> could easily move from one to another network or from one to another
> device.
There is something to this, but I was speaking in the abstract, not about
any particular proposal.
Also, as I've mentioned before, if we are to produce _practical_
proposals, we are heavily constrained by what is already deployed, and
that limits the clarity of what we can do. Yes, with a clean-sheet design,
one could carefully and completely separate location and identity.
However, we do not have the luxury of a clean sheet; we can only
_start_ to move in that direction.
> The fact that local locators are often called "identifiers" does not
> help to understand what proposals actually do.
Differing definitions here are proving to be a problem. To me, anything
that can serve to identify one end of a TCP connection _cannot_ be a pure
'locator', as to me, locators name interfaces, not stacks.
Similarly, to me, anything which can identify one end of a TCP connection
is, by definition, an 'endpoint identifier'; it may have _other_
functionality as well, but its base functionality is that of an endpoint
identifier.
Again, due to TCP's past co-mingling of the concept of 'interface name' and
'endpoint name', we cannot (alas) get cystal pure 'locators' and 'endpoint
identifiers' in any design, _especially_ if we wish to support unmodified
hosts. So, IMO, trying to apply these pure, theoretical terms to actual
proposals is necessarily problematic...
Noel
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
