From: Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
To: tuhs@minnie.tuhs.org
Subject: Re: [TUHS] OSI stack (Was: Posters)
Date: Sun, 3 Feb 2019 09:51:04 -0700 [thread overview]
Message-ID: <b7032957-3ee5-a786-6cb7-96f53e839c79@spamtrap.tnetconsulting.net> (raw)
In-Reply-To: <20190203150237.A869418C07A@mercury.lcs.mit.edu>
[-- Attachment #1: Type: text/plain, Size: 2204 bytes --]
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
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4008 bytes --]
next prev parent reply other threads:[~2019-02-03 16:51 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-03 15:02 Noel Chiappa
2019-02-03 16:51 ` Grant Taylor via TUHS [this message]
2019-02-03 23:33 ` [TUHS] Signal/noise (Was: OSI stack (Was: Posters)) Mantas Mikulėnas
2019-02-04 0:10 ` Arthur Krewat
2019-02-04 0:54 ` Grant Taylor via TUHS
2019-02-04 2:23 ` [TUHS] Signal/noise Warren Toomey
2019-02-04 2:37 ` Larry McVoy
2019-02-04 2:57 ` Bakul Shah
2019-02-04 3:26 ` Warner Losh
2019-02-04 3:26 ` Dan Cross
2019-02-04 4:55 ` Dave Horsfall
2019-02-04 6:20 ` Jon Steinhart
[not found] ` <CANCZdfq5PM9jFEi9=geC+CTnveXs5CprN7b+ku+s+FYzw1yQBw@mail.gmail.com>
2019-02-06 17:16 ` [TUHS] OSI stack (Was: Posters) Warner Losh
2019-02-06 17:23 ` Larry McVoy
2019-02-06 23:37 ` George Michaelson
2019-02-03 18:49 Norman Wilson
2019-02-04 20:29 Noel Chiappa
2019-02-04 21:13 ` Bakul Shah
2019-02-04 21:34 ` Clem Cole
2019-02-05 18:01 ` Grant Taylor via TUHS
2019-02-06 17:49 Noel Chiappa
2019-02-06 18:22 ` Paul Winalski
2019-02-06 20:47 ` Kevin Bowling
2019-02-07 18:07 ` Grant Taylor via TUHS
2019-02-07 18:22 ` Andy Kosela
2019-02-07 18:50 ` Larry McVoy
2019-02-06 23:18 Noel Chiappa
2019-02-06 23:40 ` Kevin Bowling
2019-02-06 23:52 ` Larry McVoy
2019-02-07 0:04 ` Kevin Bowling
2019-02-07 0:02 Noel Chiappa
2019-02-07 0:11 ` Kevin Bowling
2019-02-07 0:45 Noel Chiappa
2019-02-07 1:03 Noel Chiappa
2019-02-07 19:04 Noel Chiappa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b7032957-3ee5-a786-6cb7-96f53e839c79@spamtrap.tnetconsulting.net \
--to=tuhs@minnie.tuhs.org \
--cc=gtaylor@tnetconsulting.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).