Einleitung
Bill Crowthers RFC Nr. 67 hat eine viel grundlegendere Frage aufgeworfen als die der Markierung. Jede Änderung des derzeit etablierten Protokolls wird Änderungen an den Hardware-/Software-Entwicklungsarbeiten mit sich bringen, die in manchen Fällen seit über 6 Monaten laufen. Im Fall von Multics hat diese Arbeit Programme hervorgebracht, die entweder vollständig sind oder sich in fortgeschrittenen Fehlersuche-Stadien befinden. Dies gilt zweifellos auch für viele andere Standorte.
Die hier entwickelten Argumente besagen nicht, dass das derzeitige Protokoll ideal ist, sondern vielmehr, dass alle sich darauf geeinigt haben, dass es funktionsfähig ist, und mit seiner Implementierung begonnen haben. Wir möchten daher ein Moratorium für die meisten Änderungen an diesem Protokoll für die nächsten 6 Monate vorschlagen, oder jedoch so lange, wie es dauert, dieses System zum Laufen zu bringen und seine Eigenschaften zu beobachten.
Konkret bedeutet dies, keine Änderungen vorzunehmen, die nur die Effizienz oder die Leichtigkeit der Implementierung betreffen. Wird ein größeres Entwurfsproblem aufgedeckt, sollte es weiterhin zur Erörterung vorgelegt werden, ebenso wie Fragen, die Erweiterungen des bestehenden Systems darstellen. Änderungen an den Details des derzeitigen Systems sollten jedoch nicht vorgenommen werden.
Es gibt mehrere Punkte, die zugunsten dieses Arguments angeführt werden können. Der erste und vielleicht wichtigste ist, das System so schnell wie möglich zum Laufen zu bringen. Der Hauptnutzen des Netzwerks liegt in den Verwendungen, für die es eingesetzt wird, und eine Entwicklung in dieser Richtung kann nicht wirklich in Gang kommen, bevor das Netzwerk betriebsbereit ist. Wir sind der Ansicht, dass, obwohl der Aufwand, einen Teil des NCP zu einem späteren Zeitpunkt neu zu programmieren, zweifellos größer sein wird, er durch die dann parallel laufende Arbeit verdeckt werden wird, die die Nutzung des Netzwerks und die Entwicklung höherer Netzwerkschichten betrifft.
Ein weiteres Problem, das sich unmittelbar stellt, ist, was als offizielle Änderung des Protokolls gelten soll. Die Geschichte der Entwicklung des derzeitigen Protokolls zeigt, dass eine einmal vorgebrachte Idee viele Male geändert wird, bevor sie für alle allgemein akzeptabel ist. Somit könnte jeder neue Änderungsvorschlag die Programmentwicklung um Monate verzögern.
Schließlich ist da die Überlegung, dass sich eine Idee als undurchführbar erweisen kann, sobald der tatsächliche Betrieb des Netzwerks beginnt. Jede der derzeit vereinbarten Fragen kann erneut aufgegriffen werden, wenn umfassende Tests beginnen.
Wir halten diese Überlegungen für wichtig genug, um das Netzwerkprotokoll einzufrieren, es sei denn, es treten Probleme auf, die eine bestimmte Funktion nicht implementierbar machen würden. Änderungen, die dann lediglich zu größerer Effizienz führen würden, würden aufgespart, bis der tatsächliche Netzwerkbetrieb erprobt ist.
Dies soll nicht heißen, dass neue Ideen oder Argumente nicht vorgebracht werden sollten, sondern dass sie mit dem Verständnis vorgebracht werden sollten, dass sie nicht für eine sofortige Umsetzung in Betracht gezogen werden, sondern vielmehr im Hinblick auf eine mögliche spätere Umsetzung diskutiert werden sollen. Dieses Konzept könnte dadurch zum Ausdruck gebracht werden, dass solche Dokumente den Titel „Proposal for Post-Moratorium Changes to ...“ tragen.
Hinweis: Dieses RFC wurde von Bob Hinden im Juni 1997 in maschinenlesbares Format für die Aufnahme in die Online-RFC-Archive gebracht.