Critique of X.25
RFC 874

Document Type RFC - Unknown (September 1982; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 874 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)

     < INC-PROJECT, MAP-CRITIQUE.NLS.10, >, 12-Aug-83 11:46 AMW ;;;;


     RFC 874                                            September 1982

                            A CRITIQUE OF X.25



                              M.A. PADLIPSKY
                           THE MITRE CORPORATION
                          Bedford, Massachusetts




          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.


                            A CRITIQUE OF X.25

                              M. A. Padlipsky


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


     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
Show full document text