Zusammenfassung

  • John Day beschrieb das OSI-Referenzmodell in seiner mündlichen Rückschau als Rahmen für die Normungsarbeit, die darauf folgen sollte – nicht als Anweisung, einen festen Protokollstapel umzusetzen.
  • RINA schlug später eine rekursive IPC-Architektur vor; ProtoRINA erprobte eine begrenzte Implementierung. Die genannten Quellen belegen weder eine breite Einführung im Produktivbetrieb noch völlige Nichtnutzung.

Eine Zeichnung ist noch kein Rollout-Plan

Das Sieben-Schichten-Bild wirkt wie eine Aufgabenliste: unten anfangen, Schicht für Schicht bauen, am Ende das fertige Netz erhalten. John Days Rückblick deutet auf eine andere Funktion. In einer 2010 aufgezeichneten Oral History des Computer History Museum beschrieb er das OSI-Referenzmodell als Rahmen für die folgende Normungsarbeit, nicht als Implementierungsdokument. Das ist Days rückblickende Deutung – weder ein Wortlaut des Standards noch ein Ersatz für Sitzungsprotokolle.

Sie macht jedoch eine wichtige Grenze sichtbar: Ein gemeinsames Modell kann Funktionen benennen und Ausschüsse auf ein Vokabular bringen, ohne die Architektur jedes Produkts oder den Einsatzzeitplan eines Netzbetreibers festzulegen.

Day war an dieser Normungsarbeit beteiligt. In einem Interview der Boston University erinnerte er daran, Rapporteur des OSI-Referenzmodells gewesen zu sein und den ANSI-Ausschuss für OSI-Architektur geleitet zu haben. Die Oral History hält außerdem seine Schilderung der US-Delegation und der frühen Beratungen fest. Das verortet ihn in einem kollektiven Prozess; es macht ihn weder zum alleinigen Urheber von OSI noch aus dem Ausschussrahmen einen Befehl an alle Betreiber.

Diese Unterscheidung schützt vor überzogenen Vorstellungen von Normungsmacht. Ein Referenzmodell kann gemeinsame Begriffe schaffen, ein kompliziertes Problem in diskutierbare Funktionen zerlegen und Vorschläge verschiedener Organisationen koordinierbar machen. Es finanziert aber keine Entwicklung, plant keine Migration, löst keine Kompatibilität mit installierter Technik und schafft keinen geschäftlichen Wechselanreiz. Darüber entscheiden Implementierer und Betreiber unter ihren jeweiligen Bedingungen. Wer Beschreibung mit Anordnung verwechselt, stellt Normen als zwingender und Einführung als automatischer dar, als es die Quellen hergeben.

RINA schlug Rekursion vor

Days spätere Arbeit ergänzte OSI nicht einfach um eine achte Schachtel. Im Aufsatz „Networking is IPC“ von 2008 schlugen Day, Ibrahim Matta und Karim Mattar vor, Kommunikation als Inter-Process Communication (IPC) zu verstehen. Anwendungen verwenden eine IPC-Funktion; diese kann ihrerseits Dienste einer darunterliegenden IPC-Funktion anfordern. Die Wiederholung derselben Grundidee bildet den architektonischen Kern. Das ist ein Entwurfsvorschlag, keine Erhebung dazu, welche Netze ihn bereits einsetzen.

Das RINA-Projekt der Boston University beschreibt eine Distributed IPC Facility (DIF) als wiederkehrende Einheit und erklärt, wie konfigurierbare Richtlinien ihren Betrieb steuern sollen. Das ist die Darstellung des Entwicklerteams. Sie erklärt dessen Modell, ist aber keine unabhängige Leistungsbewertung und beweist nicht, dass RINA andere Architekturen verdrängt oder sämtliche Betriebsprobleme gelöst hat.

ProtoRINA macht den Schritt vom Entwurf zur Implementierung greifbar. Ein Aufsatz von Wang, Matta, Esposito und Day aus dem Jahr 2014 stellt einen Prototyp im Userspace vor und berichtet von Tests auf dem Campus der Boston University und der Forschungs-Testumgebung GENI. Der Text bezeichnet sich ausdrücklich als nicht begutachtete Editorial Note. Er beschreibt außerdem eine unvollständige Implementierung und einen TCP-Shim für Verbindungen der Ebene null. Gerade diese Grenzen bestimmen, was der Befund aussagt: Ein Teil des Entwurfs wurde gebaut und in benannten Umgebungen erprobt.

Er belegt keine allgemeine kommerzielle Einführung, keinen Ersatz des öffentlichen Internets und keine Überlegenheit gegenüber anderen Ansätzen.

Es bleiben drei getrennte Fragen: Was definiert ein Modell? Was lief in einer konkreten Implementierung? Welche unabhängigen Netze haben die Technik wann, wie lange und in welchem Umfang übernommen? Days Oral History hilft bei der ersten Frage, der RINA-Aufsatz formuliert einen Architekturvorschlag, ProtoRINA dokumentiert ein begrenztes Experiment. Die hier geprüften Quellen liefern keine vollständige Bestandsaufnahme der Einführung. Daraus folgt weder „RINA ist überall“ noch „RINA wurde nie genutzt“.

Koordination ist kein Einsatzbefehl

Die nützliche Lehre aus Days Laufbahn ist kein endgültiges Urteil über sieben Schichten oder rekursive IPC. Sie liegt in der Grenze zwischen gemeinsamer Spezifikation und lokaler Entscheidung. Normung kann Schnittstellen zwischen Organisationen verständlich machen. Betreiber müssen weiterhin prüfen, ob ein Modell zu ihrer Technik, ihren Diensten, ihren Teams, ihrer Risikotoleranz und ihrem Erneuerungszyklus passt. Ein Prototyp kann Unsicherheit darüber senken, ob Code in einer Testumgebung läuft; erst Einführungsbelege zeigen, wer die Betriebskosten trug und was im Produktivbetrieb Bestand hatte.

Wer Infrastruktur bewertet, sollte für jede Behauptung den passenden Nachweis verlangen. Ein Modell braucht einen erklärten Geltungsbereich und Zweck. Ein Prototyp braucht Angaben zu Codezustand, Umgebung, Tests und offenen Funktionen. Eine Behauptung über den Einsatz im Produktivbetrieb muss Netze, Zeiträume und Rollen benennen und Versuche von dauerhaftem Dienst unterscheiden. Ohne diese Unterlagen kann eine Foliengrafik eine Autorität erhalten, die weder Ausschuss noch Aufsatz noch Experiment verliehen haben.

Quellen