[ih] Why did location/identity separation not happen? (Was: Internet without entrenched factions?)

[Noel Chiappa]

    > From: Jack Haverty

    > The issues of location and identity that I first remember seeing were
    > in John Schoch's IEN in 1978

Jerry builds very heavily, and explicitly, on Shoch's work, in RFC-1498. The
big step foward that Jerry made there, to me, his careful separation of
classes of 'objects' (described/defined by their roles), and 'names' for them
- their nature/structure reflecting the use(s) to which they were put.

    > From: Dave Crocker

    > As a long-time, distant observer of this topic, I've been unclear about
    > the expected use of some constructs, and suspect I haven't been alone.
    > Compelling use cases often make the difference in garnering support,
    > and clarifying design requirements. ... Perhaps I've just missed the
    > both. But it seems clear I've had a lot of company.

Exactly; that is precisely why location/identity separation never caught on.

The thing is that one _can't_ forsee all the uses, and how having explicit
recognition/names of all the classes of objects will be a banefit. The future
is too complex to predict accurately. So one can't rely on cost/benefit
analyses, when doing long-term architectual planning. One has to accept that
if one has correctly listed all the classes of fundamental objects. and
introduced at least one namespace for each of them (others can be added
later), one will have a structure that can meet any future need. (In the same
way that having 'processes' can support pretty much any application.)

I will add here one of the thoughts which I left out of the previous message:
the effect of scaling on architecture (defined here as a set of object
classes, and the interaction between them). An architecture which works well
a one level of scale often won't work well at several orders of magnitude
larger. That's often because the 'smaller' one has cut a corner, and lumped
together two classes of objects. Which is why the Internet is having a hard
time supporting wide-scale multihoming; the mechanisms available, using the
objects supported when the network was small, aren't rich enough. Oh well.

(An example of this effect in operation with 'processes' is the addition of
'tasks'; 'processes' a la 1970's had too many things under one hat. Adding
tasks pulled one out.)

The thing is that in a communication network (where all the players have to be
basically the same, and share a set of semantics to communicate), one can't
dream up an improvement which is a _change_ to _existing_ stufff, and deploy
it piecemeal - as one can with an application, like an editor, where it can be
taken up in corners, locally.  Which is why ripping out the variable length
addresses of IPv3 (architecturally too poor as it was) for the shortish
fixed-length ones of v4 was a flaw the Internet has been unable to fix.

     > I've been less clear about the operational benefits of an additional
     > identifier at the datagram level.

By "at the datagram level", do you mean 'in packets'? If so, it's not clear
that identity-only names (e.g. endpoint IDs) would be in every packet.

This echoes a long-previous problem, when the programmers couln't wrap their
minds around the concept that there might be 'addresses' that _weren't_ in
every packet. That's why we had to invent 'locator' - although it's not clear
that the lesson took, as that term has since been redefined, to many, to mean
just 'a name with topological content embedded in it'. The original
definition was 'a name with topological content embedded in it _which does not
necessaily appear in every packet_'.

(And yes, I am aware that I am using "topology" with a meaning that's
different from the way mathematicians mean it. The networking field often
uses it to mean 'data-carrying connectivity structure'; I apologise for
hijacking "topology" to mean that, but I couldn't think of an existing term
with that meaning. I suppose I should have coined a new one.)

	Noel