[ih] Quantifying OSI

Tue May 12 08:52:05 PDT 2026

One of the issues that OSI had that the Internet didn’t were very entrenched factions that were going to have their way no matter what.
The PTTs absolutely didn’t want a Transport Layer or datagrams, when they couldn’t stop it (the US wanted nothing else) they did all they could to restrict it and make it something to avoid. It didn’t help that many individuals in European computer companies supported the PTT view. IBM was doing all they could to slow the process down or just plain stonewall it from ever getting off the ground. Then there were countries who wanted something special apparently just to put their stamp on it.  The UK was especially good at this.

From a standards environment there was no way to definitively kill any of these. One had to ‘let the market decide.’  The 5 classes of Transport was a good example. When the PTTs couldn’t stop there being something, their strategy was to option it to death and they had help:
TP0 - was for SGVIII who really wanted nothing. you
TP1 - was for SGVII who used over X.25 without error control (because X.25 was reliable which it wasn’t)
TP2 - was for the Brits who wanted to multiplex over X.25 (which the PTTs didn’t want) and thought it would be more efficient to not have most error recovery, ignoring that TP4 under the same conditions was just as efficient. They had to have their way.
TP3 - something for the Germans, I never understood what.
TP4 - really all that was necessary and all that was needed and an advance over TCP.

IBM more or less stayed out of that controversy, probably because others were doing their job for them.  TP0 - TP3 should have just been ignored. No one with any brains thought they were useful except their faction supporters.

What I found frustrating was that companies (and individuals) thought they should implement all of it. When it was abundantly clear that that one should only implement CLNP, TP4, collapse the upper 3 layers* into a single layer for modular development of applications and ignore X.400 and X.500. nBasically ignore anything from CCITT.  (One amusing CCITT ploy was that since X.25 was not reliable, but they couldn’t admit that anywhere near the Transport Layer just had to have RTSE in the Application Layer to recover the X.25 errors.

As I have mentioned, I am also mystified that people paid more attention to the CCITT than to what the computer companies were doing in ISO and the US. So far as I know other than the people who worked in both the IETF and OSI on the network layer, no one from the IETF contacted the ANSI work on OSI. Why not?  It was clear that CCITT had no idea what they were doing and trying to go backwards instead of forwards. One begins to believe that there was an intent to make it look bad. The actions taken certainly said that.

Scott Bradner once wrote an Editorial in NetworkWorld blasting OSI for not considering TCP. It seemed a bit odd, since OSI had already accepted as a starting point a proposal whose first author was Vint Cerf. OSI had accepted the recommendation. Or more amusing were the people who said something like ‘well, OSI had a Session Layer.’ Making obvious that they didn’t know that the OSI Session Layer was not a Session Layer and had been stolen by CCITT SGVIII for Videotex.

Even when people tried to focus on subsets of OSI in efforts like the NIST Workshops* or COS, they spent more time arguing the same factions the standards committees had argued and not coming to any better conclusions. The NIST Workshops partly suggested by IBM used an age old ploy to further confuse and delay the work by separating the designers from the implementors. The myth was of course that implementors knew more about writing the code that designers. In my experience, it was just the opposite. The designers knew what subtitles had been written into the spec for implementors to take advantage of. The implementors were clueless. (NIST Workshops were often scheduled on top of OSI meetings that prevented designers from attending the Workshop,

* In 1983, OSI recognized the upper 3 layers were not layers. The existing standards were ‘adjusted’ so the upper 2 layers could be implemented as basically null and just concentrate on the Application Layer, which was actually very interesting and a major advance over what the Internet was doing. (X.400 and X.500 are not included in that. They were purely CCITT projects with some clueless Americans participating. Much of it was the remnants of the National Software Works project DARPA funded.

OSI was dealing with a lot of problems that were not present in the Internet. That gave it a much higher hill to climb. It was going to take a lot of shaking out to get there. They were very different. There was no way to simply read the spec and know what to do. (At the same time, we had BSI doing all they could to ensure the specs were not what implementors needed.) Without talking to the people on the ISO side there was no way to know what was really going on.

Take care,
John Day 

> On May 12, 2026, at 01:43, Carl Malamud via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> Thanks everybody for your contributions and memories on this thread. Very
> helpful and interesting.
> 
> As to the comment about how this discourse is akin to shooting a dead
> horse, I believe we need to learn from history or we will be doomed to
> repeat it, and sometimes that means shooting a dead horse again.
> 
> Like many of you, I spent a lot of time looking at OSI. I spent thousands
> of dollars buying specs and many many hours trying to figure out what this
> was all about for my book on Decnet Phase V, a book I now think of as
> "paperware about vaporware." My book on Novell networks certainly sold much
> better.
> 
> Best regards,
> 
> Carl
> 
> 
> On Tue, May 12, 2026 at 7:58 AM Dave Crocker via Internet-history <
> internet-history at elists.isoc.org> wrote:
> 
>> Brian,
>> 
>> On 5/11/2026 7:17 PM, Brian E Carpenter wrote:
>>> That's true, but it leaves an impression that the OSI community was
>>> just vapourware, which I don't think is fair.
>> 
>> Depending on the moment in time and the qualifications for being actual
>> 'ware', it is absolutely fair.
>> 
>> Unless the view is that having even the smallest bit of software of any
>> portion of what is needed makes it not be vaporware.
>> 
>> It was touted for 15 years as /the/ solution.  It delivered, at best,
>> small bits of capability -- which I won't honor with the classification
>> of 'utility' -- and never at scale.
>> 
>> I suppose X.25 might be considered an exception.  Except that, really,
>> that wasn't OSI in terms of what was promoted.
>> 
>> 
>> 
>>> The OSI vision was *very* attractive to people (like me) trying to run
>>> networking services in a multiprotocol world,
>> 
>> Yes.  As I said, it was a very successful marketing campaign.  It did
>> develop market demand.
>> 
>> 
>> 
>>> and by the mid-1980s OSI was (apparently) well specified and ready to
>>> become product.
>> 
>> Sorry.  No.  Not by any stretch of operational pragmatics, except,
>> perhaps, at a department level.  And there were many other, better and
>> more mature choices for that market segment.
>> 
>> In fact there was a running joke that OSI was repeatedly promised to be
>> ready 'in two years."  I was at a conference in 1990 where Heidi Heiden
>> was speaking and he noted this running promise.  He said that while that
>> unfortunate history was true, OSI really was almost mature enough for
>> production deployment and would be available in 1992.  I, of course, was
>> unable to refrain from shouting out a comment on that.
>> 
>> 
>> 
>>> It was very disappointing that it wasn't actually ready and fit for
>>> purpose when we needed it (which was, roughly speaking, 1989, for the
>>> experiments at LEP, the electron/positron collider). TCP/IP stepped in.
>> 
>> 1989 was too late.  As I've noted before, around that time I explored
>> customer needs for transitioning from TCP to OSI and without exception
>> all I heard from our customers was a very strong need for transitions
>> tools in the opposite direction.
>> 
>> d/
>> 
>> --
>> Dave Crocker
>> 
>> dhc at dcrocker.net
>> bluesky: @dcrocker.bsky.social
>> mast: @dcrocker at mastodon.social
>> +1.408.329.0791
>> 
>> Volunteer, Silicon Valley Chapter
>> Northern California Coastal Region
>> Information & Planning Coordinator
>> American Red Cross
>> dave.crocker2 at redcross.org
>> 
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>> -
>> Unsubscribe:
>> https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history
>> 
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
> -
> Unsubscribe: https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history