Michael Padlipsky (PADLIPSKY@A.ISI.EDU)
2 Mar 1987 10:56:39 EST

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

(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 best accomplished by
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-

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.)


[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.]

This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:37:43 GMT