postel@bel.isi.edu.UUCP (02/27/87)
Hello: There was a message to this list a month ago about the GOSIP report, the Government Open Systems Interconnection Procurement Specification. It turns out that this is a matter that deserves our serious attention. In general it is a well intention effort to come up with a plan to get the US Government to acquire computer communication protocols that will interoperate so that computers that need to exchange information can do so. Unfortunately, there are some aspects of the plan where good intentions run ahead (on thin ice) of practical reality. It is important that the authors of the plan hear comments on it soon, in the next two weeks! The authors i know of are in the CC field of this message. The report has been coordinated with a large set of government staff represeneting a large number of government agencies (many that have nothing to do with computing research and development, but that do use computers). Please do not assume that this plan is someting that NBS and DOD cooked up to do in IP/TCP. In fact, the DOD people involved are perhaps the most knowledgeable and reasonable. A major problem is that for most of the other representatives, what they know about protocols (if anything) is what they read in Computerworld or Datamation. So please find out more about the GOSIP report, and send comments to the authors. The activity is coordinated by the NBS so offline comments should be sent to: GOSIP Institute for Computer Sciences and Technology National Bureau of Standards Gaithersburg, Maryland 20899 --jon.
PADLIPSKY@A.ISI.EDU.UUCP (03/02/87)
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.]
-------mrose@NRTC-GREMLIN.ARPA.UUCP (03/03/87)
Mike - I do not claim to have all the answers on GOSIP, but I
believe that one of us is severely misinformed as to GOSIP's
*intent*.
GOSIP simply states (according to my paraphrasing):
If a US Govt. organization wishes to buy OSI networking
technology, then these are the guidelines that organization's
procurement authority should use when specifying the
requirements for said technology.
As such, the GOSIP spec, although containing some minor errors, is
entirely consistent with reality. I believe that the problem
arises from the fact that you (and I) consider TCP/IP to be OSI in
addition to the ISO/CCITT stuff. The people writing the spec do
not view it that way, they view OSI as being "proprietary" to the
international standards organizations.
Given this perspective, let me make a couple of observations:
GOSIP does not say "let's trash this TCP/IP and ISO". It says "if
you're going to buy ISO, then in FY87, this is what you should be
buying". Mike, you've really got to get this us vs. iso chip off
of your shoulder, it is starting to damage your spinal cord and
hence you sense of balance.
GOSIP is actually quite realistic in what it suggests:
There is no usable virtual terminal protocol from ISO these
days, so they don't try to specify one. That is responsible.
The FTAM DIS will be an IS "any day now" and the changes from
DIS to IS are very minor. So, saying the FTAM DIS is OK, is
again, a fine thing.
Finally, the reason that the CCITT X.400 (MHS) stuff doesn't
have a presentation layer, is that it pre-dates the ISO
presentation layer. There are, however, several
implementations of X.400 which do work (and interoperate with
each other). The current joint ISO/CCITT work in message
handling, called MOTIS, does make use of ISO presentation
layer, adhering to that model of 7+3i that we love so well.
Again, since there are X.400 implementations that are working,
let me remind you what someone said in his collection of essays
on networking:
Do you want protocols that look nice or protocols that
want nice?
Given the charter of GOSIP as I interpret it, again they are
doing just fine.
Now, if you want to talk about unrealistic goals, I will privately
tell you what other OSI mavens are proposing for the '88 time-frame
(you think SDI is complex and has to do a lot? heh, heh, heh, have
I got a user profile for you!)
But, I digress: let me come back to the start of the message.
GOSIP does not say "TRASH TCP/IP". It would be much better for the
networking gurus of the Internet to look at the spec and be helpful
rather than view it as an attack on motherhood. Of course, as you
know, I like both technologies: that's why I'm running FTAM DIS now
in a TCP/IP network. I have this great ISO application running on
a stable Internet. What can I say? It's great!
/mtrPADLIPSKY@A.ISI.EDU.UUCP (03/03/87)
Marshall-- Sorry, but your "paraphrase" is not supported by the words on the page. See 1.4, Applicability: "GOSIP is to be used by all Federal Government agencies when procuring ADP systems or services and communication systems or services. It is mandatory for all new network implementations and should be carefully considered for retrofits." See also 1.2, Purpose: "This specification is _the_ standard reference for all Federal Government agencies to use when procuring ADP systems or services and communication systems or services." See, for that matter, 1.1, Background: "GOSIP addresses the need fo the Federal Government to move immediately to multi vendor [sic] interconnectivity...." Perhaps you saw an earlier draft. I don't have a chip on my shoulder, I have a clear and present danger in my sights. If this be paranoia, let's make the most of it. cheers, map P.S. Just so nobody thinks I'm quoting unfairly, 1.4 does offer: "For a period of two years, agencies are permitted to procure alternative interoperable protocols, but they must provide a mechanism for those protocols to interoperate with OSI protocols as well." Perhaps you construe this as keeping the TCP/IP Suite; I can't. -------
mrose@NRTC-GREMLIN.ARPA.UUCP (03/04/87)
We are looking at the same draft. My problem is that I attended the meeting, and formed my opinions on that, instead of interpreting the fine points of the draft. It was quite clear at the last meeting that GOSIP was not intended to mandate OSI networking. Rather it was intended to mandate the types of OSI networking technology, if one were to buy OSI. The authority to mandate OSI networking over any other technology, e.g., TCP/IP, SNA, or XNS, lies with OMB. I'm not real clear on this, but there is some OMB directive in the works which makes that mandate. If you want to get paranoid, that is where to start. It was clear to the GOSIP committee during the meeting that they were only interested in specifying the OSI technology they wanted. From this perspective, GOSIP is a reasonable thing. Perhaps someone in authority and/or with more insight can shed some light on this discussion. /mtr
pogran@CCQ.BBN.COM.UUCP (03/04/87)
Marshall,
But the document states (p. 2, sec. 1.4):
"GOSIP is to be used by all Federal Government agencies
when procuring ADP systems or services and communica-
tion systems or services. It is mandatory for all new
network implementations ... Specifically, this speci-
fication is mandatory and applies to the procurement of
all mini computers and mainframes that are to be inter-
connected as end systems or intermediate systems."
If the framers of this document wanted to say, "Use this
specification IF you want to procure OSI stuff", it certainly
didn't come out that way! My paraphrase of it would be, "If you
want to buy systems that communicate, you MUST use this spec." I
vote with MAP on this one (that's Michael A. Padlipsky, not
Manufacturing Automation Protocol).
Ken PogranPADLIPSKY@A.ISI.EDU.UUCP (03/04/87)
Marshall-- It's difficult for me to see how anyone could call the Applicability section of a proposed Federal standard a "fine point." For more on the topic of how the wording of the spec can subvert the intent of the committee, see pp. 84-5 of The Book (which you must have, since you were good enough to have quoted p. 228 at me [somewhat out of context] in your previous msg). Re the presumed "OMB mandate": In my view, it's almost certainly a red herring (stipulating that it does indeed exist, which you didn't seem sure of), for two separate reasons: (1) OMB almost certainly was put up to it by NBS, so your appeal to it represents a type of circular reasoning, not an external confirmation. (2) It's manifestly premature, regardless of whose idea it was originally; see my critique of the GOSIP draft. But I'm certainly quite willing to join you in encouraging anybody who's tracking this disucssion who knows how to alert OMB to the error of its ways to do so--as quickly and as emphatically as possible. (I don't, however, agree with your implication that they shouldn't bother to try to beat on NBS, too.) cheers, map -------
mrose@NRTC-GREMLIN.ARPA.UUCP (03/05/87)
Well Mike, what can I say? You got me on a technicality. Final
defense: It is my belief that the scope and applicability sections
of the GOSIP spec are mis-stated in that they are not consistent
with what I thought was going on at the meeting. Perhaps I am wrong
and have misinterpreted what was agreed at the last meeting. If I
am correct in this assumption, then these two sections should be
fixed in the final copy. If this is done, then GOSIP is a fine
thing.
If, on the other had, I am wrong, and these sections are to be an
accurate representation of GOSIP's intent, then I have wasted
everyone's time trying to defend something which is patently wrong
(as most of your arguments point out) and I'll appologize.
However, since none of the people in the know have commented on our
discussion, it is difficult for me to gauge how right/wrong I am.
/mtrPADLIPSKY@A.ISI.EDU.UUCP (03/05/87)
Marshall-- Tell ya what, if you'll promise to agitate through your "OSINET" channels against the Applicability stuff I'll promise not to debate whether I got you on a technicality or a TKO. cheers, map P.S. I'm told John Heafner has left NBS; trust you know some other addressee there. -------
CERF@A.ISI.EDU.UUCP (03/05/87)
Mike, John has indeed left NBS and gone to some part of DEC - don't know which, but since John is on this distribution, maybe he will say, if he still reads his Internet mail. Vint
braden@ISI.EDU.UUCP (03/05/87)
Marshall, It would seem that the important issue is not whether you are right or wrong; either case seems to lead to the same conclusion, that the present wording in the GOSIP document is badly damaged and damaging. Bob Braden
mrose@NRTC-GREMLIN.ARPA.UUCP (03/05/87)
Yes, you are absolutely correct Bob. Tell 'ya what: Let's forget about my recollections of the subject and concentrate on the specification as published. That should be a much more productive use of our time. Sorry to have confused the list with this... /mtr
PERRY@VAX.DARPA.MIL (Dennis G. Perry) (03/06/87)
I think Rose has a fair interpretation of the GOSIP document, at least according to my understanding of the discussion at the last PSSG meeting. On the other hand, please do get your constructive comments in to Corrigan so that they may properly be relected in the document. dennis -------
ucdla%topaz.Berkeley.EDU@UCBVAX.BERKELEY.EDU (U.C. Div of Library Automa) (03/09/87)
anyone know how to go about getting a copy of the gosip document?
kzm@ACC-SB-UNIX.ARPA.UUCP (03/09/87)
Mike, I agree with your comments on the GOSIP spec, but not because I am opposed to ISO/OSI. On the contrary, on that future day when it replaces TCP/IP, I think it will be to the benefit of all, since it will encompass a larger audience. This is irrespective of the technical arguments of which is currently better. Here are a few more technical criticisms you might add to your paper : 1. [4.2.4] Packet Voice definitely requires use of other than Transport class 4. 2. [4.2.7.3] says that end systems connected to public data networks must implement TP0, but end systems connected to a private subnetwork must implement TP4 !! This is clearly not inter-operable. 3. [page 19] says "Note that the SNPA is interpreted as decimal digits, even though the AFI of 47 indicates a binary representation" !! Is this following the standards ?? 4. [top of page 20] specifies that the level-3 address must be encoded according to which Level-1 protocol is used (eg. 802.3 is given a NSAP Selector different from 802.4 when both have 802.2 above them). There is already a subnet-id included in the address. Why mix the layers like this ? Cheers, Keith McCloghrie ACC Columbia, Md.
STJOHNS@SRI-NIC.ARPA (03/10/87)
The following is sent on behalf of Mike Corrigan:
_____________________________________________________________
A few comments:
1. GOSIP is the Government OSI Protocol Specification.
It was prepared by a working group of the Government OSI
Users Group, chaired by NBS, which was formed in reaction
to what was a pending Office of Management and Budget
announcement mandating use of OSI, without benefit of a
specification. I don't know the exact status of the OMB
announcemnet, but I believe it is still pending.
2. GOSIP is supposed to have been made available for
FTPing from the NIC, but I'm not sure it is really there.
I will find out and let you know.
3. A specification such as GOSIP consists of two key
parts: what it is you hope to buy and when you have to buy
it, or, the body of the spec and the applicability
statement. If these don't match as well as they might,
you get some very peculiar discussions. I think Mike P's
discussion makes it clear that the GOSIP spec pulls no
punches with respect to what ypu can currently acquire in
OSI, and if the applicability statement were not part of
the document, it would meet truth in labelling, full
disclosure and informed consent concerns a lot better than
we have ever managed in the ARPA/DOD protocol standards
arena (for example, did anyone ask themselves about
guidance or capabilities in the areas of performance,
testing, and user interfaces for TCP/IP/SMTP/FTP/TELNET
when reading Mike P's comments?). If we had waited for
adequacy in these areas in DOD, we would still be waiting.
4. The group responsible for resolving the mismatch
between the applicability statement and the spec body in
DOD is the protocol standards steering group (actually, it
is more complicated than that, but the PSSG invited all
the complications to participate with them). At its
recent meeting, the issues Mike P. raised were brought to
the table by his sponsor, as well as a number of others,
and I believe they will be adequately addressed in the DOD
comments on the spec, and for the most part will be
incorporated in the final spec. I believe that the result
will be to place the applicability statement somewhere
between the Mike P. reading and the Marshall Rose reading.
After the GOSIP is published, there will still need to be
guidance prepared by the different agencies for its use in
each agency, since different agencies have different plans
and concerns.
5. At this point, I believe additional comments would be
most useful if they adopted the Marshall Rose
interpretation, that is, "If you want to do interoperable
OSI, this is how to do it." An additional issue is how
OSI should be used by the protocol research community.
For really far out research, clearly OSI (or current
ARPA/DOD) are minimally relevant. But there is a lot of
research in the nearer term which could result in changes
to currently planned and operational protocols. Assuming
that one believes that the operational protocols for lots
of folks are going to be OSI, then the question is how
might improvements best be researched. One approach would
be to adopt OSI as the research base. This has a lot of
apparent advantages: direct applicability and shared
terminology for two. A possible difficulty is that the
OSI protocols might be a bit "rich" to use when
investigating particular points, and a "leaner" protocol
suite might be easier to use as the research suite. This
approach, however, would have the disadvantage of needing
a translation step. (Incidentally, I thought Mike P's
protocol to car analogy was less than apt. I would go
with OSI is to DOD as Lincoln Town Car is to MGB.)
Mike C.
PADLIPSKY@A.ISI.EDU.UUCP (03/10/87)
Jon-- Rather than hold fire until everybody who has HEARD things about GOSIP that are rather different from what has been WRITTEN about it manages to catch up with their reading (after all, Marshall has already thrown in the towel and presumably Dave will soon), may I suggest we assume consensus has been reached in the TCP-IP "world" that the GOSIP draft AS CIRCULATED is inappropriate and turn to discussing ways of combatting it? Does it make sense to encourage everybody who has/will come out against it to send hardcopy to Corrigan and Sullivan, seeing that they don't appear to be responding to netmail? Would you like to join me in encouraging Dennis Perry to encourage DARPA to take a formal stand? Should we be suggesting to all interested readers of TCP-IP that they write to Congress? to the GOSIP address you put in your first msg on the topic? to the chaplain? Does anybody out there have any connections with "60 Minutes"? (Not totally facetious, that; they might like one where the DoD has the right end of the stick and it's OMB and/or NBS who are leading to the overexpenditures, if only to balance the one they did the other week about the Bradley Armored Personnel Incinerator--er, uh, Carrier.) I'll be sending my own hardcopy, in compliance with a suggestion Dennis made, but I'd like to think all concerned parties can "do something" in concert. Any ideas? (For that matter, can you publish on the List appropriate p-mail addresses for Sullivan and Corrigan [p=physical], and should the NBS copy go to the attention of Jim Burrows, who was Heafner's boss before he left, perhaps, rather than just to GOSIP?) totally unfacetious cheers, map P.S. As evidence of my seriousness, note that I consciously resisted saying that the hardcopy should be sent Return Receipt Requested. -------
MRC%PANDA@SUMEX-AIM.STANFORD.EDU.UUCP (03/11/87)
If OSI is to DoD the way a Lincoln Town Car is to an MGB,
I guess we'll be running DoD protocols for a long long time to
come.
As a network programmer, I am delighted at the prospect of
full employment for everybody in my field for a very long time,
at US government expense. As a taxpayer, I'm outraged, and am
starting to make comparisions in my mind with the Sgt. York and
the B-1.
I am wondering if what we are seeing is OSI having become
so large and unmanagable that implementability has become a
forgotten goal. I read the FTAM specification and still am not
completely sure what FTAM is all about. "Eschew obfuscation"
seems to have been forgotten.
More to the point; I don't think the US government should
be in the business of trying to establish OSI as a standard
protocol. The current regime is big on "market" based decisions.
If the US government sees itself as a USER of an international
standard protocol but is otherwise neutral on what that protocol
should be, then the current de facto international standard is
TCP/IP. If OSI is so wonderful, then all the other users of
network protocols -- industry, research, our foreign allies,
the socialist countries(!!) -- will migrate to OSI without US
government pressure being brought to bear.
If OSI fails to gain such widespread acceptance, then
perhaps it was a bad idea to begin with. Nobody is seriously
suggesting that TCP/IP should be retained indefinitely; what
we ARE saying is that there should not be *any* talk of
migration until there is clearly something better available.
-------PERRY@VAX.DARPA.MIL.UUCP (03/12/87)
Mike, I have made a very strong request to Corrigan at the PSSG meeting to include something in the GOSIP document to exempt research related procurement. Mick C. agreed to include such suggestion, as I believe he alluded to in his response to the net. DARPA's position is that research should not be hampered by standards, but shoud use them as appropriate to further their research. It may also mean not using them to further their research. The Arpanet is a research network. You can draw your own conclusions from their on my position. dennis -------
hedrick@TOPAZ.RUTGERS.EDU.UUCP (03/12/87)
Could you forward this back to Mike Corrigan: My primary concern is that we don't push OSI so fast that we ruin its long-term future. TCP/IP proceeded the way it did because there was no choice. We had to get things out quickly because we needed the facilities. After all, it was originally claimed to be a research vehicle. OSI is supposed to be different. It is supposed to be a second-generation, production system, commerically supported, and all that. I have my own scepticism about this, but the point is that it will accomplish absolutely nothing if we push people into it so fast that we just duplicate the history of TCP/IP. One thing that 4.1 and 4.2 make very clear is how hard it is to get improved software into everybody's hands once large groups of people have started to use something. How many years will it have taken to get subnets in use? (It still isn't finished.) I understand the political pressure to move ahead quickly with OSI, but I think that should be resisted. I think you should be writing specs for pilot implementations, but be suggesting that all production work be done with TCP/IP. The point is that we should give OSI a chance to get some actual use in well-controlled environments, and do lots of testing. When something is offered for general use, that something should be well-tested and the robust. The last thing we should be doing is pressuring vendors to come out with products prematurely, as GOSIP seems sure to do.
markl@THYME.LCS.MIT.EDU (03/13/87)
> If OSI is to DoD the way a Lincoln Town Car is to an MGB, >I guess we'll be running DoD protocols for a long long time to >come. Well *I* have always found MGs to be paragons of reliability... markl Internet: markl@ptt.lcs.mit.edu MIT Laboratory for Computer Science Distributed Systems Group ---------- "When all else fails, pour a pint of Guinness in the gas tank, advance the spark 20 degrees, cry "God Save the Queen!", and pull the starter knob." -- MG "Series MGA" Workshop Manual :-)
slf@well.UUCP.UUCP (03/13/87)
I'm not 60 Minutes, but I am a computer journalist who has been following this discussion for the past couple of weeks with much interest. I am considering doing an article on this for InfoWorld (I'm the communications editor). To get this past my editors, I have to demonstrate that there is some PC connection; also, I would have to talk to people on 'the other side' (i.e., pro-GOSIP) to get their views as well. Does anybody have any information that can help me? Thanks.
CORRIGAN@SRI-NIC.ARPA (Mike Corrigan) (03/16/87)
As I mentioned previously, the concerns which have been raised
with respect to the applicability statement will be addressed in DOD
comments on GOSIP. I think, however, it may be useful to quote all
the relevant portions of the current applicability statement, and
give an alternate (I might add, the intended, but as Mike Padlipsky
says, you have to read the words) interpretation of what is there
now from either of the two views given to date (Mike Padlipsky's and
WBD.MDC's). The fact that there can be (at least) three views
argues that the current wording is unacceptably ambiguous, but I
don't think Marshall Rose, et al. should continue to think they were
dreaming when they interpreted it differently. There are three
important statements. I will abridge, but not paraphrase (Those who
want the missing words can get them from the NIC):
"It [GOSIP] is mandatory for all new network implementations..."
"Although GOSIP mandates OSI implementations in products, it does
not preclude the acquisition of additional (perhaps vendor specific)
networking capabilities in that same equipment."
"For a period of two years, agencies are permitted to procure
alternative interoperable protocols, but they must provide a
mechanism for those protocols to interoperate with OSI protocols as
well."
Statement 1 says that new acquisitions must include GOSIP
protocols.
Statement 2 says that any additional protocols which are needed
may also be acquired.
Statement 3 is a partial waiver of statement 1, that is, if an
agency already has an interoperable set of protocols (for example,
DOD with TCP/IP),
then it can buy the current suite in lieu of GOSIP protocols for a
period of two years. After this time, GOSIP protocols are mandatory
for such agencies as well, but, under statement 2, they can continue
to acquire their current set of interoperable protocols
indefinitely.
Please let me repeat that I agree that other interpretations can
easily be made of the current statements, and that even if no other
changes were made to the applicability statement, changes to avoid
the existing massive ambiguity would be essential. This is why
GOSIP is out for comment, but I think there is enough material on
this particular point to assist in the rewrite.
-------scott@GATEWAY.MITRE.ORG (03/16/87)
I just read the mail from Mike Corrigan giving the definitive(?) interpretation of GOSIP. I am reminded of when the government had a requirement that all computers acquired after a certain grace period have an ASCII processing mode (exacting when this was I can't remember). This hit alot of computer users hard since they were locked into machines produced by a well known manufacturer that used EBCDIC. This well known manufacturer, seeing his market being yanked away from him, provided machines that had an ASCII mode. No one ever used this mode but it was there in case the bean counters asked. Now I'm not saying that GOSIP is heading down the same road, but if it is this is a good way for software houses to pick up a quick buck for software that may never be used and therefore not that good.
dpk@BRL.ARPA.UUCP (03/22/87)
[Disclaimer: The following represent my personal professional opinion and does not necessarily represent the opinions of BRL or the DoD.] Concerning Connections between TCP/IP and PC's ---------------------------------------------- There are several possible connections between TCP/IP and PC's. There are several implementations of the DOD protocol suite for PC, both public domain (MIT & by Phil Karn for HAM packet radio) and vendor supported (FTP Software in Mass., maybe others as well, check with the NIC's vendor list). In addition there is TCP/IP support for PC's by means of smart interface cards that put TCP/IP into firmware. I believe there are several of these as well, 3Com being the one that comes immediately to mind. More details can be be dragged out of the NIC and the industry magazines. Try looking at Ungerman-Bass, Micom/Interlan, CMC, Network Solutions? PC's are now fairly easily tied into a network of Super-Mini's to Supercomputers using TCP/IP from any of these sources. This can even include true remote file systems using the Sun Microsystems NFS software for the PC (it uses the 3Com hardware as a base). A variety of vendors now make TCP/IP virtual terminal servers which provide a means to easily access other hosts via RS232 as a terminal. While this does not make a PC a real host on the network, it can be a cheap way for several PC's to access the network by sharing a terminal server and using it much like a modem. UNIX is becoming the second operating system of the PC and most versions of UNIX already support the TCP/IP protocol suite. Opinion and Caveat ------------------ [in the following read "ISO" to mean protocols referenced in the GOSIP] My position on this is a pragmatic one. I feel there is undoubtedly potential benefit to migration to (a possibly modified or amended) ISO protocol suite in the future. However, now is not the time to be purchasing ISO protocols for production use as the GOSIP is indicating. There is at least a decade of research in the TCP/IP protocol suite. This includes not only the investigation of the architectural features, but also the algorithms used in the actual operation of a large internet. These are lessons that are not necessarily transferable to the ISO protocol suite due to differences in design. These kinds of lessons can only be learned over time with controlled introduction, first into an experienced research community and then into larger communities as the specifications and unspecified algorithms solidify. You must keep the initial communities small because there will changes necessary, and you need fast turnaround between recommendation and implementation. I work in a research lab, and I expect us to start experimentation and testing of the ISO protocols to start this year at our institution. I don't expect them to work or to be complete. My gut feeling is that five years from now is the earliest time to expect reasonably robust and complete ISO protocol suite implementations. The government cannot afford to turn itself into an alpha or beta test site which is what would undoubtedly happen. As any consumer can tell you there is always a danger in buying the first units of a new product. If you are interested in reliability and predictable performance, you wait for the second printing, the next model year, or the later revision of the product. In short, I am not anti-ISO, but adoption of ISO on large scale at this time is a costly mistake. It will prove to be buggy, incomplete, and there will be unforseen incompatablities, and since its never been used on a large scale it will have scaling problems as systems are interconnected for the first time. The government should hold off widespread usage in production usage until the ISO suite has had a chance to mature, stabilize, and "prove itself" in the R&D community. I would be happy to talk to you further by phone or mail, and to help review your article for correctness regarding the TCP/IP suite. I feel its critical that people get the correct information about this. Cheers, -Doug- (301)-278-6678 AV 298-6678 FTS 939-6678 Internet: <DPK @ BRL.ARPA> Postal: Douglas P. Kingston III Advanced Computer Systems Team Systems Engineering and Concepts Analysis Division U.S. Army Ballistic Research Laboratory Attn: SLCBR-SECAD (Kingston) APG, MD 21005
karn@FLASH.BELLCORE.COM.UUCP (03/23/87)
A correction: my TCP/IP code for the IBM PC is NOT in the public domain; I have copyrighted it. However, I grant blanket permission for NONprofit, NONcommercial, NONgovernmental, NONmilitary copying and use ONLY. Amateur radio, educational and public service applications (e.g., Red Cross) are fine. (I really got a kick out of taking something originally developed for the military and subverting and perverting it for constructive purposes... :-) Otherwise I agree with Doug's posting. Phil
PERRY@VAX.DARPA.MIL.UUCP (03/24/87)
Seems to me you are taking good advantage also of the Arpanet, which was developed for militray purposes, why do you deny your obligations to it. dennis -------