Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ames!pioneer!lamaster From: lamaster@pioneer.arpa (Hugh LaMaster) Newsgroups: comp.dcom.lans,comp.protocols.misc Subject: Re: OSI-model software Message-ID: <1724@ames.UUCP> Date: Tue, 9-Jun-87 15:38:12 EDT Article-I.D.: ames.1724 Posted: Tue Jun 9 15:38:12 1987 Date-Received: Fri, 12-Jun-87 04:17:39 EDT References: <223@diab.UUCP> <233@idacrd.UUCP> <526@alliant.UUCP> <19265@ucbvax.BERKELEY.EDU> <492@houxa.UUCP> <1204@botter.cs.vu.nl> Sender: usenet@ames.UUCP Reply-To: lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) Distribution: world Organization: NASA Ames Research Center, Moffett Field, Calif. Lines: 85 Keywords: iso, tcp-ip, internetworking Xref: mnetor comp.dcom.lans:508 comp.protocols.misc:42 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")