[comp.protocols.misc] OSI-model software

ps@diab.UUCP (06/03/87)

We are looking for a software package that implements the OSI-model
protocol levels 3(internet), 4(transport class 0,2,4), and 5(session)
in whole or parts. The software need not be a commercial product, or
even completely functional. If suitable, it will be a base for further
development. It is a requirement that the software could become the property
of this company (no licensing), on a non-exclusive basis with no restrictions
on it's future use or distribution.

Any hints are appreciated. Thanks in advance.
-- 
Per-Erik Sundberg,  Diab Data AB
SNAIL: Box 2029, S-183 02 Taby, Sweden
ANALOG: +46 8-7680660
UUCP: seismo!mcvax!enea!diab!ps

mac@idacrd.UUCP (06/04/87)

in article <223@diab.UUCP>, ps@diab.UUCP (Per-Erik Sundberg) says:
> Xref: idacrd comp.dcom.lans:459 comp.protocols.misc:22 comp.sources.wanted:1227
> 
> 
> 
> We are looking for a software package that implements the OSI-model
> protocol levels 3(internet), 4(transport class 0,2,4), and 5(session)
> in whole or parts. The software need not be a commercial product, or
> even completely functional. If suitable, it will be a base for further
> development. It is a requirement that the software could become the property
> of this company (no licensing), on a non-exclusive basis with no restrictions
> on it's future use or distribution.
> 
> Any hints are appreciated. Thanks in advance.
>


AHHHAAAA Ahhhaaa hahahahahaha   ahhhhh hahahahahaha ahhh hahahaha

Chuckle chuckle etc.

Bob
 

dpz@aramis.rutgers.edu.UUCP (06/04/87)

>From: mac@idacrd.UUCP (Bob McGwier)

>>We are looking for a software package that implements the OSI-model
>>protocol levels 3(internet), 4(transport class 0,2,4), and 5(session)

> AHHHAAAA Ahhhaaa hahahahahaha   ahhhhh hahahahahaha ahhh hahahaha
> 
> Chuckle chuckle etc.

Pretty friggin obnoxious.  Go play with your toys, unless you have an
intelligent answer for him.

						dpz
-- 
David P. Zimmerman           rutgers!dpz           dpz@rutgers.edu

steckel@alliant.UUCP (06/05/87)

Anyone contemplating using OSI protocols should read Padlipsky's comments
in the tcp-ip mailgroup (comp.dcom.tcp-ip I think).  He exposes far better
than I can the fundamental flaws in network protocols prescribed by PTTs
(national postal/telegraph/telephone monopolies) or other monolithic entities.
He has also published a book on the subject - suitable for making implementors
cry and standards committee members break out in flames.  (Sorry, I can't
remember the title but I could find out if enough interest)

OSI doesn't tell you how to make a network.  It only tells you how to
(supposedly) connect to a (supposedly perfect) network.  All OSI protocols
fall extremely short on error handling.  Even X.25, the closest to usable
of all the OSI protocols, has had several revisions because of this problem
and it's a low level!

Read Padlipsky and weep (or break into hysterical laughter!).
	geoff steckel (steckel@alliant.uucp, gwes@wjh12.uucp)

jmg@cernvax.UUCP (jmg) (06/05/87)

In article <233@idacrd.UUCP> mac@idacrd.UUCP (Bob McGwier) writes:
>in article <223@diab.UUCP>, ps@diab.UUCP (Per-Erik Sundberg) says:
>> We are looking for a software package that implements the OSI-model
>> protocol levels 3(internet), 4(transport class 0,2,4), and 5(session)
etc.
>> Any hints are appreciated. Thanks in advance.
>
>AHHHAAAA Ahhhaaa hahahahahaha   ahhhhh hahahahahaha ahhh hahahaha
>
>Chuckle chuckle etc.
>
>Bob
> 

May I say that this is the sort of inane reply which drives me wild.
It has no information in it, other than an implied snide comment.
Personally, I would prefer that Mr. McGwier thinks for a few microseconds
before issuing such a reply.

As it happens:-

1. I already sent off four names to the original sender, and there are
   certainly more.
2. We are currently running (and interworking with) three different
   ISO TP4 implementations (on Vax, 68000 and IBM PC).
3. The sender is not English mother tongue (although he speaks it
   probably rather better than most readers speak his language), and
   so is possibly upset by the answer.

nrh@chuck.bellcore.com.UUCP (06/06/87)

In article <526@alliant.UUCP> steckel@alliant.UUCP (Geoff Steckel) writes:
>Anyone contemplating using OSI protocols should read Padlipsky's comments
>in the tcp-ip mailgroup (comp.dcom.tcp-ip I think).  He exposes far better
>than I can the fundamental flaws in network protocols prescribed by PTTs
>(national postal/telegraph/telephone monopolies) or other monolithic entities.
>He has also published a book on the subject - suitable for making implementors
>cry and standards committee members break out in flames.  (Sorry, I can't
>remember the title but I could find out if enough interest)
>...
>Read Padlipsky and weep (or break into hysterical laughter!).
>	geoff steckel (steckel@alliant.uucp, gwes@wjh12.uucp)

Padilipsky's book is called "The Elements of Networking Style", and
is published by Prentice-Hall.

fair@ucbarpa.Berkeley.EDU.UUCP (06/07/87)

Followup-To:

I wish to echo the recommendation of Michael Padlipsky's book,
which is

	The Elements of Networking Style

	and other Essays & Animadversions on
	the Art of Intercomputer Networking

	Michael A. Padlipsky
	published by Prentice-Hall, 1985
	ISBN 0-13-268111-0 01

It is most frustrating to only be able to sit idly by while most of the
computer industry gives lip service to ISO vaporware, while a superior,
second generation protocol suite goes mostly ignored (unless the
customers have the sense to ask for it): DoD IP/TCP.

	Erik E. Fair	ucbvax!fair	fair@ucbarpa.berkeley.edu

mel1@houxa.UUCP (06/07/87)

In article <19265@ucbvax.BERKELEY.EDU>, fair@ucbarpa.Berkeley.EDU (Erik E. Fair) writes:
> It is most frustrating to only be able to sit idly by while most of the
> computer industry gives lip service to ISO vaporware, while a superior,
> second generation protocol suite goes mostly ignored (unless the
> customers have the sense to ask for it): DoD IP/TCP.

I am new to the field of networking and am getting very confused.  I
see lots of utility in the TCP/IP offerings and uses.  I was a user
of the ARPANET for many many years (without the slightest knowledge
about what was providing such great services).  I use an Ethernet in
our lab that connects dozens of systems from different venders and
opertaing systems.  Both work very reliably, relatively fast, and
duck simple to use.

What does ISO offer that TCP/IP doesn't?  Is it significantly faster?
I can't think of any other measure that needs improving.

Is there a war going on?  TCP/IP vs ISO?  Who is on which side?  Why?

   Mel Haas  ,  odyssey!mel

dyer@spdcc.COM (Steve Dyer) (06/07/87)

It's unfortunate that Padlipsky, in naming his collection of essays
"The Elements of Networking Style", seems to have eschewed all the
recommendations of its namesake, "The Elements of Style" by Strunk
and White.  Although there is some very good technical content in
the book, it is buried beneath a rambling, self-indulgent conversational
style which is very hard to read and follow.  Padlipsky makes a lot of
his deliberate decision to avoid "seriousness" in a technical book,
but that doesn't mean that it has to represent the worst of an engineer's
first drafts.

I wonder, too, how accessible much of the material is to newcomers--many
of the essays dive immediately into the details of NCP, the protocol suite
used on the ARPAnet before the introduction of TCP/IP.  When I was reading
it, I was glad that I had worked at BBN during the NCP/TCP transition where
I had to support both protocol suites--I had some context to work with.

This isn't to detract from its uniqueness -- it's practically the only 
book of its kind, written from the point of view of one of the original
ARPA designers.  But it helps if you read it as a kind of "oral history"
transcribed verbatim and manage to get past its idiosyncratic style.
-- 
Steve Dyer
dyer@harvard.harvard.edu
dyer@spdcc.COM aka {ihnp4,harvard,linus,ima,bbn,halleys}!spdcc!dyer

sas@pyramid.UUCP (06/07/87)

In article <492@houxa.UUCP> mel1@houxa.UUCP (M.HAAS) writes:
>What does ISO offer that TCP/IP doesn't?  Is it significantly faster?
>I can't think of any other measure that needs improving.

The following is my opinion:

The ISO stack, in its current state, offers significantly less functionality
than TCP/IP.  In particular, the virtual terminal protocol is not yet
completed.  What ISO does propose to offer (when completed) is:

	(1)	More heterogeneity via a more "complete" series of
		options to the basic functions.

	(2)	A solidification of the layering approach to communications
		protocols which would provide more intermingling
		of various services within a class of functionality without
		modification to the higher layers.  E.g., the ability to run
		a lean transport on top of a connection-oriented service
		(X.25) versus a more substantial transport on top of
		connectionless services (802.3).
	
	(3)	A suite of protocols not developed by the "bomb-crazed"
		American military.  Not that I want to bring politics
		into the picture but, like it or not, we're talking
		*international* standards.  The Europeans are very
		sensitive about the protocols which run over the
		PTT networks.  Anyone whose gone through the ordeal of
		an X.25 certification can attest to this.  An international
		standard not controlled by any one country (in fact one in
		which each country can select the options (see (2)) it
		prefers) would seem to be an ideal solution.
>
>Is there a war going on?  TCP/IP vs ISO?  Who is on which side?  Why?

More opinion:

I'm not sure I'd classify what appears to be taking place as a war.  It
seems to be more of a necessary sanity check on what's been produced by
the standards bodies.  I'm all for standards and computers that talk to
each other.  However, I'd like this to happen in a reasonably fast and
(from the host-standpoint) efficient manner.  Beyond the discussion over
incompleteness of the standards, there is a question of performance of
ISO implementations.  One of the more visible groups raising these questions
is the FDDI group.  If you'll recall, FDDI is a 100 Mbit/sec token bus
standard being developed by a subcomittee of ANSI.  An important question
is what happens when I suddenly improbe my bandwidth (in this case, an
order of magnitude) but my software only allows me to use a small portion.

In favor of ISO are the European PTTs and academic networks, the MAP/TOP
group, NBS and Corporation for Open Systems (COS), and the US Government
via the GOSIP spec.  It also appears that the ARPAnet may migrate to
ISO in an undetermined timeframe.

>
>   Mel Haas  ,  odyssey!mel

sas
----
Scott Schoenthal		        Pyramid Technology Corp.
pyramid!sas				Mountain View, California

sas@pyramid.UUCP (06/08/87)

In article <2923@pyramid.UUCP> sas@pyramid.UUCP (Scott Schoenthal) writes:
> [ ... ]  If you'll recall, FDDI is a 100 Mbit/sec token bus
							  ^^^

Ugh!  My mind said "ring" but my fingers typed "bus".  My apologies for
any confusion.

sas

ast@cs.vu.nl (Andy Tanenbaum) (06/09/87)

In article <492@houxa.UUCP> mel1@houxa.UUCP (M.HAAS) writes:
>What does ISO offer that TCP/IP doesn't?  Is it significantly faster?
>I can't think of any other measure that needs improving.
>
>Is there a war going on?  TCP/IP vs ISO?  Who is on which side?  Why?

The ISO OSI model is an attempt to provide a framework for networking from
the physical bit transport to the applications.  The model itself does not
contain protocols at all, although ISO has standardized some protocols and
services for the various layers.

TCP and IP are two specific protocols for layers 4 and 3, respectively, and
as such can be used to fill two of the slots in the OSI reference model.
Other protocols are needed for the other layers.

Virtually everyone now agrees that the OSI model is a good way to look at
networking.  The war is about which protocols which be used in which layer.
TCP is clearly one candidate for the transport protocol, but most
companies in the U.S., and virtually all companies outside the U.S. are
committed to supporting the ISO OSI transport protocol and the ISO protocols
in layers 5 through 7 too.  (1-3 are much fuzzier, what with IEEE 802 etc.)

There has been a lot of generalized disgust with OSI expressed here and
elsewhere.  I would be very interested in hearing specific comments about
  1. What is wrong with the OSI model itself.
  2. What is wrong with the specific protocols ISO has adopted.

Comments like: you can't go out and buy it off the shelf right now don't
count.  If the standards people waited until every company had already
had a running network product, they would all be different and there would
be no standard at all.  The only way to achieve standardization in this area
is to agree on the standards before every company invests a lot of money
doing it some nonstandard way.  Thus it is not surprising that the standards
are here before all the implementations.

Nevertheless, there are certainly plenty of valid criticisms of the model and
the protocols (e.g., the session layer is pointless, the presentation layer
is practically empty, they forgot about encryption altogether etc.).  I would
like to see a discussion of this subject, preferably by people who know what
they are talking about.

Andy Tanenbaum (ast@cs.vu.nl)

lamaster@pioneer.arpa (Hugh LaMaster) (06/09/87)

In article <1204@botter.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
>In article <492@houxa.UUCP> mel1@houxa.UUCP (M.HAAS) writes:
>>
>>Is there a war going on?  TCP/IP vs ISO?  Who is on which side?  Why?
>

>
>There has been a lot of generalized disgust with OSI expressed here and
>elsewhere.  I would be very interested in hearing specific comments about
>  1. What is wrong with the OSI model itself.
>  2. What is wrong with the specific protocols ISO has adopted.
>
>Andy Tanenbaum (ast@cs.vu.nl)

1) I would like to move this discussion to comp.protocols.iso

2) Unfortunately, the standards making bodies have appeared to those of us on
the outside to be dominated by two groups; the first group are European
telecomm monopolies who are indifferent to or actively hostile to
internetworking (e.g. Arpanet, milnet, nsfnet, many regional networks) between
LANs because it will reduce the tariffs they collect (they are right about
that); and, second, Certain U.S. Vendors who individually and collectively
have a financial interest in pretending to be interoperable while actually
trying to make it difficult for their customers to integrate multiple vendors
into a single network (they like captive customer bases of course, what
monopoly wouldn't?).  

3)  It is not an issue that not everything is implemented yet by all vendors;
it is an issue that absolutely essential protocols are not yet defined.  Until
there is a network virtual terminal specification, for example, the rest of
ISO is of limited utility.  You have to have the minimal set of specs first
before you can reasonably judge the protocols.  How can you be an "ISO
booster" before you have a complete protocol set to boost?  How can you expect
an internet user to accept the ISO protocols before internetwork address
resolution and routing are even defined? (Let alone published where the public
can see them.)

4)  The religious overtones from the ISO camp are also disturbing.  I don't
remember anyone ever laying religious stuff on me for the arpa protocols.
TCP/IP etc. spread from arpanet to the general user community because they
worked, and provided the facilities that people wanted.  It was that simple,
and that hard.  The ISO camp is trying to replace TCP/IP not with an
improvement in performance, reliability, features, or ease of integration.
Instead, some its proponents have resorted to forced baptisms.  Before the
things we are supposed to believe in are even defined.  It worries me.

5)  Because the ISO camp didn't bother to stop and consider the needs of the
LAN and internet communities, they have only recently begun to work on LAN and
internet features.  Real improvements over tcp/ip, such as new features like
multiple gateway dynamic routing and path load balancing, and real (layer by
layer) security, have not been worked on at all.  Is it possible to retrofit
real security into ISO at this point?  If it is, will it be possible to change
iso substantially, or will it be cast into concrete, warts and all?

6)  Therefore, I am afraid there are two warring camps at this point.  The
TCP/IP camp is looking for better service, and the iso camp has its (somewhat
hidden) agenda which is quite different.  This is not to say that anyone
working on defining or implementing iso is a bad person.  Some of the nicest
people are.  The solution, from my perspective, is for the iso camp to mature
sufficiently that technical considerations override the (current) political
considerations.  In the meantime, I hope that some mechanism by which user and
small vendor input into iso can be developed.  Why isn't there anything like
the RFC mechanism for iso?  Perhaps comp.protocols.iso should spin off
rfc.protocols.iso (moderated, of course) and the results forwarded to the
standards bodies.

7)  Finally, this is not a flame on all the hardworking people who have tried
to make the iso protocol suite more suitable for LANs and internets.  I don't
know who most of you are, but I know sitting on standards committees is tough
work. 





  Hugh LaMaster, m/s 233-9,  UUCP {seismo,topaz,lll-crg,ucbvax}!
  NASA Ames Research Center                ames!pioneer!lamaster
  Moffett Field, CA 94035    ARPA lamaster@ames-pioneer.arpa
  Phone:  (415)694-6117      ARPA lamaster@pioneer.arc.nasa.gov

"In order to promise genuine progress, the acronym RISC should stand 
for REGULAR (not reduced) instruction set computer." - Wirth

("Any opinions expressed herein are solely the responsibility of the
author and do not represent the opinions of NASA or the U.S. Government")

lamaster@pioneer.arpa (Hugh LaMaster) (06/10/87)

In article <2923@pyramid.UUCP> sas@pyramid.UUCP (Scott Schoenthal) writes:


(Paraphrase: "ISO offers the following:")

>	
>	(3)	A suite of protocols not developed by the "bomb-crazed"
>		American military.  Not that I want to bring politics
>		into the picture but, like it or not, we're talking
>		*international* standards.  The Europeans are very
>		sensitive about the protocols which run over the
>		PTT networks.  Anyone whose gone through the ordeal of

This "argument" I thought was a joke, at first.  "You have got to be kidding."
The sad truth is that I have actually heard ISO proponents use it.  Did you
know that modern canning was invented for Napoleon's army (to invade other
countries, where supplies and logistics were a problem) and was used primarily
for military food supplies for its first sixty years or so?  So I guess we
shuldn't use canned food.  If there are any pacifists reading this, I might
suggest that "swords into plowshares" might be a better approach.  Use the
protocols for peaceful purposes.  My sources tell me that, unfortunately,
"they" are much more worried about "uncontrolled" traffic which flows outside
"their" networks.  It is just hard to talk about this "problem" in public, so
other arguments must be used.  Sounds like material for talk.politics to me.
Add a healthy dose of "Not invented here" (NOBODY has a monopoly on NIH), plus
some unscrupulous computer vendors ("We have ISO, see, seven layers") and you
have a mess for the technical grunts to straighten out.  Too bad; it didn't
have to be this way.


  Hugh LaMaster, m/s 233-9,  UUCP {seismo,topaz,lll-crg,ucbvax}!
  NASA Ames Research Center                ames!pioneer!lamaster
  Moffett Field, CA 94035    ARPA lamaster@ames-pioneer.arpa
  Phone:  (415)694-6117      ARPA lamaster@pioneer.arc.nasa.gov

"In order to promise genuine progress, the acronym RISC should stand 
for REGULAR (not reduced) instruction set computer." - Wirth

("Any opinions expressed herein are solely the responsibility of the
author and do not represent the opinions of NASA or the U.S. Government")

kre@munnari.UUCP (06/10/87)

In article <1724@ames.UUCP>, lamaster@pioneer.arpa (Hugh LaMaster) writes:
> 1) I would like to move this discussion to comp.protocols.iso

Be careful here, comp.protocols.iso is an internet group (a cheap
way of transporting the mailing list over the internet), it doesn't
reach out into most of usenet.  It probably should.  Since usenet
is all about networking, and iso is standardising exactly that,
this is one topic that all usenet should be able to see.

> Until there is a network virtual terminal specification, for example,
> the rest of ISO is of limited utility.

You're right, that one is lagging behind (and started late), probably
largely because X.29 (as revolting as it is) was seen as serving
adequately enough (which it doesn't outside the x.25 world).

> The solution, from my perspective, is for the iso camp to mature
> sufficiently that technical considerations override the (current) political
> considerations.

No, this is all backwards, strange as it may seem.  The whole purpose
of standardisation is for political considerations to override the
technical ones.  And no, I'm not being cynical.  The absolute essential
for a standard is for everyone to agree with it, and getting everyone
to agree means lots of compromises.  (Just consider Sun with NeWS and X).

There's absolutely no hope of a technically perfect standard, especially
not in any area where there's any dispute about what is perfect.

This isn't to say that the standards bodies don't aim to formulate a
standard as technically good as they can, but that *must* come second
to getting the necessary agreements, from the whole world.

> Why isn't there anything like the RFC mechanism for iso?

There is: they're the working papers, draft standards, etc.
What they're not is free.  Nor are they even cheap.  However
you can easily obtain copies (contact ANSI in the US).  The
documentation isn't free, as this is how ISO largely finances
its activities .. ie: selling those bits of paper largely
pays for the secretarial work that goes into creating them
(most of the cost of the technical work is contributed by the
members of the working groups, or their employers, but I believe
that some of this comes from ISO funds as well).

Robert Elz

fwb@siemens.UUCP (Frederic W. Brehm) (06/10/87)

[I removed comp.protocols.iso because postnews could not find the group!]

In article <1726@ames.UUCP> lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) writes:
>In article <2923@pyramid.UUCP> sas@pyramid.UUCP (Scott Schoenthal) writes:
>
>(Paraphrase: "ISO offers the following:")
>
>>	(3)	A suite of protocols not developed by the "bomb-crazed"
>>		American military. ...
>
>This "argument" I thought was a joke, at first.  "You have got to be kidding."
>The sad truth is that I have actually heard ISO proponents use it.  ...

I have heard it used (but without the "bomb-crazed" phrase) by TCP/IP
opponents who would use ANYTHING, no matter how terrible, as long as it is
not TCP/IP.  I don't understand this attitude.  TCP/IP is a useful suite of
protocols readily available for many machines from many vendors with good
support.

I hope that the ISO suite of protocols matures soon so that I can buy the
functionality I need without fighting political wars.

Fred
----------------------------------------------------------------------------
Frederic W. Brehm		Siemens Research and Technology Laboratories
105 College Road East		Princeton, NJ 08540	(609) 734-3336
uucp:	ihnp4!princeton!siemens!fwb or astrovax!siemens!fwb
CSNet:	fwb@siemens.siemens-rtl.com

mel1@houxa.UUCP (06/11/87)

Thanks to all who supplied comments to my questions on OSI vs
TCP/IP.  Unfortunately, none supplied answers.

When I refered to OSI vs TCP/IP, I was just using those labels for
the whole class of communications capability, not just the OSI
reference model vs the TCP/IP layers of the DOD network.

Several replys presented the theme that large corporations and
government agencys "supported", "endorsed", or "were committed to"
the OSI/ISO standards.  I don't know what that means.  In most cases
the organizations mentioned market products or install systems that
provide similar functions using quite different protocols.  Am I off
base in believing that those actions represent just the opposite of
support, endorsement, and commitment?

Several replys mentioned a variety of different protocols for some of
the ISO layers.  How does that fit the concept of a "standard"?  Is
this 1984 "double speak"?

I am just a user of already deployed interconnected networks that use
a truly fantastic variety of computer systems, hardware, and
connection media all based on TCP/IP (with rcp, rsh, rlogin, ftp,
telnet at the top for most UNIX users; and goodness knows what on the
bottom to actually connect in).  Isn't this whole stack already a
standard (with an existance proof)?  What is the replacement for all
this?  What does the replacement offer as an inducement to switch?

The TCP/IP people have a very active newsgroup discussing technical
details of the protocol.  I don't understand any of it, but find it
quite amazing that there is still growth, discussion, and willingness
to learn and change so many years into the life of the product.  Or,
is this just an indication that the wonders I see are held together
with bailing wire and string?  Does ISO/OSI have such an activity?

   Mel Haas  ,  odyssey!mel

sas@pyramid.UUCP (Scott Schoenthal) (06/11/87)

In article <1204@botter.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
>There has been a lot of generalized disgust with OSI expressed here and
>elsewhere.  I would be very interested in hearing specific comments about
>  1. What is wrong with the OSI model itself.
>  2. What is wrong with the specific protocols ISO has adopted.
>
> [ ... ]
>
>Nevertheless, there are certainly plenty of valid criticisms of the model and
>the protocols (e.g., the session layer is pointless, the presentation layer
>is practically empty, they forgot about encryption altogether etc.).  I would
>like to see a discussion of this subject, preferably by people who know what
>they are talking about.
>
>Andy Tanenbaum (ast@cs.vu.nl)

I believe that Andy knows what he is talking about and I would certainly
be interested if he would expand on the criticisms he mentions in his posting.

While I did refer in an earlier posting to the political aspects of adoption
of an international standard (the phrase '"bomb-crazed" American military'
was an impetuous addition which I now regret), I believe that we should
consider here (or hopefully in a comp.protocols.iso) mainly the technical
issues of the ISO/OSI model and protocol definition and implementation.
Hopefully, this could include MAP/TOP specific protocols (e.g., Directory
Services, Network Management) and relevant CCITT protocols (e.g., X.400)
as well.

sas
----
Scott Schoenthal		        Pyramid Technology Corp.
pyramid!sas				Mountain View, California

karn@faline.UUCP (06/13/87)

In article <1204@botter.cs.vu.nl>, ast@botter.UUCP writes:

> Virtually everyone now agrees that the OSI model is a good way to look at
> networking.  The war is about which protocols which be used in which layer.

About the only thing virtually everybody agrees on is that hierarchical
layering is usually a good idea in a computer communication network. 
The ISO Reference Model (not so fondly called "eyesore-emm" by
Padlipsky) is only one of several possible hierarchical models, and a
rather outdated one at that.

Among the major flaws of the ISO Reference Model are:

1. A fixed number (7) of layers. In a real network there may well be
more or less than 7 layers. The important thing is the relative position
of a protocol in the hierarchy and the function it performs, not the
fixed "level x" designator it might have.  Jon Postel and Danny Cohen
wrote a paper a few years ago in which they examined some real
networking systems and showed that either a) N = N + 1 (for any value
of N), OR b) the notion of "seven and only seven layers" is
fundamentally flawed.

2. It completely ignores internetworking. This is related to point #1,
since in a real internetwork you may very well have two or more network
layers in a "stack", e.g., a subnet layer underneath an internet layer.
(Some people do split ISO Layer 3 into Layer 3A, the Subnet layer, and
Layer 3B, the Internet layer.)  The fact that the model still doesn't
formally recognize the very real existence of and need for internetworking
says something about the motivations of those who influence the ISO.

3. Overly redundant layer functionality. My pet peeve is the use of the
term "reliable" in the link layer description, implying that the primary
burden for reliable delivery of information rests here instead of the
transport layer where it belongs. No other concept has contributed so
much to needless complexity, inflated costs and lousy performance than
the stubborn notion that each and every layer must "guarantee"
reliability, usually through the use of an overhead-laden connection-
oriented protocol.

A decade ago this mentality brought you X.25.  Now it has resurfaced in
an even more astonishingly byzantine creation, "IEEE 802.1 Connection-
Oriented Logical Link Control" (basically X.25 over Ethernet, believe
it or not). For more on the general subject of end-to-end vs low level
reliability mechanisms, see "End-to-end Arguments in System Design" by
Jerome Saltzer of MIT.

4. While important concepts are ignored, another layer exists whose
function is questionable at best: the Session layer. I've yet to figure
out just what it's supposed to do, and why a separate layer is needed to
do it.

5. While not a fault of the ISO RM per se, some of its overly zealous
followers (whom Padlipsky also not-so-fondly refers to as ISORMites,
pronounced "eyesore mites") tout it as *the* way a network *must* be
built. Even the originators of the ISORM never intended it as anything
other than as a general guide to *naming* the pieces of *existing*
networks. For example, I've had people tell me that I can't have a
"network" without a separate Session layer, even though TCP and UDP have
perfectly adequate port numbering and "well known socket" mechanisms.
When I ask why, they say "ISO says so".

In addition to the faults of the underlying reference model, the ISO/OSI
"protocol suite" has a host of faults of its own.  First and foremost
among them is the fetish for connection-oriented protocols. Only
recently did a connectionless transport protocol get added, despite
the widespread use of UDP in the ARPA Internet for things like network
databases and distributed file systems. On the other hand, there are a
FIVE different and mutually incompatible  protocols all providing a
connection-oriented transport service (TP-0 thru TP-4). If the ISO was
*really* serious about "open systems interconnection", they would pick
ONE connection-oriented transport protocol (TP-4, the most general one).
They claim you don't need all that reliability if you're running on a
PTT network, but of course the real reason is that they're scared to
death of internetworking. There's no way a PTT is going to allow it to
happen unimpeded.

Yes, eventually you may be able to pick a "subset" of the ISO stack that
answers the needs of the internetworking world. But if you do, you end up
with something that is similar to, but (deliberately) incompatible with
TCP/IP. So why bother?

In summary, if you think open systems interconnection is a good idea, I
agree. That's why I and so many others use TCP/IP. I have nothing
against migrating to an international standard if it is provably
superior to what we have (e.g., the metric system vs the English system)
but this is *not* the case with OSI in its present form.  I also dislike
the "bomb crazed military", but I also see no reason not to take their
technology and beat it into plowshares.  In fact, it gives me a real
feeling of satisfaction to take military technology and pervert and
subvert it to peaceful uses!

Phil

samlb@well.UUCP (06/14/87)

	It occurs to me that the reason for including the concepts "Session" 
and "Connection" in the ISO/OSI model is precisely because PPTs are accustomed
to charging by the (name your time unit) for a connection between two points.
(i.e. DM0,45/minute from Frankfurt-am Main to Bad Nirgensplatz, Bavaria)
	It is easier to machine titanium than to try to change bureaucratic
ideas (sic) of "the way the world really is -- and should be"!	
-- 
Sam'l Bassett, Semantic Engineer -- My words & ideas are for sale!
34 Oakland Ave., San Anselmo  CA  94960;  (415) 454-7282
UUCP:  {...known world...}!hplabs OR ptsfa OR lll-crg!well!samlb;
Compuserve:  71735,1776;  WU Easylink ESL 6284-3034;  MCI SBassett

martillo@bloom-beacon.UUCP (06/15/87)

Just a note on X and NeWS.

NeWS is a postscript based graphics system for high resolution
graphics devices which can be used to provide windows.

X is a window system which has some graphics primitives.  

They are not comparable as alternate standards in view of the underlying
mechanism or design or philosophy.

The question is whether window systems should be implemented on top of
graphics systems or whether graphics systems should be built on
graphics systems.  It maybe partially a religious issue (but I suspect
not because virtualizing a raster device on top of a raster device
makes sense to me while virtualizing a raster device on top of a
graphics system on top of a raster device seems to introduce an
extralevel of complexity) but Adobe has announced that it will
implement postscript on top of X.

karn@faline.UUCP (06/15/87)

> 	It occurs to me that the reason for including the concepts "Session" 
> and "Connection" in the ISO/OSI model is precisely because PPTs are accustomed
> to charging by the (name your time unit) for a connection between two points.
> (i.e. DM0,45/minute from Frankfurt-am Main to Bad Nirgensplatz, Bavaria)
> 	It is easier to machine titanium than to try to change bureaucratic
> ideas (sic) of "the way the world really is -- and should be"!	

I often say that the reason the PTTs are so anti-datagram is because
without connections, there's no way to charge for connect time.  I used to
think I was joking; not any more.

Phil

ken@rochester.UUCP (06/16/87)

|I often say that the reason the PTTs are so anti-datagram is because
|without connections, there's no way to charge for connect time.  I used to
|think I was joking; not any more.

Not all PTTs are so anti-change. Several years ago Telecom Australia
announced Austpac, a datagram service to be charged by the octet. Don't
know if it took off though.

Analog to digital converters and digital switching technology offer
unification of voice and data handling.  A generation of managers used
to SxS or crossbar technology may resent digital. Then again upgrading
to digital while maintaining compatibility is not an easy job.

	Ken

ast@botter.UUCP (06/17/87)

In article <3002@pyramid.UUCP> sas@pyramid.UUCP (Scott Schoenthal) writes:
>I believe that Andy knows what he is talking about and I would certainly
>be interested if he would expand on the criticisms he mentions in his posting.

Ok.  For one thing, I think the session layer is ridiculous.  All it really
does is keep track of whose turn it is to talk and do some checkpointing.
I think most applications know whose turn it is to talk.  If I am addressing
an editor on a remote machine, we really don't need a whole layer to keep
track of whether I am allowed to type or it is the editor's turn to say
something.  In the British proposal to ISO years ago, there was no session
layer.  I think they were right.  The session layer was probably included
because IBM had one, and people must have assumed that if IBM did it, it
must be a good idea.  I am not convinced that there are enough applications
that use the session layer to make it worth having.   The ARPANET model
does not have any session layer and I have never heard of anyone saying he
needed it.

The presentation layer.  It is practically empty now.  All that seems to be
left is ASN.1 and ASN.2, which are several hundred pages of mumbo jumbo
for the purpose of telling which order the bytes are in (VAX, Intel = little
endian) vs. (68000, IBM 370 = big endian).  This seems overkill to me.

Encryption.  ISO seems to be totally unable to get its act together.  Other
than unambiguous statements that encryption does not belong in the session
layer or physical layer, it seems that all others are possible, although
lately I have been hearing noises that maybe presentation is "in" again.
I think spreading it out all over the place is a disaster.  Logically I
think it belongs in presentation--it deals with "meaning" in some sense.
In any event, the current situation is a disaster.

Andy Tanenbaum (ast@cs.vu..nl)

karn@faline.UUCP (06/18/87)

In article <1214@botter.cs.vu.nl>, ast@botter.UUCP writes:
> Encryption.  ISO seems to be totally unable to get its act together.  Other
> than unambiguous statements that encryption does not belong in the session
> layer or physical layer, it seems that all others are possible, although
> lately I have been hearing noises that maybe presentation is "in" again.
> I think spreading it out all over the place is a disaster.  Logically I
> think it belongs in presentation--it deals with "meaning" in some sense.
> In any event, the current situation is a disaster.

I think there are some good reasons for encrypting at more than one
layer.  End-to-end encryption is the most effective way to keep a
message's contents private, especially if you want to use any available
network (e.g., a PDN), since nothing in the network need be trusted.
There is probably something to be said for encrypting anything that the
network doesn't absolutely have to have to do its job, so you might as
well encrypt the transport header as well.  In other words, encrypt
on an end-to-end basis on the interface between L3 and L4.

However, end-to-end encryption doesn't protect you against traffic
volume analysis by someone outside the network monitoring its links, so
encryption on a per-link layer is still necessary. The only remaining
threat then becomes traffic analysis from within the network itself.
This is virtually impossible to prevent since the network must have
readable addresses in order to do its job; about the only thing you can
do is generate lots of garbage traffic to random destinations to spoil
their statistics -- IF you happen to have money to burn (i.e., work for
NSA).

You could go further and build a hierarchy of networks with encryption
in each.  For example, you could build a TCP/IP Internet where the
gateways use X.25 public networks (possibly having internal encryption)
to pass encrypted IP datagrams which themselves contain end-to-end
encrypted TCP data segments. A dishonest subnet could then only analyze
a fraction of the total Internet traffic, and those observations would
be much less precise because of the (hidden) multiplexing and routing
changes going on at the IP layer. It is entirely possible that one of
the unstated reasons for DoD's insistence on datagrams is to allow
"gratuitous rerouting" (i.e., route changing not necessitated by link
failures or congestion). This would be yet another technique to foil
traffic analysis attempts at the lower layers.

So redundant encryption still makes sense, so that the lower the layer,
the less trusted its components have to be.

Phil

aweinste@Diamond.BBN.COM (Anders Weinstein) (06/18/87)

I thought that the OSI Session layer was derived from the CCITT Teletex
protocol (S or T.62). I believe most of the OSI Session-layer operations are
just Teletex session functions couched in more abstract terms, ie.
"activities" correspond to Teletex "documents", OSI synch points correspond
to pages, etc.

Not that this makes it a good idea or anything...

howard@cos.UUCP (06/19/87)

In article <1214@botter.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes:
> In article <3002@pyramid.UUCP> sas@pyramid.UUCP (Scott Schoenthal) writes:
> >I believe that Andy knows what he is talking about and I would certainly
> >be interested if he would expand on the criticisms he mentions in his posting.
> Encryption.  ISO seems to be totally unable to get its act together.  Other
> than unambiguous statements that encryption does not belong in the session
> layer or physical layer, it seems that all others are possible, although
> lately I have been hearing noises that maybe presentation is "in" again.
> I think spreading it out all over the place is a disaster.  Logically I
> think it belongs in presentation--it deals with "meaning" in some sense.
> In any event, the current situation is a disaster.
> 

The reason encryption can be defined in multiple layers is that encryption
is used for different purposes in different layers.

The usual view of encryption is that it is intended for protecting
information from viewing by unauthorized readers.  This is not always
true; disclosure of contents in, for example, many financial applications
is no major threat, but real problems could be caused by replaying
legitimate information.  It can be appropriate to encrypt the message
number part of a credit authorization message.

Protection from duplication/replay, sender authentication, avoidance
of repudiation of reception (e.g., registered letters), all are reasons
to encrypt in the application layer.

Transport-layer encryption protects message contents on an end-to-end
basis.  If encryption is done at the transport or presentation layers,
however, message headers must be in clear (or a different cryptosystem)
so that the network and data link layers can extract information
needed to route messages.  In some applications, such as tactical
military systems, it can be important to protect against traffic
analysis:  gaining information by knowing how much traffic, at what times,
are being sent from one endpoint to another.

To protect against traffic analysis, the link level must be encrypted
or physically protected.  Again, this is only needed if traffic analysis
is a concern, or, if for administrative reasons, it's easier to distribute
encryption keys on a link-by-link rather than end-to-end basis.

nguyen@amd.UUCP (06/20/87)

In article <1214@botter.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes:
> In article <3002@pyramid.UUCP> sas@pyramid.UUCP (Scott Schoenthal) writes:
> >I believe that Andy knows what he is talking about and I would certainly
> >be interested if he would expand on the criticisms he mentions in his posting.
> 
> Ok.  For one thing, I think the session layer is ridiculous.  All
it really ...

	I don't think this comment is neccessarily constructive.  It
is too early to remove the session layer altogether from the ISO's
OSI.  The development for most upper layers protocols has not proved
maturity for everyone to accept as standards and NO ONE really know
what all layers have to be in the future.  There are ton of
different applications which can exist in all kinds of networks. 
Who knows?...
	I would rather have a null layer to by pass so I can
reconfigure the adjacent interfaces when the 'null' is no longer
necessarily empty later.  Some one proved that the session layer is
not null (such as IBM) must have a very good reason for it! As we
all know that most network layer implementation are null!!!. This
doesn't seem to hurt any body.

Quinn Nguyen

kre@munnari.UUCP (06/20/87)

In article <638@faline.bellcore.com>, karn@faline.UUCP writes:
> Among the major flaws of the ISO Reference Model are:
> 
> 1. A fixed number (7) of layers.

These are just conceptual layers, and they don't (and aren't mean to)
include layers in application processes.

You can recursively redefine any of those layers as much as you like
for whatever purposes are appropriate (eg: level 2 on lans has
llc and mac, but its all still level 2 .. point to point).

> 2. It completely ignores internetworking.

This is rubbish.

> They claim you don't need all that reliability [TP4] if you're running on a
> PTT network, but of course the real reason is that they're scared to
> death of internetworking. There's no way a PTT is going to allow it to
> happen unimpeded.

I think your arguments about PTT fears need a little examination.  Most
of the world's PTT's don't need standards to control the world's networking
(this is outside the US).  In most countries the PTT's have a legal
monopoly, they don't need this kind of extra second hand pseudo-protection.

I have no love for PTT's and their regulations, however before discounting
all their arguments, its worth placing yourself in their position for
a while.  Let's indulge in a little whimsy.

Imagine yourself offered the job of director general (or whatever
its called) of the arpanet (and nsfnet, span, csnet, etc for fun).
You're naturally overjoyed, as quite apart from the 6 (or perhaps 7)
figure salary, you're finally going to be able to stamp out all this OSI
nonsense on the arpanet, and get things finally back on the straight and
narrow of TCP/IP.

So far, so good, everything's running smoothly, until one day there's
a rash of "hacker" breakins at military institutions doing weapons
research, and evidence is that this comes from the educational (research)
side of the net .. the part you are in control of.  Big stink in the
press, congressmen up in arms, the lot.  Of course, no-one suggests
that OSI would have been any better (that's not my point).

But, finally someone raises a question... the US goverment (the taxpayer)
is paying for these hackers to wreak havoc on the US national security, Why?
This must be stopped at once.  In one of those amazing happenings in the
US congress and Senate a bill is passed, and receives Presidential assent,
all within a day.  It denies any goverment funding to the networks.  Not
only direct funding, but indirect funding through research grants, contracts,
etc, and denies tax deductions for gifts to any organizations that use any
of the gift for networking purposes.  Congress is really mad!

Now, you have something of a problem.  Here you are in charge of this
network that has no money, and the bills are starting to come due.
How are you going to solve this problem?  You can try and get people
to donate funds out of the goodness of their hearts, but somehow I
doubt that is going to work.  You're likely to have to reach the position
where you have to actually charge real money to the people who use
your networks.

You're more or less in the position of the PTT's in the rest of
the world, you're running a business, and you have to at least
break even, if not make a profit, or your network collapses.

It might be instructive to explain how, with the current internet
setup, and using the standard IP based protocols (which of course you
have the authority to change if you want) you are going to make
all this work.  Nb: I mean the whole internet here, including all
those sites that have slip, and csnet x.25, links to the lucky few
on net 10.

> I have nothing
> against migrating to an international standard if it is provably
> superior to what we have (e.g., the metric system vs the English system)
> but this is *not* the case with OSI in its present form.

You're right, OSI is not ready for use yet, it needs some more
work (though many of the individual protocols are perfectly ok).
But asking for it to be provably superior is asking too
much.  It might never achieve that in the sense you mean.
What it will be is demonstrably more widely available.

That is, one day you will be able to connect to us (in Australia)
using OSI.  Chances are you never will be using TCP.  Which is strange,
as we run TCP now, so do you.  Neither of us runs OSI...  (But the
US government won't allow us to connect to you using TCP, we would
have to get some special dispensation to allow packets from outside
the US onto the arpanet, and that's simply not worth bothering with).
We could set up some direct TCP link (possibly over an X.25 carrier...,
it would certainly be over some PTT carrier, as that's all that's
available) but then you would have to take special precautions to
make sure none of our packets escape.  What great internetworking!

Remember that continually bemoaning the lack of readiness of the
ISO protocols does nothing to help them get completed.  You'd be
better assisting ISO, I know that you have lots of TCP knowledge,
you must have plenty of experience that would be quite valuable,
and perhaps you could be helping to prevent some of the mistakes
that you see ISO making, instead of just complaining about them.

kre

ps: Phil .. mail to you on the backbone list is being addressed to
bellcore!bellcore.com!karn (or something similar) and is making
bellcore's mailer dump core (SIGSEGV), you might want to look into that.

kre@munnari.UUCP (06/20/87)

In article <354@sol.ARPA>, ken@rochester.arpa (Ken Yap) writes:
> Several years ago Telecom Australia
> announced Austpac, a datagram service to be charged by the octet. Don't
> know if it took off though.

Not like that it didn't .. Austpac exists, but charges the same way
essentially all other X.25 networks do, by segment (1 .. 64 octets)
and by time.

Incidentally, the x.25 nets that charge by segments (and time) are
generally much cheaper than the odd one that charges by octets, as
long as you're rational in your use of the resources .. if you send
1 character packets, you lose big, but so you should, those things
(on any network) are very wasteful of resources.

kre

samlb@well.UUCP (Samuel B. Bassett) (06/21/87)

	Harrumpf!

	The process of achieving _reliable_ communication over a network is
difficult enough.  _Secure_ communication is a whole order of magnitude
more work, and should be left to the spooks -- when they _really_ need it,
they will provide it on their own lines, and in their own formats.

	As I understand it, the purpose of the various layers should be to
insure that a proper package is wrapped around the "data" that each layer
receives from the next 'higher' layer, so that the (otherwise unexamined)
contents of the data get where they are expected to go, and can be interpreted
correctly when they get there.  The contents of the data at each stage can
be 'plaintext' or 'cryptext' -- the protocol handler should not care one way
or the other.

	Let's not complexify the situation out beyond the state of the art!
-- 
Sam'l Bassett, Semantic Engineer -- My words & ideas are for sale!
34 Oakland Ave., San Anselmo  CA  94960;  (415) 454-7282
UUCP:  {...known world...}!hplabs OR ptsfa OR lll-crg!well!samlb;
Compuserve:  71735,1776;  WU Easylink ESL 6284-3034;  MCI SBassett

howard@COS.COM (Howard C. Berkowitz) (06/23/87)

In article <933@bloom-beacon.MIT.EDU>, martillo@athena.mit.edu (Yakim Martillo) writes:
> In article <8613@amdahl.amdahl.com> chuck@amdahl.UUCP (Charles Simmons) writes:
> >In article <920@bloom-beacon.MIT.EDU> martillo@athena.mit.edu (Yakim Martillo) writes:
> >>IEEE 802.2 and ISO level 2 puzzle me as well.  These are protocols for
> >>the communications subnet and I don't quite understand why IEEE and
> >>ISO are trying to define communications subnet protocols for all time.
> >>Shouldn't communications subnet protocols be medium-dependent?
> 
> >Actually, if you look closely at 802.2, you'll notice that the IEEE
> >defines an interface within the datalink layer.  802.2 defines
> >the logical link control layer, and is, and should be, medium-independent.
> >Underneath the logical link control layer there exists a medium
> >access control layer which is, naturally, highly medium-dependent.
> 
> No, this is incorrect because the supposedly medium-independent part
> of the level 2 (logical link control) is basically a member of the
> X.25 level 2 like family of protocols.  These protocols make or
> enforce some very specific assumptions about the medium and how you do
> networking.  They assume you really want to establish a perfect
> virtual wire at level 2 on a relatively noisy telephone-line-like
> medium and that you either never do internetting or will do so at the
> cost of some very complicated flow control procedures.  They also
> assume you will not have transmit windows at higher protocol layers.
> 

NO to the No!  There are several classes of Level 2 LLC (Logical
Link Control; IEEE 8802/2).  Type I is connectionless and does not
                                       ^^^^^^^^^^^^^^          ^^^
try to provide a "perfect virtual wire;" it is significantly different
from the LAP-B HDLC-style link protocols used for the X.25 family,

LLC Type I has been adopted as the media-independent part of 
LAN-environment Layer 2 by the NBS OSI Implementors' Workshop
(for 802.3 CSMA/CD and 802.4 Token Bus Media Access Control),
by the MAP/TOP User Group for 802.3 and 802.4, and by the 
Corporation for Open Systems (for 802.3, 802.4, and 802.5 Token 
Ring).  By contrast, COS adopted ISO 7776 as the link control
layer for X.25 WAN applications, another example of how practical OSI
protocol stacks do not require only one protocol at each layer.
> 
> This family of protocols was developed for the PTTs which have a very
> specific type of medium and have some very specific constraints on the
> type of services they can provide and on the type of services which
> they want to provide.  The PTTs consider remote terminal sessions and
> file transfer to constitute the full range of data communications for
> computers.

In the worldwide environment, the view of PTT's cannot be
ignored.  The challenge is interfacing the LAN and WAN
environment in the real world, which has political,
regulatory, and economic constraints as well as technical
ones.

PTT's doing packet work are apt to be more amenable to data
concerns than "old-line" telephone operating companies,
who believe real men do it in 4 kilohertz analog channels
implemented on twisted pair.

There is hope, however.  A few months ago, I presented
COS' current activities to ANSI Committee T1, which is
the main telecommunications standards body for the U.S.
I reminded them that about three years previously, I had
been on the T1 task force concerned with developing the
workplan for performance/quality of service standards.
At that meeting, an old time telephony standards man
took me to task about not really understanding how it
all worked; that I was up in the theoretical stratosphere
of X.25.

At the T1 meeting recently, I found that same old-timer
in the bar, complaining how his customers "didn't 
understand what their software told them; that they
simply didn't understand retransmission algorithms in
X.25."

I pointed out that in three years, our telephony pioneer
had moved from below Layer 0 of the OSI Reference Model
into Layer 2.  I predicted that in 1993, he would be
a UNIX hacker developing OSI applications, and we OSI
people would have moved into another dimension.

(Further discussion on last point to rec.sf-lovers,
please.  Comments that OSI people already are in
another dimension will be routed, using IP if
you like, to /dev/null.).
-- 
-- howard(Howard C. Berkowitz) @cos.com
 {seismo!sundc, hadron, hqda-ai}!cos!howard
(703) 883-2812 [ofc] (703) 998-5017 [home]
DISCLAIMER:  I explicitly identify COS official positions.

ast@cs.vu.nl (Andy Tanenbaum) (06/24/87)

In article <4122@amd.UUCP> nguyen@amd.UUCP (Quinn Nguyen) writes:
>In article <1214@botter.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes:
>> I think the session layer is ridiculous.  
>
> Quinn then goes on to say:
>Some one [who] proved that the session layer is
>not null (such as IBM) must have a very good reason for it! 

This is the kind of thinking that led to OSI in the first place.  The
committee observed.
   1.  IBM has a 7 layer network architecture.
   2.  IBM is big and powerful and successful

Ergo, if we have a 7 layer network architecture we will become big and
powerful and sucessful.  Nonsense.  It is not desirable to create a giant,
ponderous beast that lusts after megabytes the way the cookie monster
goes after cookies.  St. Exupery said: Perfection is not achieved when
there is nothing left to add, but when there is nothing left to take away.

Look at the success of RISC machines.  Computer architects have learned that
what one does NOT need is an unwieldy instruction set that no compiler
can produce code for.  Adding more instructions and modes and stuff on the
off chance that someone will someday need it is foolish.  The idea of
having a session layer for those few applications that can't keep track
of whose turn it is to talk is equally silly.  Let them do it as part of
the application.  I think network architectures (and everything else in
the world) should be made as simple as possible, consistent with their
intended goal.  I think OSI needs to go on a crash diet.  Null session
layers aren't the way to go.  The structural complexity is still there, 
even if it is dormant for the moment.

Andy Tanenbaum