From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc874.txt | 874 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 874 insertions(+) create mode 100644 doc/rfc/rfc874.txt (limited to 'doc/rfc/rfc874.txt') diff --git a/doc/rfc/rfc874.txt b/doc/rfc/rfc874.txt new file mode 100644 index 0000000..73ad4ec --- /dev/null +++ b/doc/rfc/rfc874.txt @@ -0,0 +1,874 @@ + + + + + +--------- + + + < INC-PROJECT, MAP-CRITIQUE.NLS.10, >, 12-Aug-83 11:46 AMW ;;;; + + + + + + RFC 874 September 1982 + M82-50 + + + + + + + + A CRITIQUE OF X.25 + + + + + + + + + + + + + + + + + + + + + + M.A. PADLIPSKY + THE MITRE CORPORATION + Bedford, Massachusetts + + + + + + ABSTRACT + + + + + The widely touted network interface protocol, "X.25", and + its attendant conceptual framework, the International Standards + Organization's Reference Model for Open System Interconnection + (ISORM), are analyzed and found wanting. The paper is a + companion piece to M82-48, and M82-51. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + i + + + + + A CRITIQUE OF X.25 + + M. A. Padlipsky + + + + + Introduction + + According to some sources, the International Standards + Organization's (ISO) "Open System Interconnection" (OSI) effort + has adopted the International Consultative Committee on Telephony + and Telegraphy (CCITT) developed X.25 protocol(s) as its Levels + 1-3. ("Loose constructionists" of the ISORM would hold that X.25 + is a mechanization of L1-L3 rather than the mechanization, and at + least one British source holds that "we in the U.K. don't believe + that ISO have adopted X.25.") In the U.S. Government arena, + where the author spends much of his time, the Government + Accounting Office (GAO) has suggested that the Department of + Defense (DoD) ought to consider adopting "X.25 networks," + apparently in preference to networks based on protocols developed + by the DoD-sponsored intercomputer networking research community. + That intercomputer networking research community in turn has, + with a few recent exceptions, adhered to its commitment to the + Oral Tradition and not taken up the cudgels against X.25 in the + open literature, even though X.25 is an object of considerable + scorn in personal communications. + + Although the DoD Protocol Standards Technical Panel has + begun to evolve a "Reference Model" different from ISO's for + reasons which will be touched on below, there seems to be a need + to address the deficiencies of X.25 on their own demerits as soon + as possible. Without pretending to completeness*, this paper will + attempt to do just that. + + The overall intent is to deal with X.25 in the abstract; + because of who pays the bills, though, a necessary preliminary is + to at least sketch the broad reasons why the DoD in particular + should not + + ________________ + * Various versions of X.25 and ISO documentation were employed; + one incompleteness of note, however, is that no attempt has + been made to do proper bibliographic citation. Another + incompleteness lies in the area of "tutoriality"; that is, + appropriate prior knowledge is assumed on the part of the + reader. (The author apologizes for the omissions but hasn't + the time or the energy to be overly scholarly. Reference [3] + might be of use to the reader who feels slighted.) + + + + + + 1 + RFC 874 September 1982 + + + employ intercomputer networks which base their protocol suites on + the ISO Reference Model (ISORM) with X.25 as Levels 1-3. (Note + that this is a different formulation from "use communications + subnetworks which present an X.25 interface.") Very briefly, the + DoD has concerns with "survivability," reliability, security, + investment in prior art (i.e., its research community has a + working protocol suite in place on many different operating + systems), procurability (i.e., ISORM-related protocol suites do + not as yet fully exist even on paper and the international + standardization process is acknowledged even by its advocates to + require several years to arrive at full suite specification, much + less offer available interoperable implementation), and + interoperability with a much wider range of systems than are ever + likely to receive vendor-supplied implementations of ISORM + protocol suites. Regardless of which particular concerns are + considered to dominate, the DoD cannot be expected to await + events in the ISO arena. (Particularly striking is the fact that + DoD representatives are not even permitted under current doctrine + to present their specific concerns in the area of security in the + sort of unclassified environment the ISO arena constitutes.) + + Some zealous ISORM advocates have suggested that the DoD + research community suffers from a "Not Invented Here" syndrome + with respect to ISORM-related protocols, though, so even if the + various reasons just cited were to prevail, there would still be + an open issue at some level. At least one or two zealous members + of the research community have asserted that the problem is not + Not Invented Here, but Not Invented Right, so an assessment of + the apparent keystone of the ISORM suite, X.25, from the + perspective of whether it's "good art" ought to be appropriate. + That's what we're up to here. + + + + + + + + + + + + + + + + + + + + + + + + + 2 + RFC 874 September 1982 + + + Problems With the Conceptual Model* + + There is confusion even amongst its advocates as to the real + conceptual model of X.25-based ISO networking. Some draw their + Reference Model as two "highrises," others draw "parking + garages" beside each highrise. That is, some draw the seven + ISORM layers in large rectangles (representing Hosts) next to one + another, showing each layer in communication with its "peer" in + the other Host/Open System; this implies an "end-to-end" view of + X.25. Others draw smaller rectangles between the larger ones, + with Levels 1-3 having peer relationships from the Host-OS ("Data + Terminal Equipment") to the Comm Subnet Node ("Data Circuit + Terminating Equipment"); this implies a "link-by-link" view of + X.25. This ambiguity does not engender confidence in the + architects, but perhaps the real problem is with the spectators. + Yet it is indisputable that when internetting with X.75, the + model becomes "hop-by-hop" (and it is likely it's meant to be + link-by-link even on a single comm subnet). + + A major problem with such a model is that the designers have + chosen to construe it as requiring them to break the "virtual + circuit" it is supposed to be supporting whenever there is + difficulty with any one of the links. Thus, if internetting, and + on some interpretations even on one's proximate net, rerouting of + messages will not occur when needed, and all the upper levels of + protocols will have to expend space-time resources on + reconstituting their own connections with their counterparts. + (Note that the success of the reconstitution under DCE failure + appears to assume a certain flexibility in routing which is not + guaranteed by the Model.) This can scarcely be deemed sound + design practice for an intercomputer networking environment, + although many have conjectured that it probably makes sense to + telephonists. + + ________________ + * Note that we are assuming an ISO-oriented model rather than a + CCITT-oriented one (X.25/X.28/X.29) because the latter appears + to offer only "remote access" functionality whereas the sort + of intercomputer networking we are interested in is concerned + with the full "resource-sharing" functionality the former is + striving for. This might be somewhat unfair to X.25, in that + it is taking the protocol(s) somewhat out of context; however, + it is what ISO has done before us, and if what we're really + accomplishing is a demonstration that ISO has erred in so + doing, so be it. As a matter of fact, it can also be argued + that X.25 is itself somewhat unfair--to its users, who are + expecting real networking and getting only communication; cf. + Padlipsky, M. A., "The Elements of Networking Style", M81-41, + The MITRE Corporation, October 1981, for more on the extremely + important topic of resource sharing vs. remote access. + + + + + + 3 + RFC 874 September 1982 + + + Indeed, it appears the virtual circuit metaphor is in some + sense being taken almost literally (with the emphasis on the + "circuit" aspect), in that what should be an environment that + confers the benefits of packet-switching is, at the X.25 level, + reduced to one with the limitations of circuit-switching. On the + other hand, the metaphor is not being taken literally enough in + some other sense (with the emphasis on the "virtual" aspect), for + many construe it to imply that the logical connection it + represents is "only as strong as a wire." Whether the whole + problem stems from the desire to "save bits" by not making + addresses explicitly available on a per-transmission basis is + conjectural, but if such be the case it is also unfortunate. + + (As an aside, it should be noted that there is some evidence + that bit saving reaches fetish--if not pathological--proportions + in X.25: For instance, there does not even appear to be a Packet + Type field in data packets; rather--as best we can determine--for + data packets the low order bit of the "P(R)" field, which + overlaps/stands in the place of the Packet Type is always 0, + whereas in "real" Packet Type fields it's always 1. [That may, + by the way, not even be the way they do it--it's hard to tell ... + or care.]) + + There is also confusion even amongst its advocates as to + what implications, if any, the protocol(s) has (have) for comm + subnet node to comm subnet node (CSN) processing. Those who draw + just two highrises seem to be implying that from their + perspective the CSN (or "DCE") is invisible. This might make a + certain amount of sense if they did not assert that each floor of + a highrise has a "peer-relationship" with the corresponding floor + of the other highrise--for to do so implies excessively long + wires, well beyond the state of the wire-drawing art, when one + notices that the first floor is the physical level. (It also + appears to disallow the existence of concatenated comm subnets + into an internet, or "catenet," unless the CSN's are all + identically constituted. And those who hold that the ISORM + dictates single protocols at each level will have a hard time + making an HDLC interface into a Packet Radio Net, in all + probability.) + + Those who, on the other hand, "draw parking garages," seem + to be dictating that the internal structure of the CSN also + adhere to X.25 link and physical protocols. This implies that + Packet Radio or satellite CSNs, for example, cannot "be X.25." + Now that might be heartening news to the designers of such comm + subnets, but it presumably wasn't intended by those who claim + universality for X.25--or even for the ISO Reference Model. + + + + + + + + + 4 + RFC 874 September 1982 + + + Even granting that ambiguities in the conceptual model do + not constitute prima facie grounds for rejecting the protocol(s), + it is important to note that they almost assuredly will lead to + vendor implementations based on differing interpretations that + will not interoperate properly. And the unambiguous position that + virtual circuits are broken whenever X.25 says so constitutes a + flaw at least as grave as any of the ambiguities. + + Another, in our view extremely severe, shortcoming of the + X.25 conceptual model is that it fails to address how programs + that interpret its protocol(s) are to be integrated into their + containing operating systems. (This goes beyond the shortcoming + of the X.25 specifications in this area, for even the advocates + of the ISORM--who, by hypothesis at least, have adopted X.25 for + their Levels 1-3--are reticent on the topic in their literature.) + Yet, if higher level protocols are to be based on X.25, there + must be commonality of integration of X.25 modules with operating + systems at least in certain aspects. The most important example + that comes to mind is the necessity for "out-of-band signals" to + take place. Yet if there is no awareness of that sort of use + reflected in the X.25 protocol's specification, implementers need + not insert X.25 modules into their operating systems in such a + fashion as to let the higher level protocols function properly + when/if an X.25 Interrupt packet arrives. + + Yet much of the problem with the conceptual model might turn + out to stem from our own misunderstandings, or the + misunderstandings of others. After all, it's not easy to infer a + philosophy from a specification. (Nor, when it comes to + recognizing data packets, is it easy even to infer the + specification--but it might well say something somewhere on that + particular point which we simply overlooked in our desire to get + the spec back on the shelf rapidly.) What other aspects of X.25 + appear to be "bad art"? + + "Personality Problems" + + When viewed from a functionality perspective, X.25 appears + to be rather schizophrenic, in the sense that sometimes it + presents a deceptively end-to-end "personality" (indeed, there + are many who think it is usable as an integral Host-Host, or + Transport, and network interface protocol, despite the fact that + its specification itself--at least in the CCITT "Fascicle" + version--points out several functional omissions where a + higher-level protocol is expected--and we have even spoken to one + or two people who say they actually do -- use it as an end-to-end + protocol, regardless); sometimes it presents a comm subnet + network interface personality (which all would agree it must); + and sometimes (according to some observers) it presents a + + + + + + + 5 + RFC 874 September 1982 + + + "Host-Front End Protocol" personality. Not to push the "bad art" + methaphor too hard, but this sort of violation of "the Unities" + is, if demonstrable, grounds for censure not only to literary + critics but also to those who believe in Layering. Let's look at + the evidence for the split-personality claim: + + X.25 is not (and should not be) an "end-to-end" protocol in + the sense of a Transport or Host-to-Host protocol. Yet it has + several end-to-end features. These add to the space-time expense + of implementation (i.e., consume "core" and CPU cycles) and + reflect badly on the skill of its designers if one believes in + the design principles of Layering and Least Mechanism. (Examples + of end-to-end mechanisms are cited below, as mechanisms + superfluous to the network interface role.) The absence of a + datagram mode which is both required and "proper" (e.g., not Flow + Controlled, not Delivery Confirmed, not Non-delivery mechanized) + may also be taken as evidence that the end-to-end view is very + strong in X.25. That is, in ISO Reference Model (ISORM) terms, + even though X.25 "is" L1-3, it has delusions of L4-ness; in + ARPANET Reference Model (ARM) terms, even though X.25 could "be" + L I, it has delusions of L II-ness.* + + X.25 is at least meant to specify an interface between a + Host (or "DTE") and a comm subnet processor (or "DCE"), + regardless of the ambiguity of the conceptual model about whether + it constrains the CSNP "on the network side." (Aside: that + ambiguity probably reflects even more badly on certain X.25 + advocates than it does on the designers, for there is a strong + sense in which "of course it can't" is the only appropriate + answer to the question of whether it is meant to constrain + generic CSN processors (CSNP's) in the general case. Note, + though, that it might well be meant to constrain specific DCE's; + that is, it started life as a protocol for PTT's--or Postal, + Telephone, and Telegraph monopolies--and they are presumably + entitled to constrain themselves all they want.) Yet the + end-to-end features alluded to above are redundant to the + interfacing role, and, as noted, extraneous features have + space-time consequences. There are also several features which, + though not end-to-end, seem superfluous to a "tight" interface + protocol. Further, the reluctance of the designers to + incorporate a proper "datagram" capability in the protocol (what + they've got doesn't seem to be + + ________________ + * For more on the ARM, see Padlipsky, M. A., "A Perspective on + the ARPANET Reference Model", M82-47, The MITRE Corporation, + September 1982; also available in Proc. INFOCOM '83. (Some + light may also be cast by the paper on the earlier-mentioned + topic of Who Invented What.) + + + + + + + 6 + RFC 874 September 1982 + + + usable as a "pure"--i.e., uncontrolled at L3 but usable without + superfluous overheard by L4--datagram, but instead entails + delivery confirmation traffic like it or not; note that "seem" is + used advisedly: as usual, it's not easy to interpret the + Fascicle) suggests at least that they were confused about what + higher-level protocols need from interfaces to CSNP's, and at + worst that there is some merit to the suggestion that, to + paraphrase Louis Pouzin, "the PTT's are just trying to drum up + more business for themselves by forcing you to take more service + than you need." + + Examples of mechanisms superfluous to the interface role: + + 1. The presence of a DTE-DTE Flow Control mechanism. + + 2. The presence of an "interrupt procedure" involving the + remote DTE. + + 3. The presence of "Call user data" as an end-to-end item + (i.e., as "more" than IP's Protocol field). + + 4. The "D bit" (unless construed strictly as a "RFNM" from + the remote DCE). + + 5. The "Q bit" (which we find nearly incomprehensible, but + which is stated to have meaning of some sort to + X.29--i.e., to at least violate Layering by having a + higher-level protocol depend on a lower level + machanism--and hence can't be strictly a network + interface mechanism). + + + + + + + + + + + + + + + + + + + + + + + + + + 7 + RFC 874 September 1982 + + + The final "personality problem" of X.25 is that some of its + advocates claim it can and should be used as if it were a + Host-Front End protocol.* Yet if such use were intended, surely + its designers would have offered a means of differentiating + between control information destined for the outboard + implementation of the relevant protocols and data to be + transmitted through X.25, but there is no evidence of such + mechanisms in the protocol. "Borrowing" a Packet Type id for + H-FP would be risky, as the spec is subject to arbitrary + alteration. Using some fictitious DTE address to indicate the + proximate DCE is also risky, for the same reason. Further, using + "Call user data" to "talk to" the counterpart H-FP module allows + only 15 octets (plus, presumably, the 6 spare bits in the 16th + octet) for the conversation, whereas various TCP and IP options + might require many more octets than that. Granted that with + sufficient ingenuity--or even by the simple expedient of + conveying the entire H-FP as data (i.e., using X.25 only to get + channels to demultiplex on, and DTE-DCE flow control, with the + "DCE" actually being an Outboard Processing Environment that gets + its commands in the data fields of X.25 data packets)--X.25 might + be used to "get at" outboard protocol interpreters, but its + failure to address the issue explicitly again reflects badly on + its designers' grasp of intercomputer networking issues. + (Another possibility is that the whole H-FP notion stems from the + use of X.25 as a Host-Host + + ________________ + * That is, as a distributed processing mechanism which allows + Host operating systems to be relieved of the burden of + interpreting higher level protocols "inboard" of themselves by + virtue of allowing Host processes to manipulate "outboard" + interpreters of the protocols on their behalf. Note that the + outboarding may be to a separate Front-End processor or to the + CSNP itself. (The latter is likely to be found in + microprocessor-based LAN "BIU's.") Note also that when + dealing with "process-level" protocols (ARM L III; + approximately ISORM L5-7), only part of the functionality is + outboarded (e.g., there must be some Host-resident code to + interface with the native File System for a File Transfer + Protocol) and even when outboarding Host-Host protocols (ARM L + II; approximately ISORM L4 plus some of 5) the association of + logical connections (or "sockets") with processes must be + performed inboard--which is why, by the way, it's annoying to + find ISO L5 below ISO L6: because, that is, you'd like to + outboard "Presentation" functionality but its protocol expects + to interact with the "Session" protocol, the functionality of + which can't be outboarded. (Although this approach, not the + proper context for a full treatment of the H-FP approach, it + is also of interest that the approach can effectively insulate + the Host from changes in the protocol suite, which can be a + major advantage in some environments.) + + + + + 8 + RFC 874 September 1982 + + + protocol so that some might think of it in its Host aspect as + "simply" a way of getting at the H-HP. This interpretation does + give rise to the interesting observation that DCE's seem to need + a protocol as strong as TCP amongst themselves, but doesn't + strike the author as particularly convincing evidence for viewing + X.25 as anything like a proper H-FP--if for no other reason than + that a central premise of Outboard Processing is that the + Host-side H-FP module must be compact relative to an inboard + generic Network Control Program.) + + X.25, then, is rather schizophrenic: It exceeds its brief + as an interface protocol by pretending to be end-to-end + (Host-Host) in some respects; it is by no means a full end-to-end + protocol (its spec very properly insists on that point on several + occasions); it's at once too full and too shallow to be a good + interface; and it's poorly structured to be treated as if it were + "just" an H-FP. (Some would phrase the foregoing as "It's + extremely ill layered"; we wouldn't argue.) + + A Note on "Gateways"* + + Although it was at least implied in the discussion of + conceptual model problems, one aspect of X.25/X.75 internetting + is sufficiently significant to deserve a section of its own: Not + only does the link-by-link approach taken by CCITT make it + unlikely that alternate routing can take place, but it is also + the case that ARPANET Internet Protocol (IP) based internetting + not only permits alternate routing but also could alt-route over + an "X.25 Subnet." That is, in IP's conceptual model, Gateways + attach to two or more comm subnets "as if they (the Gateways) + were Hosts." This means that they interpret the appropriate + Host-comm subnet processor protocol of whatever comm subnets + they're attached to, giving as the "proximate net address" of a + given transmission either the ultimate (internet addressed) + destination or the address of another Gateway "in the right + direction." And an implementation of IP can certainly employ an + implementation of ("DTE") X.25 to get a proximate net, so ... at + least "in an emergency" X.25 interface presenting Public Data + Networks can indeed carry IP traffic. (Note also that only the + proximate net's header has to be readable by the nodal processor + of/on the proximate net, so if some appropriate steps were taken + to render the data portion of such transmissions unintelligible + to the nodal processors, so much the better.) + + ________________ + * This section was added to address the ill-founded concerns of + several ISORMites that "TCP/IP won't let you use Public Data + Nets in emergencies." + + + + + + + + 9 + RFC 874 September 1982 + + + (Further evidence that X.75 internetting is undesirable is + found in the fact that the U.S. National Bureau of Standards has, + despite its nominal adoption of the ISORM, inserted IP at + approximately L3.5 in its version of the Reference Model.) + + The Off-Blue Blanket + + Although touched on earlier, and not treatable at much + length in the present context, the topic of security deserves + separate mention. We are familiar with one reference in the open + literature [1] which appears to make a rather striking point + about the utility of X.25 in a secure network. Dr. Kent's point + that the very field sizes of X.25 are not acceptable from the + point of view of encryption devices would, if correct (and we are + neither competent to assess that, nor in a position to even if we + were), almost disqualify X.25 a priori for use in many arenas. + Clearly, uncertified "DCE's" cannot be permitted to read + classified (or even "private") data and so must be "encrypted + around," after all. + + It would probably be the case, if we understand Dr. Kent's + point, that X.25 could be changed appropriately--if its + specifiers were willing to go along. But this is only one + problem out of a potentially large number of problems, and, + returning briefly to our concern with the interplay of X.25 and + the DoD, those persons in the DoD who know best what the problems + are and/or could be are debarred from discussing them with the + specifiers of X.25. Perhaps a sufficiently zealous ISORM + advocate would be willing to suggest that Professor Kuo's + publisher be subsidized to come out with a new edition whenever a + problem arises so that if Dr. Kent happens to spot it advantage + can continue to be taken of his ability to write for the open + literature--but we certainly hope and trust that no ISORMite + would be so tone-deaf as to fail to recognize the facetiousness + of that suggestion. + + In short, it appears to be difficult to dispute the + assertion that whatever sort of security blanket X.25 could + represent would at best be an off shade of blue. + + Space-Time Considerations + + Another topic touched on earlier which deserves separate + mention, if only to collect the scattered data in a single + section, is that of what have been called space-time + considerations. That is, we are concerned about how well X.25 in + particular and the ISORM-derived protocols in general will + implement, both in terms of size of protocol interpreters (PI's) + and in terms of execution and delay times. + + + + + + + 10 + RFC 874 September 1982 + + + On the space heading, certainly the fact that X.25 offers + more functionality in its end-to-end guise than is required to + fulfill its network interface role suggests that X.25 PI's will + be bigger than they need be. As an aside--but a striking one--it + should be noted that X.25's end-to-end functions are at variance + with the ISORM itself, for the "peer entity" of a DTE X.25 entity + must surely be the local DCE X.25. Perhaps a later version of + the ISORM will introduce the polypeer and give rise to a whole + new round of Layering-Theologic controversy.* Speaking of the + ISORM itself, those who hold that each layer must be traversed on + each transmission are implicitly requiring that space (and time) + be expended in the Session and Presentation Levels even for + applications that have no need of their services. The Well-Known + Socket concept of the ARM's primary Host-Host protocol, the + Transmission Control Protocol (TCP), lets Session functionality + be avoided for many applications, on the other hand--unless ISORM + L5 is to usurp the Host's user identification/authentication role + at some point. (Yes, we've heard the rumors that "null layers" + might be introduced into the ISORM; no, we don't want to get into + the theology of that either.) + + On the time heading, X.25's virtual circuit view can be + debilitating--or even crippling--to applications such as + Packetized Speech where prompt delivery is preferred over ordered + or even reliable delivery. (Some hold that the X.25 datagram + option will remedy that; others hold that it's not "really + datagrams"; we note the concern, agree with the others, and pass + on.) Speaking of reliable delivery, as noted earlier some + observers hold that in order to present an acceptable virtual + circuit X.25 must have a protocol as strong as TCP "beneath" + itself; again, we're in sympathy with them. Shifting focus again + to the ISORM itself, it must be noted that the principle that + "N-entities" must communicate with one another even in the same + Host via "N-1 entities" even in the same Host is an over-zealous + application of the Principle of Layering that must consume more + time in the interpreting of the N-1 protocol than would a direct + interface between N-level PI's or such process-level protocols as + FTP and Telnet, as is done in the ARPANET-derived model. + + Other space-time deficiencies could be adduced, but perhaps + a shortcut will suffice. There is a Law of Programming + (attributed to Sutherland) to the effect that "Programs are like + waffles: you should always throw the first one out." Its + relevance should become + + ________________ + * And perhaps we now know why some just draw the highrises. + + + + + + + + + 11 + RFC 874 September 1982 + + + clear when it is realized that (with the possible exception of + X.25) ISORM PI's are in general either first implementations or + not even implemented yet (thus, the batter, as it were, is still + being mixed). Contrast this with the iterations the + ARPANET-derived PI's--and, for that matter, protocols--have gone + through over the years and the grounds for our concern over + X.25/ISORM space-time inefficiency become clear irrespective of + corroborative detail. Factor in the consideration that space-time + efficiency may be viewed as contrary to the corporate interests + of the progenitors of X.25 ("the PTT's") and at least the current + favorite for ISORM Level 4 (ECMA--the European Computer + Manufacturers' Association), and it should become clear why we + insist that space-time considerations be given separate mention + even though touched upon elsewhere.* + + Getting Physical + + Still another area of concern over X.25 is that it dictates + only one means of attaching a "DTE" to a "DCE." That is, earlier + references to "the X.25 protocol(s)" were not typographical + errors. Most of the time, "X.25" refers to ISORM Level 3; + actually, though, the term subsumes L2 and L1 as well. Indeed, + the lowest levels constitute particular bit serial interfaces. + This is all very well for interfacing to "Public Data Nets" + (again, it must be recalled that X.25's roots are in CCITT), but + is scarcely appropriate to environments where the communications + subnetwork may consist of geosynchronous communications satellite + channels, "Packet Radios," or whatever. Indeed, even for + conventional Local Area Networks it is often the case that a + Direct Memory Access arrangement is desired so as to avoid + bottlenecking--but DMA isn't HDLC, and the "vendor supported X.25 + interface" so prized by some won't be DMA either, one imagines. + (Speaking of LAN's, at least the evolving standard in that + arena--"IEEE 802"--apparently will offer multiple physical + interfaces depending on comm subnet style [although there is some + disagreement on this point amongst readers of their draft specs]; + we understand, however, that their Level 2 shares X.25's end-end + aspirations--and we haven't checked up on DMA capability.) X.25, + then, imposes constraints upon its users with regard to interface + technology that are inappropriate. + + ________________ + * The broad issue of design team composition is amplified in + Padlipsky, M. A., "The Illusion of Vendor Support", M82-49, + The MITRE Corporation, September 1982. + + + + + + + + + + + 12 + RFC 874 September 1982 + + + Other Observers' Concerns + + This paper owes much to conversations with a number of + people, although the interpretations of their concerns are the + author's responsibility. Mention should be made, however, of a + few recent documents in the area: The Defense Communications + Agency (DCA Code J110) has sent a coordinated DoD position [2] to + NBS holding that X.25 cannot be the DoD's sole network interface + standard; Dr. Vinton Cerf of the ARPA Information Processing + Technology Office made a contribution to the former which + contains a particularly lucid exposition of the desirability of + proper "datagram" capability in DoD comm subnets [3]; Mr. Ray + McFarland of the DoD Computer Security Evaluation Center has also + explored the limitations of X.25 [4]. Whether because these + authors are inherently more tactful than the present author, or + whether their positions are more constraining, or even whether + they have been more insulated from and hence less provoked by + uninformed ISORMite zealots, none has seen fit to address the + "quality" of X.25. That this paper chooses to do so may be + attributed to any one of a number of reasons, but the author + believes the key reason is contained in the following: + + Conclusion + + X.25 is not a good thing. + + References + + [1] Kent, S. T., "Security in Computer Networks," in Kuo, F., + Ed., Protocols and Techniques for Data Communications + Networks, Prentice-Hall, 1981, pp. 369-432. + + [2] Letter to NBS from P. S. Selvaggi, Chief, Interoperability + and Standards Office, 7 April 1982. + + [3] Cerf, V. G., "Draft DoD Position Regarding X.25" in undated + letter to P. S. Selvaggi. + + [4] Personal communications. + + + + + + + + + + + + + + + + + 13 \ No newline at end of file -- cgit v1.2.3