[TUHS] OSI stack (Was: Posters)

[Grant Taylor]

On 2/3/19 8:02 AM, Noel Chiappa wrote:
> Why? The details have faded from my memory, but the lower 2 layers of 
> the stack (CLNP and TP4) I don't recall as being too bad. (The real 
> block to adoption was that people didn't want to get snarled up in the 
> ISO standards process.)

I too am curious.  I've got no first hand experience.  (I'm not counting 
getting a couple of SimH VAXen talking to each other over DECnetIV.)

> It at least managed (IIRC) to separate the concepts of, and naming 
> for, 'node' and 'network interface' (which is more than IPv6 managed, 
> apparently on the grounds that 'IPv4 did it that way', despite lengthy 
> pleading that in light of increased understanding since IPv4 was done, 
> they were separate concepts and deserved separate namespaces).

I'm not quite sure what you mean by naming a node vs network interface.

But I do know for a fact that in IPv4, IP addresses belonged to the 
system.  Conversely, in IPv6, IP addresses belong to the interface. 
This has important security implications on multi-homed systems.

> Yes, the allocation of the names used by the path selection (I use that 
> term because to too many people, 'routing' means 'packet forwarding') 
> was a total dog's breakast (allocation by naming authority - the very 
> definition of 'brain-damaged') but TCP/IP's was not any better, really.

I don't understand what you mean by using "names" for "path selection". 
Or are you referring to named networks, and that traffic must pass 
through a (named) network?

That's probably why I don't understand how routes are allocated by a 
naming authority.

> Yes, the whole session/presentation/application thing was ponderous and 
> probably over-complicated, but that could have been ditched and simpler 
> things run directly on TP4.

I've seen various parts of session and / or presentation applied to IPv4 
(and presumably IPv6) applications.  Some people like to say that 
session is one of those two (arguments ensue as to which) grafted on top 
of the application layer.  So, even that's still there in the IP world, 
just in an arguably different order.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190203/6e7ddcc4/attachment.bin>