Browse Prior Art Database

Illusion of vendor support (RFC0873) Disclosure Number: IPCOM000003922D
Original Publication Date: 1982-Sep-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 8 page(s) / 23K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

M.A. Padlipsky: AUTHOR

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 13% of the total text.


< INC-PROJECT, MAP-ILLUSION.NLS.8, >, 12-Aug-83 11:44 AMW ;;;;

RFC 873 September 1982





Bedford, Massachusetts


The sometimes-held position that "vendor supplied"

intercomputer networking protocols based upon the International

Standards Organization's Reference Model for Open System

Interconnection are worth waiting for, in particular in

preference to protocols based upon the ARPANET Reference Model

(ARM), is shown to be fallacious.

The paper is a companion piece to M82-47, M82-48, M82-50,

and M82-51.



M. A. Padlipsky


Even one or two members of the DoD Protocol Standards

Technical Panel join with many others (including, apparently,

some members of the DoD Protocol Standards Steering Group, and

clearly, somebody at the GAO) in expressing a desire to "go with

vendor-supported intercomputer networking protocols instead of

using our own." The author's view of the implications of this

desire should be clear from the title of this paper. What

evidence, then, is there to so stigmatize what is clearly a

well-meant desire to save the Government money?


First, we must consider what is meant by "vendor-supported

protocols." It can't be just X.25, because that only gets you

through the network layer whether you're appealing to the

International Standards Organization's widely-publicized

Reference Model for Open System Interconnection (ISORM) or to the

unfortunately rather tacit reference model (ARM) to which the

ARPANET protocols (e.g., TCP, IP, Telnet, FTP) were designed. It

also can't be just X.25 and X.28/X.29 (even with X.75 tossed in

to handle "internetting" and X.121 for addressing) because: 1.

They don't serve as a protocol suite for resource sharing (also

known as OSI), but rather only allow for remote access [1]. 2.

They (coming as they do from the Consultative Committee on

International Telegraphy and Telephony--and including one or two

other protocols, in reality) don't even constitute the full

protocol suite being worked on by the U. S. National Bureau of

Standards, much less the somewhat different suite being evolved

by ISO. So it must be a suite from NBS or ISO, and for present

purposes we needn't differentiate between them as their Reference

Models are close enough to be shorthanded as the ISORM.


Realizing that we're being asked to consider an

ISORM-related protocol suite as wh...