Re: Terminology [Re: Some Comments on ID/Loc Separation Proposals]

[Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>]

Noel;

>     > From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
> 
>     >> could you provide a definition of what do you mean by end system?
> 
>     > As I searched reference of the RFC, "end point" seems to be an
>     > alternative wording of "end system" that if JNC is saying "endpoint"
>     > with the difinition of Saltzer's paper, that is fine.
> 
> Which Saltzer paper? "End-End arguments", or RFC-1498 (which is the paper
> that first pointed out that we needed to separate location and identity)?
> 
> In any event, there is a *significant* difference between my definition, and
> Saltzer's paper: he talks (basically) of hosts (i.e. physical boxes), whereas
> my "endpoint" definition is deliberately not tied to hardware.

Then, you must find another wording, though there is no point
insisting your point.

> This has the very important *practical* difference that at one particular
> location in the network (i.e. whether one thinks that our "location-names"
> name interfaces, or are topology-dependent names for end-things) one could
> conceivably find *more than one* end-thing - e.g. if a host contains (for
> whatever reason) two endpoints.

If end things are found at one particular location, which is
the *PRACTICAL* assumption, they share connectivity fate that
thier is nothing for M6 to worry about.

> If so, the packet needs to contain some
> disambiguator to allow deliver to the proper end-thing.

When a host has complex internal structure, feel free to something,
say, a port number, beyond a host address(es) for the disambiguation.

> Many schemes for doing location/identity separation don't provide this. E.g.
> naive versions of 8+8, where the lower 64 bits is just the IEEE number,
> don't. Whether it's an important engineering goal is not for me to say - I'm
> just pointing it out.

Be practical.

							Masataka Ohta