Die Host-Tabelle vor dem Markt: Wer autorisierte das erste Internet-Hauptbuch?

Zusammenfassung

• Die frühe Host-Tabelle erlangte praktische Autorität durch eine begrenzte Kette: ARPA beschaffte das Network Information Center für das ARPANET, SRI führte die gemeinsame Aufzeichnung, teilnehmende Standorte lieferten und konsumierten Host-Informationen, und die DCA integrierte den Dienst später in eine operative DoD-Umgebung.
• RFC 810 veröffentlichte eine Registrierungsvoraussetzung für Namen und Adressen, die im Zusammenhang mit von DoD-Hosts weitergeleitetem Verkehr verwendet werden, aber die erhaltene Spezifikation zeigt keine Überwachung, Paketverwerfung, Sanktionen, Compliance-Raten oder irgendeine bestimmte blockierte Kommunikation.
• Die öffentliche Aufzeichnung liefert weder die vollständigen frühen Verträge, Host-Tabellen-Anforderungsdateien, strittigen Entscheidungen, Korrekturergebnisse, Override-Aufzeichnungen, Durchsetzungsberichte noch Abhilfemaßnahmen, die erforderlich wären, um entweder einen uneingeschränkten NIC-Ermessensspielraum oder ein öffentliches Mandat, das sich auf jedes externe Netzwerk erstreckt, festzustellen.

Am 8. März 1974 forderte das Network Information Center jeden ARPANET-Standort auf, eine lokale Host-Tabelle zu ändern. Die Anweisung erschien inRFC 620, „Request for Monitor Host Table Updates“, herausgegeben von Bill Ferguson vom Augmentation Research Center von SRI. NIC-Dienste waren zuOFFICE-1umgezogen, an Netzwerkstandort 53 in oktaler Notation. Standort 2 bliebSRI-ARC, aber sein Spitzname sollteARCwerden; der vertraute SpitznameNICsollte stattdessen auf Standort 53 verweisen. Die Mitteilung enthielt genaue Einträge für TENEX-Monitortabellen und wies Standorte mit anderen Betriebssystemen an, entsprechende Änderungen vorzunehmen.

RFC 620 dokumentiert eine Anweisung, nicht einen beobachteten Compliance-Fall. Sie identifiziert keinen einzelnen Betreiber, der die Arbeit ausführt, keinen Standort, der es nicht tat, und keinen daraus resultierenden Ausfall. Der Betreiber ist dennoch eine notwendige, vom Dokument implizierte Rolle: Jemand an jedem Standort musste die lokal verwendete Zuordnung auf die für dieses Betriebssystem geeignete Weise ändern. Wenn eine Tabelle veraltet blieb, würde sieNICweiterhin mit Standort 2 assoziieren und könnte einen namensbasierten Versuch vom beabsichtigten NIC-Dienst wegleiten. Diese Konsequenz folgt aus der Zuordnungsänderung, aber der RFC meldet keine tatsächlich fehlgeschlagene Namensauflösung oder fehlgeleitete Verbindung.

Die Mitteilung offenbart die administrative Struktur hinter einem scheinbar einfachen Namen. SRI konnte die neue Assoziation ankündigen, aber die Ankündigung schrieb nicht jede entfernte Maschine um. Ein Standort musste die Anweisung empfangen, interpretieren und sein eigenes System ändern. Gemeinsame Namensgebung funktionierte, wenn die gepflegte Aufzeichnung, der Verteilungskanal und die lokale Implementierung konvergierten.

Am 25. März 1974 kündigteRFC 627einen regelmäßigeren Verteilungsmechanismus an. Die Online-ASCII-Datei mit offiziellen Hostnamen war unterOFFICE-1verfügbar, dessen Adresse als 43 in dezimaler Notation erschien, äquivalent zur in RFC 620 verwendeten oktalen 53. Das NIC pflegte die Datei und integrierte wöchentlich Hinzufügungen oder Änderungen. Jeder Netzwerk-Host war dafür verantwortlich, neue Informationen über das File Transfer Protocol abzurufen. Änderungen, Ergänzungen, Korrekturen und Kommentare konnten über Netzwerk-Mail, Telefon oder das NIC-Identifikationssystem an Elizabeth „Jake“ Feinler gerichtet werden.

Diese beiden März-Dokumente bewahren keine vollständige Anforderung-zu-Entscheidung-Transaktion. Sie können jedoch mit früheren und späteren Aufzeichnungen kombiniert werden, um eine minimale zusammengesetzte Rekonstruktion zu erstellen, vorausgesetzt, die Daten bleiben getrennt.

1971 wählte ein Host über seinen Verbindungsmann einen bevorzugten formalen Namen gemäß dem inRFC 273vorgeschlagenen Verfahren. Der Verbindungsmann übermittelte die Wahl; das Dokument stellt nicht fest, dass ein technischer Verbindungsmann persönlich die Autorität besaß, jede organisatorische Entscheidung für den Standort zu treffen. Das vorgeschlagene Namensschema erwartete, dass Spitznamen innerhalb der Netzwerkgemeinschaft eindeutig waren, und sah Diskussionen vor, wenn doppelte oder außergewöhnlich lange Namen gewählt wurden. Es spezifizierte kein NIC-Veto, keinen Ablehnungstest, keine endgültige Entscheidungsregel, keine Aufhebung und keine Berufung.

Im Januar 1974 beschriebRFC 608den offiziellen Hostnamen als Zeichenkette, die durch Verhandlung zwischen dem Host und dem NIC erhalten wurde. Er legte Zeichen- und Formatierungsbeschränkungen fest, identifizierte Feinlers NLS-Quelldatei und schlug die regelmäßige Erstellung einer maschinenlesbaren ASCII-Ausgabe vor. Er erklärte nicht, wie umstrittene Verhandlungen endeten oder wer sich durchsetzte, wenn die Diskussion scheiterte.

Im März 1974 etablierte RFC 627 die verfügbare Datei, die wöchentliche Integration von Aktualisierungen, einen Korrekturkanal und die Verantwortung jedes Hosts, neue Informationen abzurufen. Erst 1982 erklärteRFC 810ausdrücklich, dass der Benutzer der DoD-Host-Tabelle dafür verantwortlich war, sie in das jeweils erforderliche lokale Format zu übersetzen. Es wäre ungenau, diese Aussagen von 1971, 1974 und 1982 in eine beobachtete Routine zu komprimieren oder jeden Schritt demselben Beamten zuzuschreiben.

Die vertretbare Zusammensetzung ist daher bescheiden. Ein Host kommunizierte seinen bevorzugten Namen über einen Verbindungsmann. Veröffentlichte Konventionen bestimmten die Form dieses Namens; die Eindeutigkeit der Spitznamen wurde erwartet, und doppelte oder lange Wahlen konnten Diskussionen auslösen. SRI pflegte eine Quelle, aus der es eine gemeinsame Datei erstellte. Standorte riefen die Datei ab und integrierten ihren Inhalt in lokale Systeme. Bis 1982 wurde die Verantwortung des Benutzers für die lokale Übersetzung ausdrücklich festgehalten.

Was geschah, wenn ein vorgeschlagener Name umstritten blieb, wenn eine Korrektur angefochten wurde oder wenn ein Standort eine Anweisung ablehnte, kann aus den verfahrenstechnischen RFCs allein nicht erschlossen werden.

Dies ist die erste Grenze der Autorität der Host-Tabelle. Die gemeinsame Aufzeichnung konnte bestimmen, welchen Namen ein teilnehmendes System erkannte, ohne zu entscheiden, ob der zugrunde liegende Computer existierte, ob eine physische Leitung installiert war oder ob eine Organisation zum Netzwerk zugelassen wurde. Ihre Auswirkungen waren operativ und manchmal schwerwiegend für die namensbasierte Nutzung, aber sie waren nicht identisch mit der Kontrolle über die gesamte Konnektivität.

Vier divergierende Tabellen und das Plädoyer für eine gemeinsame Datei

Die Online-Host-Datei adressierte ein beobachtetes Koordinationsproblem. Im Dezember 1973 beschriebRFC 606vier zugängliche TENEX-Systeme –SRI-ARC,BBN-TENEX,USC-ISIundPARC-MAXC– deren Zuordnungen zwischen Hostnamen und Adressen voneinander abwichen. Keine war vollständig, und der Autor glaubte, dass jede in gewisser Hinsicht von der offiziellen Liste abwich.

Dieser Beweis sollte nicht zu der Behauptung aufgebläht werden, dass jeder ARPANET-Standort eine ungenaue Tabelle hatte. Er stellt eine Divergenz bei vier genannten Systemen fest. Selbst diese begrenzte Feststellung reichte aus, um die Kosten der separaten Wartung zu demonstrieren. Eine Person, die sich zwischen diesen Maschinen bewegte, konnte auf unterschiedliche Antworten stoßen. Ein Programm, das für einen lokalen Satz geschrieben wurde, konnte fehlschlagen, wenn es auf einen anderen übertragen wurde. Ein neu hinzugefügter oder umbenannter Host konnte an einem Standort erkannt werden, während er an einem anderen unbekannt blieb.

RFC 606 schlug eine zentral erstellte, maschinenlesbare Datei vor, die vom NIC gepflegt wird. Er unterschied die beiden Kernfakten eines Eintrags – Hostname und Hostadresse – von optionalen Attributen wie Hoststatus, Protokollverhalten und Spitznamen. Der Autor warnte, dass Attribute nicht vollständig sein müssen und die Protokollaushandlung, Mundpropaganda oder andere Wege zur Ermittlung der Eigenschaften eines Hosts nicht ersetzen sollten. Der Vorschlag war bewusst spezifisch: Er zielte darauf ab, inkompatible lokale Listen zu lösen, nicht eine umfassende Satzung für die Netzwerkteilnahme zu schaffen.

RFC 608 akzeptierte die Idee einer zentralen Datei und berichtete, dass sie vom Information Processing Techniques-Büro von ARPA unterstützt wurde. Feinler pflegte die Quelle im NLS-Format von SRI, während ein Programm die ASCII-Verteilungsdatei regelmäßig erstellen sollte. Anfänglich enthielten die generierten Einträge den offiziellen Namen, die dezimale Hostadresse und den Status. Weitere Informationen konnten hinzugefügt werden, sobald Daten verfügbar wurden.

Das Dokument erlaubte auch ein Netzwerkpräfix für Hosts außerhalb des ARPANET, was zeigt, dass die Autoren bereits einen Vergleichssatz in Betracht zogen, der breiter war als die ARPANET-Host-Population. Es identifiziert nicht jeden externen Host, der tatsächlich aufgenommen wurde.

Die Unterscheidung zwischen Quelle und Verteilung war wichtig. NLS war ein SRI-System zur Pflege strukturierter Informationen. Die ASCII-Ausgabe wurde für den Abruf und die Verarbeitung durch heterogene Hosts konzipiert. SRI-ARC war der organisatorische und rechnerische Kontext, aus dem mehrere dieser Mitteilungen hervorgingen, währendOFFICE-1im März 1974 die Maschine wurde, die NIC-Benutzer und die veröffentlichte Host-Datei bediente. Spätere Dokumente verwendetenSRI-NICfür den Host, der die DoD-Tabelle und den Namensdienst bereitstellte. Diese Bezeichnungen kennzeichnen technische und organisatorische Änderungen; sie sollten nicht als austauschbare Namen für eine unveränderliche Maschine behandelt werden.

RFC 627 wandelte den Vorschlag in einen angekündigten Dienst um. Er ermutigte Hosts, die offiziellen Namen in ihren Monitoren zu verwenden, und machte jeden Host für den Abruf der Datei verantwortlich. Spitznamen waren optional, und Systeme, die eine Namens-zu-Adress-Übersetzung bereitstellten, wurden ermutigt, aber nicht verpflichtet, sie zu verwenden. Das Dokument bot Kanäle für Hinzufügungen und Korrekturen, aber die Existenz eines Kanals beweist nicht die benötigte Zeit, die geforderten Beweise oder die verfügbare Abhilfe, wenn eine Anfrage abgelehnt wurde.

Die Architektur blieb am Punkt der Nutzung verteilt. SRI pflegte die Referenzdatei, aber entfernte Standorte entschieden, wann sie sie abriefen und wie sie sie installierten. Ein kürzlich korrigierter Master konnte mit veralteten lokalen Kopien koexistieren. Ein Betreiber konnte eine offizielle Datei mit einem lokalen Alias ergänzen. Eine Person, die eine numerische Adresse kannte, konnte einen fehlenden Namen umgehen. Die Tabelle reduzierte Inkonsistenzen, ohne selbst das Paketvermittlungs-Subnetz zu werden.

Ein falscher Eintrag konnte dennoch materielle Auswirkungen haben. Ein namensbasiertes Programm könnte den Verkehr zur aufgezeichneten Adresse anstelle der beabsichtigten Maschine lenken. Ein fehlender Eintrag könnte Software unfähig machen, den angeforderten Namen zu übersetzen. Eine verzögerte lokale Aktualisierung könnte ein veraltetes Ergebnis bewahren. Das genaue Verhalten hing vom lokalen Betriebssystem und der Anwendung ab. Die RFCs rechtfertigen keine universelle Behauptung, dass jedes Auslassen eine Trennung verursachte oder dass jeder ungenaue Eintrag denselben Fehler verursachte.

Der Umzug im März veranschaulicht die engere These. NachdemNICzuOFFICE-1umgezogen war, würde ein Standort, der die Änderung von RFC 620 implementierte, den Spitznamen mit Standort 53 assoziieren. Ein veralteter Standort konnte ihn weiterhin mit Standort 2 assoziieren. Der Dienstumzug von SRI erfolgte unabhängig von der entfernten Tabelle, während die Nützlichkeit des gemeinsamen Spitznamens von der entfernten Übernahme abhing. Die Aufzeichnung war folgenreich, weil andere Maschinen darauf reagierten.

Namen begannen bei Hosts, nicht mit einem unbegrenzten NIC-Veto

Die gemeinsame Datei entstand nicht aus einer festen Regel, die es dem NIC erlaubte, jeden gewünschten Namen zuzuweisen. Die RFC-Diskussion von 1971 dokumentiert erhebliche Meinungsverschiedenheiten über die Namensgebung.

RFC 226zirkulierte einen vorgeschlagenen Satz von Mnemoniken und lud zu Einwänden ein. Konkurrierende Vorschläge folgten. Einige Teilnehmer bevorzugten kurze Rufzeichen; andere wollten Namen, die institutionelle und Projektidentitäten bewahrten. Die Debatte war nicht nur kosmetisch. Namen erschienen in Befehlen, Dokumenten und Gewohnheiten der Benutzer. Eine Namensregel verteilte daher Unannehmlichkeiten und Anerkennung ebenso wie Zeichen.

InRFC 237argumentierte das NIC, dass es eine logische Stelle sei, um den Namensstandard zu pflegen, und schlug vor, neuen Hosts Namen zuzuweisen, sobald die Network Working Group die Syntax und die aktuelle Liste geklärt habe. Das war ein institutioneller Vorschlag des Dienstbetreibers. Es ist ein Beleg dafür, was das NIC für seine Rolle hielt, nicht ein Beweis, dass jede angeschlossene Organisation oder eine übergeordnete öffentliche Autorität den gesamten Anspruch akzeptierte.

RFC 273 reagierte auf das Scheitern früherer Vorschläge, Akzeptanz zu erreichen. Er besagte, dass Hosts über ihre Verbindungsleute ihre eigenen formalen Namen wählen sollten, möglicherweise vorbehaltlich einer Diskussion, wenn sie doppelte oder übermäßig lange Namen wählten. Hosts einer Institution sollten dasselbe institutionelle Mnemonik verwenden. Ein Spitzname sollte innerhalb der Netzwerkgemeinschaft eindeutig sein.

Die Formulierung etabliert lokale Wahl und die Möglichkeit einer zentralen Diskussion. Sie definiert nicht, wer eine endgültige Ablehnung aussprechen konnte. Ein Duplikat würde den Zweck eines gemeinsamen Spitznamens vereiteln, aber technische Inkompatibilität allein offenbart nicht die administrative Abhilfe. Das NIC hätte einen Standort überreden können, einen anderen Namen zu wählen; ein Sponsor hätte eingreifen können; Standorte hätten eine informelle Konvention akzeptieren können; oder einige Meinungsverschiedenheiten blieben ungelöst. Eine vollständige Fallakte wäre erforderlich, um diese Möglichkeiten zu unterscheiden.

RFC 289, veröffentlicht im Dezember 1971, berichtete, dass fast alle Standorte mit gewünschten Namen geantwortet hätten. Sein Titel „What We Hope Is An Official List of Host Names“ bewahrt den vorläufigen Charakter der Übung. Die entstehende Liste spiegelte die Einholung und Standortantwort innerhalb einer begrenzten ARPANET-Gemeinschaft wider. Sie war weder eine einseitige private Erfindung noch das Ergebnis einer weltweiten öffentlichen Delegation.

Die Rolle des Verbindungsmanns erfordert ebenfalls Sorgfalt. RFC 273 nutzte Verbindungsleute als Kanal, über den Hosts Namen wählten und kommunizierten. Ein spätererLeitfaden des Computer History Museum zu den SRI ARC/NIC-Aufzeichnungenbesagt, dass technische Verbindungsleute im Allgemeinen nicht befugt waren, für die Standortverwaltung zu sprechen. Der Archivleitfaden beschreibt die spätere Schaffung einer Host-Administrator-Rolle, deren Inhaber Standortaktionen autorisieren konnte. Da der Leitfaden einen längeren Zeitraum abdeckt, kann er nicht einfach rückwirkend auf jeden Austausch von 1971 projiziert werden. Er warnt jedoch davor, „Verbindungsmann“ als Synonym für institutionelle Führungskraft zu behandeln.

Das Höchste, was sicher gesagt werden kann, ist, dass der Host der ursprüngliche Wähler im veröffentlichten Verfahren von 1971 war, der Verbindungsmann der Kommunikationskanal und das NIC das gemeinsame Ergebnis pflegte. Syntax und erwartete Eindeutigkeit schränkten ein, was im gemeinsamen Namensraum funktionieren konnte. Die Dokumente offenbaren kein umfassendes Entscheidungssystem.

Dieses begrenzte Ermessen war dennoch bedeutsam. Sobald ein Name in Dokumenten und maschinenlesbaren Dateien erschien, konnten Benutzer andernorts sich darauf verlassen. Ein Host konnte seinen Namen ändern, aber dies verursachte Kosten für Software, Dokumentation und lokales Wissen. Stabilität wurde zu einer Quelle praktischer Autorität. Das Zentrum brauchte keine weitreichende rechtliche Macht, um seine gepflegte Antwort schwer ignorierbar zu machen.

ARPAs Dienstvertrag und die DCA-Übergabe

Die institutionelle Kette begann mit einem föderalen Forschungsprogramm, nicht mit dem breiteren Internet.

ARPANET war ein bestimmtes paketvermitteltes Netzwerk, das durch die Advanced Research Projects Agency innerhalb des United States Department of Defense eingerichtet wurde. ARPA finanzierte das Forschungsprogramm, wählte Auftragnehmer aus und unterstützte teilnehmende Forschungszentren. Die Agentur wurde 1972 zur Defense Advanced Research Projects Agency. „ARPA“ ist daher für die Einrichtung des Netzwerks und die frühe Namensdebatte angemessen, während „DARPA“ in Aufzeichnungen aus der späteren Zeit erscheint.

DerARPANET Completion Report, erstellt 1978, besagt, dass das Stanford Research Institute einen Vertrag erhielt, um ein Network Information Center für das ARPANET zu entwickeln und zu betreiben. Die Arbeit begann zusammen mit der Implementierung des Netzwerks im Jahr 1969. Der Bericht beschreibt einen Dienst, der Teilnehmer- und Verteilerlisten führte, technische Dokumente archivierte, Informationen über Host-Ressourcen bereitstellte, Zugang zum NLS-System von SRI gewährte und ARPANET-Protokollspezifikationen pflegte.

Dies begründet eine Sponsor-Auftragnehmer-Beziehung. ARPA beschaffte einen Informationsdienst für das Netzwerk und die von ihm unterstützte Forschungsgemeinschaft. SRI hatte die Pflicht, das vertraglich Geforderte zu erfüllen, und ARPA hatte das entsprechende Recht auf vertragliche Leistung. Der öffentliche Bericht gibt weder die frühe Leistungsbeschreibung, Änderungen, Abnahmestandards, Sanktionen, Datenklauseln noch Hostnamen-Entscheidungsregeln wieder. Er kann daher nicht den vollständigen rechtlichen Inhalt dieser Pflicht feststellen.

Die mit dem ARPANET verbundenen Standorte waren institutionell vielfältig. Dazu gehörten Universitäten, Forschungsinstitute, Regierungslaboratorien, militärische Einrichtungen und private Auftragnehmer. Die Vielfalt der Rechtsform machte nicht jeden Standort zu einem unabhängigen öffentlichen Betreiber. Viele nahmen über föderale Förderung, Verträge oder genehmigte Auftragsbeziehungen teil. Gleichzeitig verhindert das Fehlen der zugrunde liegenden Standortinstrumente die Behauptung, dass jede angeschlossene Organisation eine identische Vertragsklausel hatte, die die Einhaltung der Host-Tabelle vorschrieb.

Die stärkste direkte Darstellung des Übergangs von ARPA an die Defense Communications Agency ist gestaffelt und datiert. Der Completion Report beschreibt ein ARPA-DCA-Memorandum, wonach das Management des ARPANET am 1. Juli 1975 an die DCA übertragen wurde. Er vermerkt auch eine sechsmonatige Übergangsphase, die bis zum 31. Dezember 1975 dauerte, während der ARPA die DCA weiterhin unterstützte, während die DCA die Managementrolle übernahm. Ein detaillierter Übergangsplan war bis Juni fertiggestellt.

Der Bericht besagt, dass das übertragene Netzwerk als DoD-Einrichtung für Regierungsgeschäfte betrieben werden sollte. Die DCA würde Betrieb und Wartung durch eine Kostenumlagevereinbarung mit ARPANET-Sponsoren finanzieren. Die DCA sollte zunächst BBN und SRI für Netzbetrieb, Wartung und NIC-Funktionen beauftragen. Der Bericht sagt, dass klar impliziert war, dass die DCA später andere Auftragnehmer beauftragen könnte, sicherlich nach dem ersten Jahr.

Das ist ein Beleg für die institutionelle Ersetzbarkeit auf der Ebene der Auftragnehmerauswahl. Es beweist nicht, dass die DCA eine vollständige portierbare Kopie jeder NIC-Aufzeichnung, uneingeschränkte Rechte an vom Auftragnehmer erstellten Daten, ein getestetes Übergangspaket oder eine durchsetzbare Abhilfe für jeden Dienstausfall besaß. Ein Kunde kann grundsätzlich einen anderen Anbieter wählen, während er gewaltigen praktischen Hindernissen bei der Übertragung von Mitarbeiterwissen, Software, Archiven, aktuellen Aufzeichnungen und Standortbeziehungen gegenübersteht.

Eine DCA-Publikation von 1978, indexiert alsARPANET Information Brochure, gibt ebenfalls den 1. Juli 1975 als Datum der Managementübertragung an. Das spätere Findmittel des Computer History Museum präsentiert einen widersprüchlichen retrospektiven Bericht: Es besagt, dass der ARPANET-Betrieb 1973 an die DCA übergeben wurde und dass die DCA-Vertragsfinanzierung das SRI-NIC nach 1974 unterstützte.

Der Widerspruch sollte sichtbar bleiben. Die formelle Memorandum-Chronologie im Completion Report liefert ein genaues Übertragungsdatum und eine Übergangsphase. Das Findmittel liefert andere zusammenfassende Daten, aber nicht das zugrunde liegende Instrument, das sie in Einklang bringen würde. Es besagt auch, dass das NIC 1973 ein separates Projekt wurde, was ein anderer institutioneller Wandel ist als die Übertragung des ARPANET-Managements.

Ohne die relevanten Verträge und Verwaltungsaufzeichnungen können die betriebliche Aussage von 1973 und die Finanzierungsaussage von nach 1974 nicht in eine einzige nahtlose Chronologie umgewandelt werden.

Nach der formellen Übertragung konnte DARPA weiterhin Forschung fördern, die das ARPANET nutzte, während die DCA das operative Netzwerk verwaltete. Das DoD war das übergeordnete Regierungsumfeld; DARPA und DCA hatten darin unterschiedliche Funktionen. SRI blieb ein Auftragnehmer, der NIC-Dienste erbrachte, anstatt selbst zur Regierung zu werden. Teilnehmende Standorte betrieben Hosts. Host-Verbindungsleute und spätere Kontaktrollen übermittelten Informationen und Anweisungen. Die Unterscheidung dieser Rollen verhindert, dass Beschaffungsautorität mit universeller Autorität verwechselt wird.

Die Aufnahme ins ARPANET war keine Host-Tabellen-Entscheidung

Die Host-Tabelle erfasste Maschinen innerhalb einer Betriebsumgebung, aber die Pflege der Aufzeichnung durch SRI machte SRI nicht zur alleinigen Autorität, die darüber entschied, wer dem ARPANET beitreten konnte.

DasARPANET Directory vom Dezember 1978beschrieb Teilnehmerkategorien und den Prozess zur Erlangung von Diensten. Sein Rahmenwerk platzierte die Zulassung und Förderung innerhalb der Netzwerkmanagementstruktur der DCA. Ein potenzieller Teilnehmer benötigte einen akzeptablen behördlichen Zweck, eine Förderung und verfügbare Einrichtungen. Diese Entscheidungen betrafen den Zugang zu einem spezifischen gemanagten Netzwerk.

Die Unterscheidung ist grundlegend. Die DCA konnte die Teilnahmeberechtigung am ARPANET verwalten. SRI konnte das Verzeichnis und die Host-Informationen pflegen, die nach oder um die Zulassung herum verwendet wurden. Ein Host-Tabellen-Eintrag mochte für die bequeme gemeinsame Nutzung notwendig sein, aber die Erfassung des Hosts war nicht derselbe institutionelle Akt wie die Genehmigung der Verbindung der Organisation, die Installation eines Interface Message Processor, die Bereitstellung einer Leitung oder die Autorisierung einer Mission.

Die ARPANET-Population sollte auch nicht mit dem DoD-Internet gleichgesetzt werden. ARPANET war ein Netzwerk. Das DoD-Internet war eine Internetworking-Umgebung, in der ARPANET, Paketfunksysteme, Satellitensysteme und andere Netzwerke Internetprotokolle und gemeinsame Koordinierungsinformationen nutzen konnten. Das breitere entstehende Internet war noch breiter: eine sich verändernde Menge von Netzwerken, Experimenten und Betreibern, deren rechtliche, vertragliche und technische Beziehungen nicht einheitlich waren.

Bis September 1981 listeteRFC 790zugewiesene Internet-Netzwerknummern für zahlreiche benannte Netzwerke auf, darunter ARPANET, UCLNET, CYCLADES, TELENET, das EPSS der British Post Office, DATAPAC, TRANSPAC, LCSNET, TYMNET und eine Auswahl von Paketfunk-, Satelliten-, lokalen und experimentellen Systemen. Er identifizierte Jon Postel am Information Sciences Institute der University of Southern California als Kontakt für die Zuweisung von Netzwerknummern.

Die Liste beweist, dass die Umgebung der zugewiesenen Nummern über eine Liste von ARPANET-Hosts hinausging. Sie stellt für sich allein nicht fest, dass jedes genannte Netzwerk in diesem Moment operativ miteinander verbunden war, unabhängig von staatlicher Förderung, kommerziell, nicht-DoD oder durch den SRI-Host-Tabellen-Prozess geregelt. Eine Nummer, die in einem Zuweisungsdokument erscheint, ist keine vollständige Darstellung des vertraglichen Status oder des tatsächlichen Verkehrs des Netzwerks.

Es trennt auch Funktionen, die spätere Geschichten manchmal verwischen. Postels Rolle der zugewiesenen Nummern am USC-ISI betraf Netzwerk- und Protokollparameter. SRI pflegte die Host-Tabelle und den Namensdienst. Die DCA verwaltete das ARPANET und beauftragte den NIC-Dienst. DARPA förderte weiterhin die Forschung. Keine dieser Tatsachen macht einen Akteur zum alleinigen Urheber des gesamten entstehenden Internets.

Die Phrase „erstes Internet-Hauptbuch“ benötigt daher einen definierten Vergleich. Die Host-Tabelle war nicht das erste von einer Computerorganisation gepflegte Verzeichnis, noch war die Datei von 1974 ein Register für ein weltweites öffentliches Internet. Sie war eine frühe gemeinsame, maschinenlesbare Namens-und-Adress-Referenz in der ARPANET-zu-Internet-Linie. Bis 1982 integrierte ihr Nachfolgeformat Netzwerke, Gateways und Internetadressen und wurde von ihren Betreibern als globale Hostnamen- und Adressdatenbank beschrieben.

Ihre historische Bedeutung liegt in der zunehmenden Reichweite und der organisationsübergreifenden Abhängigkeit dieser Referenz, nicht in einem nachgewiesenen Mandat über jedes Netzwerk.

Die DoD-Regel von 1982: eine veröffentlichte Voraussetzung, keine nachgewiesene Durchsetzung

RFC 810 markierte einen Wechsel in Umfang und institutioneller Sprache. Herausgegeben am 1. März 1982 von Feinler, Ken Harrenstien, Zaw-Sing Su und Vic White vom Network Information Center von SRI International, besagte er, dass die frühere ARPANET-Host-Tabelle nicht mehr den Bedürfnissen der DoD-Gemeinschaft oder des Internetworking entsprach. Das neue Format umfasste Netzwerk-, Gateway- und Host-Einträge, Internetadressen, Betriebssysteme und Protokollinformationen.

Die Tabelle war vom HostSRI-NICüber FTP und über den Host Name Server verfügbar. Der RFC identifizierte den Server als einen vom ARPANET-NIC im Auftrag der DCA gepflegten Dienst. Er wies die Übersetzungsverantwortung auch ausdrücklich dem Benutzer zu: Wer auch immer die Tabelle konsumierte, musste sie in das lokal erforderliche Format umwandeln.

Seine siebte Annahme enthielt die stärkste operative Sprache in der Host-Tabellen-Aufzeichnung. Namen und Adressen für DoD-Netzwerke, Gateways und Hosts mussten mit dem NIC ausgehandelt und registriert werden, bevor sie verwendet wurden und bevor Verkehr von einem DoD-Host weitergeleitet wurde. Dies war eine veröffentlichte Voraussetzung, die das Verhalten von DoD-Hosts regelte. Sie verband die Registrierung direkter mit dem Betrieb als die Ermutigung von 1974, offizielle Hostnamen zu verwenden.

Der Satz dokumentiert keine Durchsetzung. RFC 810 identifiziert keinen Monitor, der Registrierungen überprüfte, keine Router-Regel, die nicht registrierten Verkehr ablehnte, keine Sanktion für Nichtbeachtung, keine Compliance-Rate oder eine bestimmte blockierte Kommunikation. Der Unterschied ist wichtig. Eine Spezifikation kann erforderliches Verhalten definieren, ohne zu beweisen, wie konsequent Betreiber es umsetzten.

Das Dokument behandelte nicht-DoD-Informationen anders. Für eine Übergangszeit würde das NIC versuchen, ähnliche Informationen für nicht-DoD-Netzwerke und -Hosts zu pflegen, sofern diese Informationen bereitgestellt wurden und solange sie benötigt wurden, bis untereinander kommunizierende Namensserver verfügbar waren. Es identifizierte weder jeden tatsächlich enthaltenen nicht-DoD-Eintrag noch auferlegte es allen externen Betreibern dieselbe ausdrückliche Voraussetzung.

Das neue Format hatte auch eine gestaffelte Einführung. RFC 810 legte den 1. Mai 1982 als Umstellungstermin fest. Im Mai enthielt der bestehendeHOSTS.TXT-Pfad noch die alte Ausgabe, während eine Testdatei im neuen Format separat verfügbar war. Im Juni und Juli enthielt der Hauptpfad das neue Format, während Material im alten Format über einen anderen Pfad zugänglich blieb. Nach dem 1. August wurde das in RFC 608 spezifizierte alteHOSTS.TXT-Format nicht mehr unterstützt.

Diese Überlappung unterschied ein veröffentlichtes Design von der sofortigen universellen Implementierung. Programme hatten Zeit, sich anzupassen. Lokale Systeme konnten während des Übergangs auf verschiedenen Ausgaben bleiben. Der Zeitplan zeigt ein aktives Management des Kompatibilitätsrisikos, beweist aber nicht, dass jeder Host die Umstellung rechtzeitig abgeschlossen hat.

RFC 811, am selben Tag veröffentlicht, spezifizierte den Online-Hostnames-Server. Ein Programm konnte nach einem Hostnamen oder einer Adresse fragen oder die gesamte Tabelle anfordern. Der Server konnte Host-, Gateway- oder Netzwerkeinträge zurückgeben. Wenn ein angeforderter Name nicht vorhanden war, nahm der definierte Fehler die FormERR: NAMNFD: Name not found:an. Andere Fehler waren möglich, einschließlichTMPSYS, was einen vorübergehenden Systemausfall und die Aufforderung bedeutete, es später erneut zu versuchen.

Diese Semantik gehört zum SRI-NIC-Serverprotokoll. Sie sollte nicht auf jeden lokalen Resolver projiziert werden, der eine heruntergeladene Kopie verwendet. Eine lokale Abfrage gegen eine Tabelle ohne Eintrag konnte fehlschlagen, eine ergänzende Zuordnung verwenden, einen Benutzer auffordern oder sich auf andere systemabhängige Weise verhalten. Das Fehlen eines Namens in einer lokalen Kopie und eineNAMNFD-Antwort des Servers waren verwandte Zustände, nicht unbedingt identische Ereignisse.

RFC 811 beschrieb seine Datenbank als Erweiterung der alten ARPANET-HOSTS.TXT-Datei und bezeichnete die zentrale Verwaltung als Übergangslösung auf dem Weg zu einem dezentralen, verteilten Namens-und-Adress-Übersetzungsdienst. Diese institutionelle Behauptung ist aus zwei Gründen wichtig. Sie zeigt, dass SRI den Dienst als Übergangsmechanismus und nicht als dauerhafte Architektur verstand, und sie bestätigt, dass der Umfang und Zweck der Tabelle über die ursprüngliche ARPANET-Liste hinausgewachsen war. Sie beweist nicht unabhängig eine universelle Abdeckung.

In den frühen 1980er Jahren wurde das NIC zunehmend mit der Umgebung des Defense Data Network in Verbindung gebracht, und spätere historische Sammlungen verwenden den Namen DDN-NIC für den Dienst. Dieses spätere Etikett sollte nicht rückwirkend auf den Vertrag von 1969 oder die Hostnamen-Debatte von 1971 übertragen werden. SRI-ARC, das SRI NIC, SRI-NIC und DDN-NIC beschreiben verbundene, aber zeitlich getrennte organisatorische und Host-Kontexte.

Was das Archiv zeigen kann – und was fehlt

Die RFC-Serie ist ungewöhnlich reich an Vorschlägen, Spezifikationen und Ankündigungen. Als Aufzeichnung einzelner Verwaltungsfälle ist sie viel schwächer.

Das Findmittel des Computer History Museum identifiziert relevante Sammlungen: NIC-Vorschläge und -Verträge, Fortschrittsberichte, Namens- und Adressierungsunterlagen, Host-Tabellen, Referenzdienstmaterial, Korrespondenz und Aufzeichnungen zu offiziellen Netzwerkkontakten. Es besagt, dass der frühe NIC-Vertrag nicht in Aufgaben unterteilt war und dass spätere Verträge aufwändiger wurden. Es beschreibt auch technische Verbindungsleute, Host-Administratoren, Node Site Coordinators und andere Kontakte, über die Informationen oder Handlungsanweisungen liefen.

Ein Findmittel stellt die Existenz, den ungefähren Gegenstand und die Anordnung von Aufzeichnungen fest. Es offenbart nicht den Inhalt jedes Vertrags, Briefes oder jeder Entscheidung. Seine Beschreibungen können nicht beweisen, dass ein Hostnamen-Antrag auf eine bestimmte Weise genehmigt, abgelehnt oder eskaliert wurde. Die zugrunde liegenden Dokumente müssten geöffnet und verglichen werden.

Es wurde hier keine vollständige Antragsakte vorgelegt, die den vorgeschlagenen Namen eines Hosts, die Fragen des NIC, die Antwort des Standorts und die endgültige Entscheidung zeigt. Kein erhaltener Fall demonstriert eine NIC-Ablehnung aufgrund von Duplizierung, eine erfolgreiche Berufung, ein Überschreiben durch einen Sponsor oder eine Korrekturabhilfe. Kein umfassendes Register liefert Bearbeitungszeiten oder Fehlerquoten. Die Kontaktdaten von RFC 627 beweisen, dass ein Korrekturkanal existierte; sie beweisen nicht die Ergebnisse, die darüber erzielt wurden.

Die fehlenden Verträge sind aus einem anderen Grund wichtig. Ein föderaler Vertrag kann ein Recht auf Leistung verleihen, ohne das Eigentum an jeder Aufzeichnung, das Eigentum an einem technischen System oder uneingeschränkte Rechte an von Auftragnehmern erstellten Daten zu übertragen. Er kann Liefergegenstände, Datenlizenzen, Übergangsunterstützung und Abhilfemaßnahmen festlegen, aber diese Konsequenzen hängen von seinen tatsächlichen Klauseln ab.

Eine viel spätereAnalyse des Government Accountability Office zu föderalen Internetfunktionsvereinbarungenunterschied sorgfältig zwischen Leistungsrechten, Datennutzungsrechten, Eigentumstiteln und Besitz. Diese Stellungnahme von 2016 betraf spätere DNS- und IANA-Regelungen und liefert nicht die fehlenden Bedingungen der SRI-Verträge der 1970er Jahre. Ihr Wert hier ist methodologisch. Allein die föderale Finanzierung kann nicht verwendet werden, um jedes Eigentums- oder Übergangsrecht abzuleiten.

Der Completion Report unterstützt eine engere Schlussfolgerung: Die DCA beabsichtigte zunächst, SRI für die NIC-Funktion beizubehalten, und konnte später einen anderen Auftragnehmer einsetzen. Das zeigt eine angedachte Ersetzbarkeit des Anbieters. Es stellt nicht fest, dass ein Austausch ohne Verzögerung, Datenstreitigkeiten, Softwarekonvertierung, verlorenes institutionelles Gedächtnis oder Dienstunterbrechung erfolgen könnte.

Implementierungsaufzeichnungen fehlen auch für die Verkehrsbedingung von RFC 810. Um von der veröffentlichten Regel zur nachgewiesenen Durchsetzung zu gelangen, bräuchte man DCA-Richtlinien, Host-Software, Prüfprotokolle, Vorfallberichte, Sanktionen oder einen dokumentierten blockierten Fluss. Ohne dieses Material kann der Artikel die erklärte Reichweite der Regel identifizieren, aber nicht ihre beobachtete Kraft.

Stillschweigen muss in beide Richtungen wirken. Das Fehlen eines veröffentlichten Berufungsverfahrens beweist nicht, dass keine informelle Eskalation existierte. Telefonate, Netzwerk-Mail, NLS-Austausch und Eingreifen von Sponsoren könnten Streitigkeiten ohne einen RFC gelöst haben. Umgekehrt beweist das Fehlen veröffentlichter Beschwerden nicht, dass jeder Teilnehmer den Prozess als legitim ansah oder dass jede Aktualisierung rechtzeitig erfolgte.

Die resultierende Unsicherheit ist institutionell und nicht nur antiquarisch. Wenn Anträge routinemäßig durch transparente Standortbestätigung korrigiert wurden, sähe der Dienst eher bürokratisch und kooperativ aus. Wenn das NIC Einträge ohne Erklärung ablehnen konnte und keine Sponsorenprüfung existierte, hätte dieselbe Datei eine andere Governance-Bedeutung. Die öffentlichen Beweise stützen keines der Extreme als allgemeine Darstellung.

Die Alternative der lokalen Liste und ihre tatsächlichen Kosten

Eine historisch machbare Alternative zur gemeinsamen Datei war nicht das moderne Domain Name System. Es war die bereits vor RFC 606 sichtbare Praxis: Jeder Standort pflegte seine eigenen Zuordnungen, bezog Änderungen durch persönliche Kommunikation und übersetzte entfernte Informationen in sein eigenes Betriebssystem.

Bei vier Standorten konnte dies handhabbar sein. Administratoren kannten einander, Protokolldesigner trafen sich regelmäßig, und eine Korrektur konnte per Telefon, Dokument oder Netzwerk-Mail übermittelt werden. Ein Standort konnte einen lokalen Alias übernehmen, ohne auf eine zentrale Veröffentlichung zu warten. Wenn zwei Organisationen häufig kommunizierten, konnten sie ihre gemeinsamen Informationen aktuell halten, selbst wenn eine zentrale Maschine nicht verfügbar war.

Der Wartungsaufwand wuchs schnell. Bei zehn Standorten, von denen jeder Einträge für die anderen neun pflegte, konnte es bis zu 90 gerichtete lokale Zuordnungen geben. Bei einhundert Standorten konnte es bis zu 9.900 geben. Diese Zahlen beschreiben an Standorten gehaltene gerichtete Kopien, nicht 90 oder 9.900 verschiedene bilaterale Beziehungen. Die tatsächlich benötigte Anzahl von Zuordnungen hinge von den Kommunikationsmustern ab, aber jedes neue Ziel schuf mehr Orte, an denen Informationen veralten konnten.

Das Hinzufügen eines Hosts oder eine Adressänderung müsste mehrere Administratoren erreichen. Jeder würde sie nach einem eigenen Zeitplan und in einem lokalen Format anwenden. Eine Korrektur könnte von einem Standort bestätigt, von einem anderen verpasst und von einem dritten falsch umgewandelt werden. Betreiber müssten identifizieren, welche Ausgabe sie hatten, widersprüchliche Berichte vergleichen und feststellen, ob ein offensichtlicher Dienstausfall vom Netzwerk, dem entfernten Host oder einer veralteten Zuordnung stammte.

RFC 606 liefert die beobachtete Warnung: Die vier genannten TENEX-Systeme hatten bereits unvollständige, divergierende Tabellen. Er quantifiziert keine durch diese Unterschiede verursachten Ausfälle. Die Divergenz selbst demonstriert doppelte Wartung und inkonsistente Antworten.

Eine gemeinsame Quelle reduzierte diesen Aufwand. Der betroffene Host konnte Informationen über einen anerkannten Kanal kommunizieren. SRI konnte eine Ausgabe erstellen. Standorte konnten dieselbe Datei abrufen und ihren lokalen Zustand mit einer datierten Referenz vergleichen. Ein Support-Mitarbeiter, der eine Diskrepanz untersuchte, hatte einen Ausgangspunkt.

Die gemeinsame Datei beseitigte nicht alle Verteilungskosten. Jeder Standort benötigte weiterhin Speicher, Abrufsoftware, lokale Konvertierung und eine Aktualisierungsroutine. Die wöchentliche Veröffentlichung führte zu einer Verzögerung zwischen einer gemeldeten Änderung und ihrem Erscheinen in der nächsten Ausgabe. Der Abruf konnte fehlschlagen, wenn der dienende Host oder ein Netzwerkpfad nicht verfügbar war. Die lokale Installation konnte nach erfolgreichem Abruf hinterherhinken. Die Architektur zentralisierte die Zusammenstellung, nicht jede betriebliche Aufgabe.

Auch garantierte eine gemeinsame Quelle nicht die Wahrheit. SRI war darauf angewiesen, dass Hosts und Kontakte genaue Informationen lieferten. Eine von einem Standort gelieferte falsche Adresse konnte in den Master gelangen. Eine korrekte zentrale Aktualisierung konnte durch veraltete lokale Bereitstellung untergraben werden. Ein Konflikt konnte fortbestehen, wenn das Verfahren zu seiner Entscheidung unklar war. Die Referenz machte Meinungsverschiedenheiten sichtbar und reduzierte Doppelarbeit, aber sie beseitigte nicht die Notwendigkeit der Überprüfung.

Die Alternative der lokalen Liste erklärt, warum Organisationen sich der NIC-Datei fügten, ohne eine Theorie unbegrenzter Befehlsgewalt zu benötigen. Eine gepflegte Antwort war billiger zu konsumieren als viele unabhängig rekonstruierte. Software und Dokumentation wurden zuverlässiger, wenn sie gemeinsame Namen verwendeten. Die daraus resultierende Abhängigkeit verlieh der gepflegten Aufzeichnung operative Kraft.

Ein gemeinsames Hauptbuch mit mehr als einem Verteiler

Eine zweite zeitlich machbare Alternative hätte eine kanonische Datei beibehalten, während Speicherung und Abruf breiter verteilt worden wären.

Die Idee erschien in zeitgenössischen Dokumenten.RFC 623schlug vor, dass das NIC den Master behält, während ein anderer Host eine häufig aktualisierte sekundäre Kopie pflegt. Der Autor bot UCSB an und schlug eine tägliche Synchronisation vor. Der Zweck war Verfügbarkeit: Wenn der NIC-Host die Datei nicht bereitstellen konnte, konnten Benutzer das Sekundärsystem versuchen.

RFC 625akzeptierte den Grundsatz, dass mehr als ein Host eine Kopie pflegen sollte, und begrüßte UCSB als potentielles Sekundärsystem. Er lehnte es ab, FTP durch ein dediziertes Abrufprotokoll zu ersetzen. RFC 627, später im März veröffentlicht, lud immer noch jeden Host, der eine Sekundärkopie pflegen wollte, ein, das NIC zu kontaktieren.

Diese Aufzeichnungen etablieren ein vorgeschlagenes und akzeptiertes Replikationsdesign. Sie beweisen nicht, dass UCSB oder ein anderer Host einen funktionierenden Spiegel betrieb. Eine Bestätigung würde eine Betriebsmeldung, ein Serverprotokoll, eine archivierte Sekundärdatei, ein Host-Handbuch oder einen späteren Bericht erfordern. Der Vorschlag sollte nicht als Bereitstellung umgeschrieben werden.

Hätte ein solches Sekundärsystem funktioniert, hätte es zeitgemäße Ressourcen benötigt. Der Standort brauchte Speicher für die Datei, Personal oder automatisierte Verfahren zum Abruf von Aktualisierungen und einen Zeitplan, der häufig genug war, um seine Ausgabe nützlich zu halten. Benutzer mussten wissen, welchen Host sie kontaktieren sollten und wie sie die neueste kanonische Version erkennen konnten. Das Sekundärsystem benötigte eine Regel, was zu tun war, wenn seine lokale Kopie von der von SRI abwich.

Ein Ausfall konnte die Abstimmung erschweren. Angenommen, das Sekundärsystem verpasste zwei Aktualisierungen, während SRI verfügbar blieb, und kehrte dann mit einer älteren Ausgabe zurück. Eine Zeitstempel- oder Sequenzkonvention wäre erforderlich, um zu verhindern, dass Benutzer Verfügbarkeit mit Aktualität verwechseln. Wenn SRI nicht verfügbar war, während eine umstrittene Korrektur eintraf, müsste das Sekundärsystem wissen, ob es die Änderung veröffentlichen könnte oder lediglich den letzten bestätigten Master weiter bereitstellen sollte.

Die Replikation ließ auch die Änderungsautorität ungelöst. Ein Spiegel konnte die kanonische Datei verteilen, ohne über Einträge zu entscheiden. Ihm unabhängige Bearbeitungsbefugnis zu geben, würde die Möglichkeit konkurrierender Master schaffen. Um dieses Problem zu vermeiden, war eine klare Trennung erforderlich zwischen der Organisation, die ihre Fakten bezeugte, dem Zentrum, das den gemeinsamen Namensraum abstimmte, dem Verteiler, der Kopien bereitstellte, und einem etwaigen Prüfer, der Streitigkeiten behandelte.

Die Standortbestätigung hätte ohne moderne Infrastruktur verstärkt werden können. Vor der wöchentlichen Veröffentlichung hätte das NIC eine vorgeschlagene Änderung an den betroffenen Verbindungsmann oder autorisierten Standortkontakt senden können. Eine datierte Änderungsmitteilung hätte die erstellte Datei begleiten können. Sekundärverwalter könnten die angekündigten Änderungen mit der erhaltenen Datei vergleichen. Standorte könnten Unstimmigkeiten gegenüber einer bestimmten Ausgabe melden, anstatt einer undatierten lokalen Kopie.

Diese Verfahren hätten Kosten verursacht. Kontakte mussten antworten. Korrekturen könnten auf Bestätigung warten. Personal musste Protokolle führen und unbeantwortete Anfragen abgleichen. Ein Host, der sich schnell änderte, könnte einen wöchentlichen Zyklus als zu langsam empfinden, während häufigere Verteilung die Berechnung, Netzwerknutzung und die Arbeitsbelastung der Betreiber erhöhte. Eine formelle Überprüfung könnte die Rechenschaftspflicht verbessern, gleichzeitig aber dringende Korrekturen verzögern.

Der Auftragnehmerwechsel stellte ein größeres Problem dar. Die Fähigkeit der DCA, einen anderen Anbieter auszuwählen, garantierte keinen nahtlosen Ersatz von SRI. Ein Nachfolger benötigte die aktuelle kanonische Datei, die Software, die sie erstellte, die Dokumentation von Formaten und Veröffentlichungsplänen, offene Anfragen, die Korrekturhistorie, Kontaktlisten, Mitarbeiterwissen und Zugang zur Bereitstellungsumgebung. Wenn der Vertrag keine Lieferung oder Datennutzungsrechte vorsah, konnte die Übertragung sowohl rechtlich als auch betrieblich schwierig werden.

Die erhaltenen öffentlichen Dokumente belegen nicht, ob diese Übergangsmaterialien als durchsetzbare Liefergegenstände existierten. Sie zeigen, dass ein anderer Auftragnehmer in Betracht gezogen wurde, nicht dass ein getesteter Übergabemechanismus vorhanden war. Ersetzbarkeit auf dem Papier und Kontinuität im Betrieb waren getrennte Errungenschaften.

Diese Alternative verdeutlicht die Governance-Wahl. Eine einzige logische Antwort erforderte keinen einzigen physischen Verteiler. Eine kanonische Ausgabe konnte mit Spiegeln, Standortbestätigung, aufbewahrten Änderungen und einem Ersatzdienstleister koexistieren. Jede Ergänzung hätte Kosten und Verantwortung verschoben, ohne die Notwendigkeit einer endgültigen Koordination zu beseitigen.

Eine datierte Autoritätskette, kein universelles Mandat

Zwischen 1969 und 1983 sammelte sich die Autorität der Host-Tabelle durch eine Reihe verschiedener Beziehungen an.

1969 beschaffte ARPA ein Network Information Center für das ARPANET. Das etablierte einen föderalen Kunden, einen SRI-Auftragnehmer und eine definierte Dienstpopulation. Es machte SRI nicht zum Vertreter jedes Computernetzwerks.

1971 wurden Hosts eingeladen, über Verbindungsleute innerhalb veröffentlichter Konventionen Namen zu wählen. Debatte und Reaktion unter ARPANET-Teilnehmern lieferten eine begrenzte Akzeptanz unter Gleichgestellten. Die vorgeschlagene Rolle des NIC wurde durch die lokale Wahl eingeschränkt, während der gemeinsame Namensraum dennoch kompatible Ergebnisse erforderte.

1973 und Anfang 1974 veranlassten divergierende lokale Tabellen die Erstellung einer maschinenlesbaren gemeinsamen Datei. RFCs 606 und 608 dokumentierten den Vorschlag und das Quellendesign. RFCs 620 und 627 dokumentierten eine spezifische standortweite Änderungsanweisung, die verfügbare ASCII-Datei, wöchentliche Aktualisierungen, die lokale Abrufverantwortung und Korrekturkanäle. Sie dokumentierten kein allgemeines NIC-Veto oder vollständiges Streitbeilegungssystem.

Am 1. Juli 1975, gemäß dem im Completion Report beschriebenen ARPA-DCA-Memorandum, wurde das Management des ARPANET an die DCA übertragen, gefolgt von einer Übergangsphase bis zum 31. Dezember. Die DCA behielt SRI zunächst für NIC-Funktionen bei und konnte einen anderen Auftragnehmer in Betracht ziehen. Die widersprüchlichen Aussagen des Findmittels über eine betriebliche Übergabe 1973 und die Finanzierung nach 1974 bleiben ungelöst.

Bis 1978 platzierte das Teilnehmerrahmenwerk der DCA die ARPANET-Zulassung innerhalb des staatlichen Netzwerkmanagements und nicht in der SRI-Host-Tabellen-Pflege. Dies trennte die Befugnis, einen Teilnehmer zuzulassen, von dem Dienst, der Host-Informationen aufzeichnete und verteilte.

Bis 1981 führte die Umgebung der zugewiesenen Nummern viele Netzwerke über das ARPANET hinaus auf, während die Zuweisung von Netzwerknummern mit Postel am USC-ISI identifiziert wurde. Das Erscheinen in dieser Liste stellte nicht fest, dass jedes Netzwerk dieselbe rechtliche oder betriebliche Beziehung zur DCA oder zum NIC teilte.

Im März 1982 spezifizierte RFC 810 eine breitere DoD-Internet-Host-Tabelle und veröffentlichte die vorherige Registrierung als Bedingung für Namen und Adressen, die im Zusammenhang mit von DoD-Hosts weitergeleitetem Verkehr verwendet werden. Die getrennte Übergangsbehandlung von nicht-DoD-Informationen markierte eine Grenze. Die Regel war explizit; ihre Durchsetzung bleibt unbewiesen. Die Umstellung von Mai bis August zeigte weiter, dass Spezifikation, Übergang und abgeschlossene lokale Implementierung verschiedene Phasen waren.

Der Server von RFC 811 machte die gepflegte Antwort über Online-Abfragen verfügbar und beschrieb die zentrale Datenbank als vorübergehende Brücke zur verteilten Namensgebung. Dieser Dienst erhöhte die Abhängigkeit von SRI-NIC, während anerkannt wurde, dass die Architektur nicht dazu gedacht war, dauerhaft zentral zu bleiben.

Die Host-Tabelle übte daher ihre stärkste nachgewiesene Autorität an drei Stellen aus. SRI schuldete seinem föderalen Kunden Leistung im Rahmen eines Vertrags, dessen vollständige Bedingungen nicht verfügbar sind. Die DCA konnte Betriebsanforderungen für die von ihr verwaltete DoD-Umgebung erlassen. Teilnehmende Maschinen und Benutzer verließen sich auf die gemeinsame Aufzeichnung für konsistente namensbasierte Kommunikation.

Außerhalb dieser Beziehungen ergab sich die Reichweite der Tabelle aus Interoperabilität und Übernahme. Ein externes Netzwerk konnte Informationen beisteuern oder die gemeinsame Datei nutzen, weil dies die Kommunikation erleichterte. Diese Abhängigkeit war folgenreich, aber RFC 810 beschrieb sie nicht als gleichwertig mit der DoD-Voraussetzung. Keine überprüfte Aufzeichnung zeigt eine weltweite Wählerschaft, die SRI allgemeine Autorität delegierte.

Die Tabelle schuf auch nicht alles, was sie aufzeichnete. Der Sponsor genehmigte die Netzwerkteilnahme; Auftragnehmer und Standorte lieferten Maschinen und Software; Leitungen und Paketvermittler transportierten Verkehr; andere Stellen handhabten Netzwerknummern; lokale Systeme konsumierten die veröffentlichten Zuordnungen. Die Aufzeichnung des NIC half, einen Namen allgemein erkennbar zu machen, aber sie schuf nicht die zugrunde liegende Organisation, die physische Verbindung oder jede numerische Zuweisung.

Ihre praktische Autorität war dennoch erheblich. Eine von vielen Maschinen konsumierte gemeinsame Aufzeichnung kann Verhalten einschränken, selbst wenn keine gesetzgebende Körperschaft oder öffentliche Mitgliederorganisation sie geschaffen hat. Ein Host, der vorhersehbare Anerkennung wollte, hatte Grund, den Namenskonventionen zu folgen. Ein Standort, der aktuelle Antworten wollte, hatte Grund, die gemeinsame Datei abzurufen. Ein DoD-Host wurde durch eine veröffentlichte Registrierungsvoraussetzung angesprochen. Ein nicht-DoD-Betreiber konnte Abweichungen als kostspielig empfinden, weil andere Systeme die gepflegte Antwort erwarteten.

Was unbewiesen bleibt, ist ebenso wichtig. Die erhaltenen öffentlichen Beweise zeigen nicht, dass das NIC die von ihm aufgeführten Adressen besaß, jedes externe Netzwerk nach Belieben ausschließen konnte, jedem nicht konformen Standort Sanktionen auferlegte oder jeden fehlenden Eintrag in eine physische Trennung umwandelte. Sie offenbaren keine vollständige Berufungsstruktur, Korrekturabhilfe oder Override-Hierarchie. Sie begründen kein übertragbares Regierungseigentum an allen NIC-Daten.

Die frühe Host-Tabelle war autoritativ, wo Beschaffung, Netzwerkmanagement und Maschinenabhängigkeit zusammentrafen. Sie löste ein konkretes Problem: Inkompatible lokale Zuordnungen machten gemeinsame Namen unzuverlässig. Die zentrale Zusammenstellung machte eine Antwort leichter zu verteilen, zu vergleichen und zu nutzen. Diese Errungenschaft erklärt, warum die Aufzeichnung Macht erlangte, bevor Namen und Adressen zu Marktgütern wurden.

Sie beweist nicht, dass der Betreiber der Aufzeichnung Autorität über jedes Netzwerk erhielt, das die Aufzeichnung beschreiben konnte. Die historische Kette stützt eine engere Schlussfolgerung: SRI pflegte eine föderal beauftragte Referenz für ein gefördertes Netzwerk, diese Referenz wurde in die DoD-Internetoperationen eingebettet und die breitere Abhängigkeit erweiterte ihre praktische Reichweite. Die Nützlichkeit des Hauptbuchs machte es mächtig. Sein öffentliches Mandat blieb unbegründet.