Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!A.ISI.EDU!PADLIPSKY From: PADLIPSKY@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP Message-ID: <8703021641.AA14109@ucbvax.Berkeley.EDU> Date: Mon, 2-Mar-87 10:56:39 EST Article-I.D.: ucbvax.8703021641.AA14109 Posted: Mon Mar 2 10:56:39 1987 Date-Received: Tue, 3-Mar-87 20:50:15 EST References: <8702270413.AA00250@bel.isi.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 248 Approved: tcp-ip@sri-nic.arpa I had already seen the GOSIP document and been asked, under extreme time contraints, to comment on it for "my sponsor". The comments follow. They should be understood as being fragmentary, in the sense that I feel a lot more could be said, and various points don't even get the emphasis they deserve (e.g., the very negative implications of the fact that the NBS variations aren't "pure ISO"), but I wanted to get them out on the table as soon as possible, so I haven't made an editorial pass over them for this mailing. Please note that I have tried very hard to refrain from what I call Constructive Snottiness (and what many doubtless call abrasiveness) here, but I don't want anybody to think it's from lack of intensity of feelings on the subject. Quite the opposite, indeed. But let the record show that I think the promulgating of GOSIP AT THIS POINT IN TIME is utterly irresponsible, and amounts to "go sip at the public trough for years to come." I urge anybody who sees this and agrees with my negative assessment of GOSIP to alert everybody they can think of that it should be forestalled until the ISO and/or the NBS can offer an INTEGRAL suite of widely-implemented, tested, performance-acceptable protocols. (I personally believe that they're still five years away-- and attach some significance to the fact that I, and other knowledgable observers it should be noted, have been saying that very thing for at least five years.) cheers, map Comments on "GOSIP" Draft M. A. Padlipsky I urge that DIA take the strongest possible action to assure that the DoD take the strongest possible action to prevent the promulgation of a finalized version of the "GOSIP" Draft (dated December 18, 1986). There are three broad grounds on which the dissent should be based: (1) There is ample evidence within the document itself that it is premature for any branch of the Government to standardize on the ISO/OSI protocols. (2) There are leg- itimate DoD concerns and requirements that the ISO/OSI pro- tocols do not, and in some cases cannot in principle, address. (3) There are sufficient technical flaws and inconsistencies in the GOSIP document as to cast doubt on the qualifications of its progenitors to be prescribing net- working policy for the DoD, much less for the Government as a whole. Although time does not permit an exhaustive analysis of each of these areas, some indication of the lines of argument will comprise the remainder of this note. The support for (1) is as follows: The Preface states "This specification will change..." and "Appendices specify future work items needed to enrich the specification...". This is prima facie evidence that the Government is being asked to make procurements to a moving target, the costs of doing which should be well known. Since a major rationale for choosing international standards has traditionally been to save on procurement and maintenance costs, the fact that the document acknowlegdes that there is not yet in existence a stable, seasoned, integral suite of protocols in the ISO/OSI arena indicates that this rationale does not apply at the present time. On the strength of its Preface alone, then, an appropriate response to the GOSIP document would be "Come back in three or four years, when you've got something solid to plug". The absence of a Virtual Terminal Protocol stan- dard in 1.3 is further evidence of the underdeveloped state of the ISO/OSI work, since the ability such a protocol would confer to perform remote logins is fundamental to an inter- computer network worthy of the name. The presence of 1.5.2 and 1.5.3 on "Secondary Sources" and "Tertiary Sources" (of protocol specifications) is still further evidence of incom- pleteness. It is also implicit evidence of fiscal impru- dence: implementing a Draft Proposed Standard can be a waste of money when the Draft International Standard takes a sub- stantially different technical approach, as witness the experience with FTAM; reinterfacing DoD "Telnet" to "TP4"-- as would be consistent with 1.5.3--would also be expensive, and would prove to have been wasted motion whenever the "official" Virtual Terminal Protocol were proclaimed. The footnote to 1.6.1 is also suggestive: if OSI is so "new" that there's no "testing service," isn't it too new to invest in? And if, as 1.6.3 states, "GOSIP does not cite performance criteria," might we not be buying a dead pig in a poke? Finally, it is not enough to say, as 1.6.4 does, that "It is expected that most vendors will update their products..."; unless GOSIP can somehow mandate updating at known, extremely modest cost, isn't GOSIP asking the Govern- ment to sign a blank check? In summary, until ISO has pro- duced specifications for an integral suite of seasoned pro- tocols, GOSIP will almost surely generate more expenditures than savings. The support for (2) is as follows: The technical areas of concern to the DoD which are not addressed by ISO/OSI have been dealt with elsewhere; see References 1-3, for example. For present purposes, it should suffice to note that, among other technical areas, the DoD is--and must be--particularly concerned with the mobility and survivability of its commun- ications, yet GOSIP 4.1.1 mandates a choice of proximate network interface protocols that seems to preclude use of such media as Packet Radio and 5.1.3 specifies static routing--both of which dictates run counter to the DoD needs in the area--and that the DoD has deep Security concerns, yet the GOSIP section on that topic on the one hand does not necessarily reflect the DoD view and on the other hand does not even reflect the prevailing ISO/OSI view (it is, in fact, modeled apparently fairly closely on a view which has been proposed in DoD circles), so that even if it were to prove on closer inspection to be acceptable to the DoD its implementation would engender additional charges by the ven- dors. (It should also be noted that there are inherent, possibly insurmountable difficulties in addressing DoD Secu- rity concerns in the public standards arena.) There is a non-technical concern that deserves even more attention than the technical points in the present context, however. For the DoD, after all, is not "made of money," and it has in place and running an integral suite of intercomputer net- working protocols which indisputably possesses both of the significant desirable properties claimed for OSI: it is "open," in the sense that it is not vendor-idiosyncratic and anyone who implements it can interoperate, and it is widely available, in the sense that dozens of vendors offer DoD Protocol Suite products. (It is also arguable that the DoD Suite is technically superior to the ISO/OSI Suite, but that is not the point at issue here--any more than that there are probably more DoD Suite products available today than OSI Suite products.) Why should the DoD be told in effect to send a well-maintained, late-model, paid-for, "loaded" Buick to the junkyard in order to have the garage space so that it can buy a "stripped" Renault that doesn't even claim to get better gas milage and doesn't have a passenger's seat and other key components? Is this not throwing bad money after good? That is, whatever economic justification there is for ISO/OSI in the de novo case--and certainly, if the Depart- ment of Commerce, say, had no intercomputer networks whatso- ever right now, a better case could be made for "going GOSIP," even though it's premature to do so, rather than "going SNA"--it simply doesn't apply in the case where the fruits of an investment in seasoned art are actively being enjoyed, as is the case in the DoD with respect to the DoD Protocol Suite. Therefore, I would suggest that if points (1) and (3) are not deemed sufficient to put GOSIP on hold for several years the Applicability section of GOSIP (1.4) must be reworked to take cognizance of the realities, with DoD explicitly empowered to exercise its own best judgment on whether/in what specialized circumstance it will "go GOSIP." (It might not be germane to the argument, but it is at least interesting to note that the conceptual underpinnings of OSI were invented and given proof of concept in the DoD- sponsored ARPANET, which is why the statement above about "openness" in the DoD was labeled as indisputable: the prin- ciple of Layering and the goal of Host heterogeneity both come from what is now the DoD Protocol Suite. Therefore, the position I am urging the DoD to take is not one of "Not Invented Here," by any means; it was invented "here," and why should we pay to have it reinvented elsewhere when it works fine here is more like it.) The support for (3) is as follows: The very definition of "End system" in the GOSIP Glossary is inaccurate. In the first place, the defining characteristic of a "terminal" in the intercomputer networking context is that it does not implement the protocols; "intelligent terminals," "worksta- tions," and "personal computers," by contrast, can be "end systems," since they can implement the protocols (but when they merely emulate ["dumb"] terminals, they're not being end systems). More damaging to the GOSIP Draft's credibil- ity, though, the entire weight of the Outboard Processing ("Network Front-End") art militates against the assertion that the protocols must all be implemented "in" the end sys- tem. Another Glossary flaw: "intermediate systems" actually participate in routing, in concert with end systems, they do not "perform routing." Further, in 1.1 GOSIP is stated to be "consistent with and complementary to [MAP and TOP]." If so, it's not consistent with the ISO/OSI "Reference Model" it explicitly espouses elsewhere, since MAP and TOP are not consistent with the reference model. (They prescribe per- forming L6 functions in L7 and they ignore L5.) Also, in 1.4 it cannot be optional to employ the protocols in microprocessors, etc. "that will be connected as end sys- tems..."; it must be mandatory to do so if they're end sys- tems, by definition. Then there's the statement in 3.1 that "Achieving OSI...is best accomplished by using...one protocol specification at each layer": this is palpable non- sense, since if there were one protocol at each layer you wouldn't need Layering, which was invently precisely to allow the existence of different protocols at each layer without having to change the upper (or lower) layer proto- cols to take cognizance of the differences. Indeed, the statement is contradicted in both of the next two para- graphs. And the description of the "transport layer" in 3.2 is incorrect in that it omits reference to both "connection- less" L4 alternatives and to "unreliable, but rapid" L4 con- nections, both of which are necessary and desirable in many intercomputer networking contexts (including several of par- ticular interest to the DoD). Similarly, in 4.1.1, "tran- sport class 4" should not be mandatory: it's merely one of a number of L4 alternatives, even if it was NBS's "baby." For that matter, forcing a choice among a limited number of L2-1 "technologies" betrays a lack of understanding of the power of Layering (you can prefer certain technologies for certain contexts, but if you're properly layered it doesn't matter if the bits are going over a direct wire), and exempting "messaging" from having to comply with L6 (and apparently from L5) simply flouts the very reference model espoused, in a nearly scandalous fashion. (Just because CCITT has enough "clout" to ignore the ISO/OSI reference model doesn't mean that a Government standards program intended to bring good networking practice to participants economically should.) Without bothering to scrutinize the rest of the document for still more evidence, then (although the lack of definitions of terms in 5.2.1 is particularly annoying), it certainly appears that GOSIP is preaching an approach it doesn't prac- tice. Time constraints do not permit a more comprehensive adducing of evidence, but one would hope that the points raised here at least suggest that it is premature for the Government to impose GOSIP upon itself. It is folly to chase a moving target in technological implementations; it is folly to dis- card state-of-the-art technology in favor of less mature technology; and it is folly to adopt misunderstood stan- dards, irrespective of whether they are or are not ever understandable, since it will be too expensive to get them understood even if they are. Let GOSIP go sit for as many years as it takes to come up with a complete set of well- specified, well-implemented protocols that are mutually com- patible. (And then let it come up with a more reasonable position with respect to the DoD Protocol Suite.) References [I'll formalize these if anybody's willing to hand the paper to some Authority; they'll be 1: The Book, 2: Cerf and Lyons' paper on Military Networking, and 3: A Norwegian paper (in English) on the same general topic; just don't feel like digging them up at nearly 6 on Friday.] -------