Summary

  • RFC 873 argued that waiting for vendor-supplied networking protocols based on the ISO reference model did not solve the Defense Department’s immediate procurement and interoperability problem in 1982.
  • Its sharpest test was practical: an incomplete suite, ambiguous interfaces and optional features could leave two good-faith vendor implementations needing paid repair before they worked together.

“Vendor supported” sounds like a plan until the purchasing office asks what, exactly, will arrive. In RFC 873, Michael A. Padlipsky put that question to a 1982 debate inside U.S. Defense Department networking procurement. Some officials wanted protocols supplied by vendors rather than the ARPANET-model suite already in use. The hope, as Padlipsky described it, was to save government money. His answer was less comforting: a supplier’s name on the box would not finish the missing layers, settle the choices between implementations or pay for making the results interoperate.

He began by asking what the proposed purchase contained. X.25 by itself, he argued, did not provide a complete protocol suite for sharing resources between computers. Adding nearby access and addressing specifications still did not equal the full suite under discussion at the National Bureau of Standards or the International Organization for Standardization. Those efforts were not identical, either. A buyer who wrote “vendor-supported networking” into a requirement could discover that the apparent product was a collection of partly different plans. The box in the catalogue was tidier than the standards work behind it.

Time was the first bill. Defense procurement already had long lead times, while Padlipsky said the ISO-model suite was incomplete in September 1982. Some components were proposals at lower or upper layers, awaiting the test of actual use. Standards processes would take years. At the same time, the department was issuing networking contracts, and ARPANET-model protocols existed on operating systems it already used. Maintainers had to deal with code, specifications and operating-system releases. The available running suite could, in Padlipsky’s assessment, be procured sooner than a complete future one.

The second bill was hidden inside the word “support.” Padlipsky listed questions a vendor would have to answer before a customer could infer interoperability from conformance: what service crossed each layer boundary, whether every layer had to be traversed, how many protocol choices lived inside one layer, and what an application could do with an expedited signal. A reference model could help people describe a system while leaving enough room for two conforming products to behave differently. In his account, that room was expensive. It had to be closed with common decisions and testing after procurement.

Optional features made the problem easy to picture. Suppose one supplier’s implementation relied on an option that another supplier chose not to provide. Both could have acted in good faith. Their customers would still have to change a configuration, replace software or fund engineering work. Padlipsky’s question was who would get that invoice. He suspected it would not be either supplier. That is a pointed purchasing argument, with a technical mechanism underneath: optionality transfers a compatibility decision from the specification writer to the pair of systems that must communicate.

He worried about the cost of running the software, too. CPU time and memory were resources the network was meant to help share, not free materials for a protocol stack to consume. The essay questioned design rules that might force traffic through every conceptual layer or multiply processing state. It also recounted a historical probing anecdote whose lesson was operational: a small repeated control exchange can become costly when every machine performs it. The specific anecdote did not measure every proposed suite. It forced a buyer to ask for resource-use evidence alongside a promise of standards alignment.

Padlipsky wrote with a sharp pen, but he did not need a theory of bad vendors to make the case. His essay said the design environment might simply fail to reward small, efficient implementations. Its closing joke was that there is no free lunch: even if vendor maintenance looked cheaper on a purchase order, interoperability work, processor time and memory could return as other costs. The paper also observed that more vendors were supplying or preparing to supply TCP/IP. That observation complicated the neat choice between vendor support and the ARPANET suite even as the argument was being made.

RFC 873 preserves a 1982 decision in the making. It shows what Padlipsky wanted a buyer to inspect: which complete suite existed, how long the procurement clock ran, what two implementations would do with the same options, and who would bear the cost when their answers differed. A label could promise a vendor relationship. Packets still needed a working agreement.