Zusammenfassung

  • RFC 873 stellte die Hoffnung infrage, das US-Verteidigungsministerium könne bei anstehenden Netzbeschaffungen einfach auf ein späteres, vom Hersteller geliefertes Protokollpaket nach dem ISO-Referenzmodell warten.
  • Wenn zwei Anbieter erlaubte Optionen verschieden auslegen, können beide guten Gewissens liefern und der Käufer trotzdem die Anpassung bezahlen müssen.

Auf einem Angebot macht sich „Herstellerunterstützung“ hervorragend. In einer laufenden Verbindung muss die Unterstützung jedoch eine sehr unromantische Frage beantworten: Schickt die eine Maschine etwas, das die andere versteht? Michael A. Padlipsky nahm sich diesen Unterschied in seiner RFC 873 vom September 1982 vor. Im US-Verteidigungsministerium wurde darüber gesprochen, bei Netzbeschaffungen auf vom Hersteller gelieferte Protokolle nach dem ISO-Referenzmodell zu warten. Die Hoffnung auf geringere Staatsausgaben fand Padlipsky nachvollziehbar. Er wollte nur die komplette Rechnung sehen.

Sein erster Posten betraf den Inhalt der Lieferung. X.25 war damals ein greifbarer Name, deckte für Padlipsky aber nur einen Teil des Weges ab. Wer Ressourcen zwischen Rechnern teilen wollte, brauchte weitere Funktionen und Absprachen. Die Arbeit des National Bureau of Standards und jene der International Organization for Standardization ergaben zudem nicht einfach dasselbe Paket. „Das Protokollpaket“ klang auf einem Bestellformular wie ein fertiger Gegenstand. Tatsächlich lagen noch unterschiedliche Baupläne auf den Tischen.

Einen Karton kann man etikettieren, bevor sein Inhalt fertig ist; ein Netz wird dadurch keinen Tag früher betriebsbereit.

Dann kam die Uhr. Beschaffungsverfahren des Ministeriums hatten lange Vorläufe. Gleichzeitig war das Paket nach dem ISO-Modell im Jahr 1982 noch unvollständig; Teile existierten nach Padlipskys Darstellung erst als Vorschläge. Normung brauchte Zeit, während Verträge bereits vorbereitet wurden. Protokolle nach dem ARPANET-Modell liefen dagegen auf mehreren Betriebssystemen, die das Ministerium verwendete. Ihr Betrieb und ihre Pflege hatten Kosten. Für den damaligen Käufer zählte aber auch der Liefertermin: Eine vorhandene Implementierung ließ sich anders bestellen als eine noch offene Sammlung künftiger Festlegungen.

Padlipsky beschrieb einen Vorsprung, keine gemessene Zahl von eingesparten Monaten.

Besonders unbequem wurde seine Frage beim Wort „unterstützt“. Ein Referenzmodell ordnet Funktionen in Schichten. Für einen konkreten Kauf muss darüber hinaus klar sein, was an deren Grenzen passiert. Welche Bedeutung hat eine dringende Datenmeldung für die Anwendung? Muss jeder Vorgang sämtliche Schichten durchlaufen? Wie viele Protokolle dürfen in einer Schicht nebeneinander existieren? Die RFC 873 führte solche Fragen auf, weil eine Architekturübersicht noch keinen gemeinsamen Test für zwei ausgelieferte Produkte ersetzt. Wenn die Antworten offenbleiben, wächst aus einer Zeile im Vertrag später ein Stapel Nachträge.

Am deutlichsten zeigte Padlipsky das an optionalen Funktionen. Ein Hersteller nutzt eine laut Spezifikation erlaubte Option; der andere lässt sie weg. Beide können den Text sorgfältig lesen und ehrlich behaupten, ihn einzuhalten. Ihre Produkte kommen beim Käufer an, treffen sich im Netz und brauchen plötzlich zusätzliche Arbeit. Vielleicht muss eine Einstellung geändert, vielleicht Code geschrieben werden. Der Käufer hat den Bedarf an Verbindung; deshalb erwartete Padlipsky, dass die Kosten am Ende bei ihm landen. Die Option war in der Norm freiwillig. Die Rechnung für ihre Folgen kann sehr verbindlich ausfallen.

Padlipsky rechnete auch die Ressourcen der Rechner mit. Protokolle benötigen Speicher und Prozessorzeit, also gerade Kapazitäten, die das Netz zur gemeinsamen Nutzung erschließen sollte. Er diskutierte den Aufwand, den zusätzliche Schichtdurchläufe und Zustände verursachen können, und erzählte von einer älteren Erfahrung mit häufigen Prüfmeldungen und einer Multics-Rechnung. Diese Episode belegt keine allgemeine Geschwindigkeitszahl für spätere Produkte. Sie zeigt, warum ein Einkäufer vor Vertragsabschluss wissen möchte, wie die Software unter Last arbeitet.

Ein kostenlos geliefertes Programm kann auf einer teuren Maschine einen erstaunlich anspruchsvollen Appetit entwickeln.

Sein Ton war spöttisch, das Problem schlicht: Wartung, Rechenzeit, Speicher und die Reparatur unvereinbarer Implementierungen sind verschiedene Kostenarten. Hersteller mussten für die Schwierigkeiten keine Schurken sein. Zwei kompetente Teams konnten an verschiedenen Stellen vernünftige Entscheidungen treffen und dennoch erst beim gemeinsamen Einsatz erfahren, dass ihre Entscheidungen kollidierten. In der Schlussbetrachtung erwähnte Padlipsky, dass mehr Anbieter bereits TCP/IP lieferten oder dies planten. Auch die angenommene Wahl zwischen einer Herstellermarke und vorhandenen ARPANET-Protokollen begann sich damit zu verändern.

Die RFC 873 hält einen Beschaffungsstreit aus dem Jahr 1982 fest. Ihre gute Frage passt genau in diesen Moment: Was läuft heute auf den vorgesehenen Maschinen, welche Teile kommen erst später, welche Optionen sind auf beiden Seiten vorhanden und wer trägt die Anpassung? Der Einkauf kann einen Hersteller verpflichten. Zwei Systeme müssen sich trotzdem über ihr Verhalten einigen.