Zusammenfassung

  • Die erste Host-Tabelle erlangte praktische Autorität durch eine begrenzte Kette: die ARPA finanzierte das Network Information Center für ARPANET, das SRI führte das gemeinsame Register, die Entitätsstandorte lieferten und konsumierten Host-Informationen, und die DCA integrierte den Dienst später in eine operative DoD-Umgebung.
  • Die RFC 810 veröffentlichte eine Registrierungsvoraussetzung für Namen und Adressen, die im Zusammenhang mit dem durch DoD-Hosts geleiteten Verkehr verwendet wurden, aber die erhaltene Spezifikation zeigt keine Überwachung, Paketabweisung, Sanktionen, Compliance-Rate oder eine bestimmte blockierte Kommunikation.
  • Die öffentliche Akte liefert keine vollständigen frühen Verträge, keine Antragsdateien für Host-Tabellen, keine angefochtenen Entscheidungen, keine Korrekturergebnisse, keine Ausnahmeregistrierungen, keine Durchsetzungsberichte und keine Rechtsmittel, die erforderlich wären, um entweder ein unbegrenztes Ermessen des NIC oder ein öffentliches Mandat, das sich auf alle externen Netzwerke erstreckt, zu belegen.

Am 8. März 1974 forderte das Network Information Center jeden ARPANET-Standort auf, eine lokale Host-Tabelle zu ändern. Die Anweisung erschien in derRFC 620, „Anforderung von Aktualisierungen der Monitor-Host-Tabelle“, veröffentlicht von Bill Ferguson vom SRI Augmentation Research Center. Die NIC-Dienste waren nachOFFICE-1, Netzwerkstandort 53 in oktaler Notation, verlegt worden. Standort 2 bliebSRI-ARC, aber sein Spitzname sollteARCwerden; der gebräuchliche SpitznameNICsollte nun auf Standort 53 verweisen. Die Mitteilung lieferte die genauen Einträge für die TENEX-Monitortabellen und forderte Standorte mit anderen Betriebssystemen auf, äquivalente Änderungen vorzunehmen.

Die RFC 620 dokumentiert eine Anweisung, keinen beobachteten Konformitätsfall. Sie identifiziert keinen einzelnen Betreiber, der die Arbeit ausgeführt hat, keinen Standort, der dies nicht getan hat, und keinen daraus resultierenden Ausfall. Der Betreiber ist dennoch eine notwendige Rolle, die vom Dokument impliziert wird: Jemand an jedem Standort musste die lokal verwendete Zuordnung in der für das jeweilige Betriebssystem geeigneten Weise ändern. Wenn eine Tabelle veraltet blieb, würde sie weiterhinNICmit Standort 2 assoziieren und möglicherweise einen namensbasierten Versuch des vorgesehenen NIC-Dienstes fehlleiten. Diese Konsequenz ergibt sich aus der Änderung der Zuordnung, aber die RFC berichtet über keinen tatsächlichen Lookup-Fehler oder eine fehlgeleitete Verbindung.

Die Mitteilung offenbart die administrative Struktur hinter einem scheinbar einfachen Namen. Das SRI konnte die neue Zuordnung bekannt geben, aber die Ankündigung überschrieb nicht jede entfernte Maschine. Ein Standort musste die Anweisung erhalten, interpretieren und sein eigenes System ändern. Die gemeinsame Benennung funktionierte, wenn das gepflegte Register, der Verteilungskanal und die lokale Implementierung konvergierten.

Am 25. März 1974 kündigte dieRFC 627einen regelmäßigeren Verteilungsmechanismus an. Die Online-ASCII-Datei der offiziellen Hostnamen war aufOFFICE-1verfügbar, dessen Adresse in dezimaler Notation als 43 erschien, äquivalent zu 53 oktal in RFC 620. Das NIC pflegte die Datei und nahm wöchentlich Ergänzungen oder Änderungen auf. Jeder Host im Netzwerk war dafür verantwortlich, die neuen Informationen über das File Transfer Protocol abzurufen. Änderungen, Ergänzungen, Korrekturen und Kommentare konnten per Netzpost, Telefon oder über das NIC-Identifikationssystem an Elizabeth „Jake“ Feinler gerichtet werden.

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

1971 wählte ein Host einen bevorzugten formalen Namen über seinen Verbindungsagenten gemäß dem in derRFC 273vorgeschlagenen Verfahren. Der Verbindungsagent übermittelte die Wahl; das Dokument belegt nicht, dass ein technischer Verbindungsagent persönlich die Autorität hatte, alle organisatorischen Entscheidungen für den Standort zu treffen. Das vorgeschlagene Benennungsschema erwartete, dass Spitznamen innerhalb der Netzgemeinschaft eindeutig sind, und sah eine Diskussion vor, wenn doppelte oder übermäßig lange Namen gewählt wurden. Es spezifizierte weder ein Veto des NIC, einen Ablehnungstest, eine endgültige Entscheidungsregel, eine Ausnahme noch einen Einspruch.

Im Januar 1974 beschrieb dieRFC 608den offiziellen Hostnamen als eine Zeichenkette, die durch Verhandlung zwischen dem Host und dem NIC erhalten wurde. Sie legte Zeichen- und Formateinschränkungen fest, identifizierte Feinlers NLS-Quelldatei und schlug die periodische Generierung einer maschinenlesbaren ASCII-Ausgabe vor. Sie erklärte nicht, wie umstrittene Verhandlungen endeten oder wer bei einem Scheitern der Diskussion obsiegte.

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

Die vertretbare Zusammensetzung ist daher bescheiden. Ein Host kommunizierte seinen bevorzugten Namen über einen Verbindungsagenten. Veröffentlichte Konventionen regelten die Form dieses Namens, Eindeutigkeit der Spitznamen wurde erwartet, und doppelte oder lange Auswahlen konnten Diskussion auslösen. Das SRI unterhielt eine Quelle, aus der es eine gemeinsame Datei generierte. Die Standorte riefen die Datei ab und integrierten ihren Inhalt in lokale Systeme. 1982 wurde die Verantwortung des Benutzers für die lokale Übersetzung ausdrücklich dargelegt.

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

Dies ist die erste Grenze der Host-Tabellen-Autorität. Das gemeinsame Register konnte bestimmen, welchen Namen ein Entitätssystem erkennt, ohne zu entscheiden, ob der zugrunde liegende Computer existierte, ob eine physische Leitung installiert war oder ob eine Organisation im Netzwerk zugelassen war. Seine Auswirkungen waren operativ und manchmal schwerwiegend für die namensbasierte Nutzung, aber sie waren nicht identisch mit der Kontrolle der gesamten Konnektivität.

Vier unterschiedliche Tabellen und die Notwendigkeit einer gemeinsamen Datei

Die Online-Hostdatei beantwortete ein beobachtetes Koordinationsproblem. Im Dezember 1973 beschrieb dieRFC 606vier zugängliche TENEX-Systeme —SRI-ARC,BBN-TENEX,USC-ISIundPARC-MAXC— deren Zuordnungen zwischen Hostnamen und Adressen unterschieden. Keine war vollständig, und der Autor glaubte, dass jede in einiger Hinsicht von der offiziellen Liste abwich.

Diese Beweise sollten nicht aufgebläht werden, um zu behaupten, dass jeder ARPANET-Standort eine ungenaue Tabelle hatte. Sie belegen eine Abweichung bei vier benannten Systemen. Selbst diese begrenzte Feststellung reichte aus, um die Kosten einer getrennten Wartung zu demonstrieren. Eine Person, die von einer Maschine zur anderen wechselte, konnte auf unterschiedliche Antworten stoßen. Ein für eine lokale Umgebung geschriebenes Programm konnte fehlschlagen, wenn es auf eine andere übertragen wurde. Ein neu hinzugefügter oder umbenannter Host konnte an einem Standort erkannt werden, während er an einem anderen unbekannt blieb.

Die RFC 606 schlug eine zentral generierte maschinenlesbare Datei vor, die vom NIC gepflegt wurde. Sie unterschied die beiden Hauptfakten eines Eintrags – den Hostnamen und die Hostadresse – von optionalen Attributen wie Hoststatus, Protokollverhalten und Spitznamen. Ihr Autor warnte davor, dass die Attribute nicht unbedingt vollständig sein müssten und nicht die Protokollverhandlung, Mundpropaganda oder andere Mittel zur Entdeckung der Eigenschaften eines Hosts ersetzen sollten.

Der Vorschlag war bewusst spezifisch: Er zielte darauf ab, inkompatible lokale Listen zu lösen, nicht eine umfassende Verfassung für die Netzwerkteilnahme zu etablieren.

Die RFC 608 akzeptierte die Idee der zentralen Datei und berichtete, dass sie die Unterstützung des ARPA Information Processing Techniques Office hatte. Feinler pflegte die Quelle im NLS-Format des SRI, während ein Programm periodisch die ASCII-Verteilungsdatei generieren sollte. Anfangs würden die generierten Einträge den offiziellen Namen, die dezimale Hostadresse und den Status enthalten. Weitere Informationen könnten hinzugefügt werden, sobald die Daten verfügbar wurden.

Das Dokument erlaubte auch ein Netzwerkpräfix für Hosts außerhalb von ARPANET und zeigte, dass die Autoren bereits eine breitere Vergleichsmenge als die ARPANET-Hostpopulation in Betracht zogen. Es identifiziert nicht alle tatsächlich eingeschlossenen externen Hosts.

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

Die RFC 627 setzte den Vorschlag in einen angekündigten Dienst um. Sie 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-Adress-Übersetzung bereitstellten, wurden ermutigt, sie zu verwenden, aber nicht dazu verpflichtet. Das Dokument lieferte Kanäle für Ergänzungen und Korrekturen, aber die Existenz eines Kanals beweist nicht die erforderliche Zeit, die geforderten Beweise oder das verfügbare Rechtsmittel, wenn eine Anfrage abgelehnt wurde.

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

Ein fehlerhafter Eintrag konnte dennoch materielle Auswirkungen haben. Ein namensbasiertes Programm konnte den Verkehr zur registrierten Adresse statt zur vorgesehenen Maschine leiten. Ein fehlender Eintrag konnte die Software daran hindern, den angeforderten Namen zu übersetzen. Eine verzögerte lokale Aktualisierung konnte ein veraltetes Ergebnis bewahren. Das genaue Verhalten hing vom lokalen Betriebssystem und der Anwendung ab. Die RFCs rechtfertigen keine universelle Behauptung, dass jede Auslassung eine Trennung verursachte oder dass jeder ungenaue Eintrag denselben Fehler erzeugte.

Die März-Verschiebung veranschaulicht den engeren Vorschlag. NachdemNICnachOFFICE-1verschoben worden war, würde ein Standort, der die Änderung von RFC 620 implementierte, den Spitznamen Standort 53 zuordnen. Ein veralteter Standort könnte ihn weiterhin Standort 2 zuordnen. Die Verschiebung des Dienstes vom SRI erfolgte unabhängig von der entfernten Tabelle, während der Nutzen des gemeinsamen Spitznamens von der entfernten Übernahme abhing. Das Register war folgenreich, weil andere Maschinen darauf handelten.

Die Namen begannen mit den Hosts, nicht mit einem unbegrenzten Veto des NIC

Die gemeinsame Datei entstand nicht aus einer etablierten Regel, die es dem NIC erlaubte, jeden gewünschten Namen zuzuweisen. Die RFC-Diskussion von 1971 dokumentiert eine substanzielle Meinungsverschiedenheit über die Benennung.

DieRFC 226verbreitete einen vorgeschlagenen Satz von Mnemoniken und lud zu Einwänden ein. Es folgten konkurrierende Vorschläge. Einige Entitäten bevorzugten kurze Kennungen; andere wollten Namen, die institutionelle und Projektidentitäten bewahrten. Die Debatte war nicht nur kosmetisch. Namen erschienen in Befehlen, Dokumenten und Benutzergewohnheiten. Eine Benennungsregel verteilte daher Nachteile und Anerkennung sowie Zeichen.

In derRFC 237argumentierte das NIC, dass es ein logisches Gremium sei, um den Benennungsstandard zu pflegen, und schlug vor, neuen Hosts Namen zuzuweisen, sobald die Network Working Group die Syntax und die aktuelle Liste geklärt hätte. Dies war ein institutioneller Vorschlag des Dienstbetreibers. Es belegt, was das NIC als seine Rolle wünschte, und nicht, dass jede angeschlossene Organisation oder eine übergeordnete öffentliche Autorität den gesamten Anspruch akzeptierte.

Die RFC 273 reagierte auf das Scheitern früherer Vorschläge, akzeptiert zu werden. Sie besagte, dass Hosts über ihre Verbindungsagenten ihre eigenen formalen Namen wählen sollten, gegebenenfalls vorbehaltlich Diskussion, wenn sie doppelte oder übermäßig lange Namen auswählten. Hosts derselben Institution sollten dieselbe institutionelle Mnemonik verwenden. Ein Spitzname sollte innerhalb der Netzgemeinschaft eindeutig sein.

Die Sprache etabliert die 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 zunichtemachen, aber die technische Inkompatibilität allein offenbart nicht den administrativen Rechtsbehelf. Der NIC könnte einen Standort überredet haben, einen anderen Namen zu wählen; ein Sponsor könnte vermittelt haben; Standorte könnten eine informelle Konvention vereinbart haben; oder eine Meinungsverschiedenheit könnte ungelöst geblieben sein.

Eine vollständige Akte wäre erforderlich, um diese Möglichkeiten zu unterscheiden.

DieRFC 289, veröffentlicht im Dezember 1971, berichtete, dass fast alle Standorte mit den gewünschten Namen geantwortet hatten. Ihr Titel, „Was wir hoffen, eine offizielle Liste von Hostnamen zu sein“, bewahrt den vorläufigen Charakter der Übung. Die entstehende Liste spiegelte eine Aufforderung und Antwort von Standorten innerhalb einer begrenzten ARPANET-Gemeinschaft wider. Sie war weder eine einseitige private Erfindung noch das Ergebnis einer globalen öffentlichen Delegation.

Die Rolle des Verbindungsagenten erfordert ebenfalls Vorsicht. Die RFC 273 verwendete Verbindungsagenten als Kanal, über den Hosts Namen wählten und kommunizierten. EinFindbuch des Computer History Museum zu den SRI ARC/NIC-Archivengibt an, dass technische Verbindungsagenten im Allgemeinen nicht die Befugnis hatten, im Namen der Standortverwaltung zu sprechen. Das Findbuch beschreibt die spätere Schaffung einer Host-Administrator-Rolle, deren Inhaber Standorthandlungen autorisieren konnte. Da das Findbuch einen längeren Zeitraum abdeckt, kann es nicht einfach auf jeden Austausch von 1971 zurückprojiziert werden. Es warnt jedoch davor, „Verbindungsagent“ als Synonym für institutionelle Führungskraft zu behandeln.

Das Höchste, was man mit Sicherheit sagen kann, ist, dass der Host der ursprüngliche Wähler im veröffentlichten Verfahren von 1971 war, der Verbindungsagent der Kommunikationskanal war und das NIC das gemeinsame Ergebnis pflegte. Die Syntax und die erwartete Eindeutigkeit schränkten ein, was im gemeinsamen Namensraum funktionieren konnte. Die Dokumente offenbaren kein vollständiges Schiedssystem.

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

Der ARPA-Dienstvertrag und die Übertragung an die DCA

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

ARPANET war ein bestimmtes Paketvermittlungsnetz, das von der Advanced Research Projects Agency innerhalb des US-Verteidigungsministeriums eingerichtet wurde. Die ARPA finanzierte das Forschungsprogramm, wählte Auftragnehmer aus und unterstützte Entitätsforschungszentren. Die Behörde wurde 1972 zur Defense Advanced Research Projects Agency. „ARPA“ ist daher für die Gründung des Netzwerks und die frühe Benennungsdebatte angemessen, während „DARPA“ in den Aufzeichnungen der späteren Periode erscheint.

DerARPANET-Abschlussbericht, erstellt 1978, gibt an, dass das Stanford Research Institute einen Vertrag zur Entwicklung und zum Betrieb eines Network Information Center für ARPANET erhielt. Die Arbeit begann parallel zur Netzwerkimplementierung im Jahr 1969. Der Bericht beschreibt einen Dienst, der Listen von Entitäten und Verteilungen pflegte, technische Dokumente archivierte, Informationen über Host-Ressourcen bereitstellte, Zugang zum SRI-NLS-System bot und die ARPANET-Protokollspezifikationen pflegte.

Dies etabliert eine Sponsor-Auftragnehmer-Beziehung. Die ARPA kaufte einen Informationsdienst für das Netzwerk und die Forschungsgemeinschaft, die sie unterstützte. Das SRI war verpflichtet, alles zu tun, was der Vertrag verlangte, und die ARPA hatte das entsprechende Recht auf vertragliche Leistung. Der öffentliche Bericht reproduziert nicht die anfängliche Leistungsbeschreibung, Nachträge, Abnahmekriterien, Sanktionen, Datenklauseln oder Entscheidungsregeln über Hostnamen. Er kann daher nicht den vollständigen rechtlichen Inhalt dieser Verpflichtung belegen.

Die mit ARPANET verbundenen Standorte waren institutionell vielfältig. Sie umfassten Universitäten, Forschungsinstitute, Regierungslabors, Militäreinrichtungen und private Unternehmen. Die Vielfalt der Rechtsformen machte nicht jeden Standort zu einem nicht verbundenen öffentlichen Betreiber. Viele nahmen durch föderale Sponsorschaft, Verträge oder genehmigte Missionsbeziehungen teil. Gleichzeitig verhindert das Fehlen der zugrunde liegenden Vertragsinstrumente die Behauptung, dass jede angeschlossene Organisation eine identische Vertragsklausel hatte, die die Einhaltung der Host-Tabelle verlangte.

Der direkteste narrative Bericht über die Übertragung von der ARPA an die Defense Communications Agency ist gestaffelt und datiert. Der Abschlussbericht beschreibt ein ARPA-DCA-Memorandum, wonach das ARPANET-Management am 1. Juli 1975 an die DCA übertragen wurde. Er verzeichnet auch eine sechsmonatige Übergangsphase bis zum 31. Dezember 1975, in der die ARPA die DCA weiterhin unterstützte, während die DCA die Managerrolle übernahm. Ein detaillierter Übergangsplan war im Juni abgeschlossen worden.

Der Bericht gibt an, dass das übertragene Netzwerk als DoD-Einrichtung für Regierungsaktivitäten betrieben werden sollte. Die DCA würde den Betrieb und die Wartung durch eine Kostenverteilungsvereinbarung finanzieren, an der die ARPANET-Sponsoren beteiligt waren. Die DCA sollte zunächst BBN und das SRI für den Netzbetrieb, die Wartung und die NIC-Funktionen beauftragen. Der Bericht besagt, dass klar impliziert war, dass die DCA später, sicherlich nach dem ersten Jahr, andere Auftragnehmer auswählen könnte.

Dies ist ein Beleg für die Möglichkeit eines institutionellen Austauschs auf der Ebene der Auftragnehmerauswahl. Es beweist nicht, dass die DCA eine portierbare vollständige Kopie jedes NIC-Datensatzes, uneingeschränkte Rechte an den vom Auftragnehmer erstellten Daten, einen getesteten Übergangssatz oder einen durchsetzbaren Rechtsbehelf für jeden Serviceausfall besaß. Ein Kunde kann grundsätzlich in der Lage sein, einen anderen Anbieter auszuwählen, steht aber vor gewaltigen praktischen Hürden bei der Übertragung von Personalwissen, Software, Archiven, aktuellen Aufzeichnungen und Standortbeziehungen.

Eine DCA-Veröffentlichung von 1978, indiziert alsARPANET Information Brochure, gibt ebenfalls den 1. Juli 1975 als Datum der Managementübertragung an. Das Findbuch des Computer History Museum präsentiert einen widersprüchlichen retrospektiven Bericht: Es heißt, der ARPANET-Betrieb sei 1973 an die DCA übertragen worden und die DCA-Vertragsfinanzierung habe das SRI-NIC nach 1974 unterstützt.

Der Konflikt muss sichtbar bleiben. Die formale Memorandum-Chronologie im Abschlussbericht liefert ein genaues Übergabedatum und eine Übergangsphase. Das Findbuch liefert andere summarische Daten, aber nicht das zugrunde liegende Instrument, das sie angleichen würde. Es heißt auch, das NIC sei 1973 zu einem separaten Projekt geworden, was eine andere institutionelle Änderung als die Übertragung des ARPANET-Managements ist. Ohne die relevanten Verträge und Verwaltungsunterlagen können die Betriebserklärung von 1973 und die Finanzierungserklärung nach 1974 nicht in eine einzige, lückenlose Chronologie umgewandelt werden.

Nach der formellen Übertragung konnte die DARPA weiterhin Forschung sponsern, die ARPANET nutzte, während die DCA das operative Netzwerk verwaltete. Das DoD war die übergeordnete Regierungsumgebung; DARPA und DCA hatten darin unterschiedliche Funktionen. Das SRI blieb ein Auftragnehmer, der NIC-Dienste erbrachte, und wurde nicht selbst zur Regierung. Die Entitätsstandorte betrieben Hosts. Die Host-Verbindungsagenten und späteren Kontaktrollen übermittelten Informationen und Anweisungen. Diese Rollen getrennt zu halten, verhindert, dass die Beschaffungsbefugnis mit universeller Befugnis verwechselt wird.

Die Aufnahme in ARPANET war keine Entscheidung der Host-Tabelle

Die Host-Tabelle verzeichnete Maschinen in einer operativen Umgebung, aber die Registerpflege durch das SRI machte das SRI nicht zur alleinigen Autorität, die entschied, wer ARPANET beitreten konnte.

DasARPANET-Verzeichnis vom Dezember 1978beschrieb die Teilnehmerkategorien und das Verfahren zur Erlangung des Dienstes. Sein Rahmen platzierte Aufnahme und Sponsorschaft in der DCA-Netzwerkmanagementstruktur. Ein potenzieller Teilnehmer musste einen akzeptablen Regierungszweck, Sponsorschaft und verfügbare Einrichtungen haben. Diese Entscheidungen betrafen den Zugang zu einem bestimmten verwalteten Netzwerk.

Die Unterscheidung ist grundlegend. Die DCA konnte die Teilnehmerberechtigung für ARPANET verwalten. Das SRI konnte das Verzeichnis und die Host-Informationen pflegen, die nach oder um die Aufnahme herum verwendet wurden. Ein Eintrag in der Host-Tabelle könnte für die praktische gemeinsame Nutzung notwendig sein, aber die Host-Registrierung war nicht derselbe institutionelle Akt wie die Genehmigung des Organisationsanschlusses, die Installation eines Interface Message Processors, die Bereitstellung einer Schaltung 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 Interkonnektionsumgebung, in der ARPANET, Paketfunksysteme, Satellitensysteme und andere Netzwerke die Internetprotokolle und gemeinsame Koordinationsinformationen verwenden konnten. Das breitere entstehende Internet war noch größer: eine sich verändernde Menge von Netzwerken, Experimenten und Betreibern, deren rechtliche, vertragliche und technische Beziehungen nicht einheitlich waren.

Im September 1981 listete dieRFC 790die zugewiesenen Internet-Netzwerknummern für viele benannte Netzwerke auf, darunter ARPANET, UCLNET, CYCLADES, TELENET, das britische Post Office EPSS, DATAPAC, TRANSPAC, LCSNET, TYMNET und eine Reihe von Paketfunk-, Satelliten-, lokalen und experimentellen Systemen. Sie identifizierte Jon Postel am Information Sciences Institute der University of Southern California als den Kontakt für die Zuweisung von Netzwerknummern.

Die Liste beweist, dass die Umgebung der zugewiesenen Nummern über eine ARPANET-Hostliste hinausging. Sie belegt nicht von selbst, dass jedes benannte Netzwerk zu diesem Zeitpunkt betrieblich verbunden war, unabhängig von staatlicher Sponsorschaft, kommerziell, nicht dem DoD zugehörig oder durch den SRI-Host-Tabellenprozess geregelt. Eine in einem Zuweisungsdokument erscheinende Nummer ist kein vollständiger Bericht über den Vertragsstatus des Netzwerks oder den tatsächlichen Verkehr.

Sie trennt auch Funktionen, die spätere Geschichten manchmal vermischen. Postels Rolle bei der Nummernzuweisung bei USC-ISI betraf Netzwerk- und Protokollparameter. Das SRI pflegte die Host-Tabelle und den Namensdienst. Die DCA verwaltete ARPANET und beauftragte den NIC-Dienst. Die DARPA setzte die Forschungsförderung fort. Keine dieser Tatsachen macht einen einzelnen Akteur zum alleinigen Autor des gesamten entstehenden Internets.

Der Ausdruck „erstes Internet-Register“ erfordert daher einen definierten Vergleich. Die Host-Tabelle war nicht das erste Verzeichnis, das jemals von einer Computerorganisation gepflegt wurde, und die Datei von 1974 war kein Register für ein globales öffentliches Internet. Sie war eine frühe gemeinsame maschinenlesbare Referenz von Namen und Adressen in der ARPANET-Internet-Linie. 1982 umfasste ihr Nachfolgeformat Netzwerke, Gateways und Internet-Adressen und wurde von ihren Betreibern als eine globale Datenbank von Hostnamen und -adressen beschrieben.

Ihre historische Bedeutung liegt in der wachsenden 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

Die RFC 810 markierte eine Änderung in Umfang und institutioneller Sprache. Veröffentlicht am 1. März 1982 von Feinler, Ken Harrenstien, Zaw-Sing Su und Vic White vom Network Information Center von SRI International, gab sie an, dass die alte ARPANET-Host-Tabelle den Anforderungen der DoD-Gemeinschaft oder der Interkonnektion nicht mehr gerecht wurde. Das neue Format umfasste Netzwerk-, Gateway- und Host-Einträge, Internet-Adressen, Betriebssysteme und Protokollinformationen.

Die Tabelle war auf dem HostSRI-NICüber FTP und über den Host-Namens-Server verfügbar. Die RFC identifizierte den Server als einen Dienst, der vom ARPANET-NIC im Auftrag der DCA unterhalten wurde. Sie wies auch ausdrücklich die Verantwortung für die Übersetzung dem Benutzer zu: Jeder, der die Tabelle konsumierte, musste sie in das lokal erforderliche Format konvertieren.

Ihre siebte Annahme enthielt die stärkste operative Sprache in der Host-Tabellen-Aufzeichnung. Namen und Adressen für DoD-Netzwerke, -Gateways und -Hosts mussten beim NIC ausgehandelt und registriert werden, bevor sie verwendet wurden und bevor Verkehr durch einen DoD-Host geleitet wurde. Dies war eine veröffentlichte Voraussetzung, die das Verhalten des 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. Die RFC 810 identifiziert keinen Monitor, der Registrierungen überprüft, keine Routerregel, die unregistrierten Verkehr zurückweist, keine Sanktion für Nichteinhaltung, keine Compliance-Rate oder eine bestimmte Kommunikation, die blockiert wurde. Der Unterschied ist wichtig. Eine Spezifikation kann ein erforderliches Verhalten definieren, ohne zu beweisen, wie konsequent die Betreiber es implementierten.

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, wenn diese Informationen bereitgestellt wurden und solange sie benötigt wurden, in Erwartung von miteinander kommunizierenden Namenservern. Es identifizierte weder jeden tatsächlich eingeschlossenen Nicht-DoD-Eintrag noch verhängte es dieselbe ausdrückliche Voraussetzung für alle externen Betreiber.

Das neue Format hatte auch eine gestaffelte Einführung. Die RFC 810 legte den 1. Mai 1982 als Umschaltdatum fest. Während des Monats Mai enthielt der vorhandene PfadHOSTS.TXTnoch 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 das Material im alten Format über einen anderen Pfad zugänglich blieb. Nach dem 1. August würde die alteHOSTS.TXT-Format, das in RFC 608 spezifiziert wurde, nicht mehr unterstützt.

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

DieRFC 811, am selben Tag veröffentlicht, spezifizierte den Online-Host-Namens-Server. Ein Programm konnte nach einem Hostnamen oder einer Hostadresse fragen oder die gesamte Tabelle anfordern. Der Server konnte Host-, Gateway- oder Netzwerkdatensätze zurückgeben. Wenn ein angeforderter Name fehlte, nahm der definierte Fehler die FormERR: NAMNFD: Name nicht gefunden:an. Andere Fehler waren möglich, darunterTMPSYS, was einen vorübergehenden Systemausfall und eine Aufforderung zum späteren Wiederholen bedeutete.

Diese Semantik gehört zum Protokoll des SRI-NIC-Servers. Sie sollte nicht auf jeden lokalen Resolver projiziert werden, der eine heruntergeladene Kopie verwendet. Eine lokale Suche in einer Tabelle ohne einen Eintrag konnte fehlschlagen, einen zusätzlichen Treffer verwenden, den Benutzer auffordern oder sich systemabhängig verhalten. Das Fehlen eines Namens aus einer lokalen Kopie und eineNAMNFD-Antwort des Servers waren verwandte, aber nicht notwendigerweise identische Ereignisse.

Die RFC 811 beschrieb ihre Datenbank als eine Erweiterung der alten ARPANETHOSTS.TXT-Datei und bezeichnete die zentrale Verwaltung als eine vorübergehende Lösung auf dem Weg zu einem dezentralisierten, verteilten Adress-Übersetzungs-Dienst. Diese institutionelle Aussage ist aus zwei Gründen wichtig. Sie zeigt, dass das SRI den Dienst als Übergangsmechanismus und nicht als dauerhafte Architektur verstand, und sie bestätigt, dass sich Population und Zweck der Tabelle über die ursprüngliche ARPANET-Liste hinaus erweitert hatten. Sie beweist nicht unabhängig eine universelle Abdeckung.

In den frühen 1980er Jahren wurde das NIC zunehmend mit der Defense Data Network-Umgebung assoziiert, und historische Sammlungen verwenden später den Namen DDN-NIC für den Dienst. Diese spätere Bezeichnung sollte nicht in den Vertrag von 1969 oder die Host-Namensdebatte von 1971 zurückprojiziert werden. SRI-ARC, das SRI-NIC, SRI-NIC und DDN-NIC beschreiben organisatorische und hostbezogene, aber zeitlich unterschiedliche Kontexte.

Was die Archive zeigen können – und was fehlt

Die RFC-Reihe ist außergewöhnlich reich an Vorschlägen, Spezifikationen und Ankündigungen. Sie ist als Aufzeichnung einzelner Verwaltungsfälle viel schwächer.

Das Findbuch des Computer History Museum identifiziert relevante Sammlungen: NIC-Vorschläge und -Verträge, Fortschrittsberichte, Namens- und Adressierungsaufzeichnungen, Host-Tabellen, Referenzdienst-Dokumentation, Korrespondenz und Aufzeichnungen über offizielle Netzwerkkontakte. Es heißt, der erste NIC-Vertrag sei nicht in Aufgaben gegliedert gewesen und spätere Verträge seien aufwändiger geworden. Es beschreibt auch die technischen Verbindungsagenten, Host-Administratoren, Knoten-Standortkoordinatoren und andere Kontakte, über die Informations- oder Aktionsnachrichten flossen.

Ein Findbuch belegt die Existenz, den ungefähren Gegenstand und die Anordnung der Aufzeichnungen. Es offenbart nicht den Inhalt jedes Vertrags, Briefs oder jeder Entscheidung. Seine Beschreibungen können nicht beweisen, dass ein Hostnamenantrag gewährt, abgelehnt oder in einer bestimmten Weise eskalierend behandelt wurde. Die zugrunde liegenden Dokumente müssten geöffnet und verglichen werden.

Es wurde hier kein vollständiger Antragsdatensatz vorgelegt, der den vorgeschlagenen Hostnamen, die Fragen des NIC, die Antwort des Standorts und die endgültige Entscheidung zeigt. Kein erhaltener Fall demonstriert eine NIC-Ablehnung aufgrund eines Duplikats, einen erfolgreichen Einspruch, eine Sponsorenausnahme oder einen Rechtsbehelf zur Korrektur. Kein vollständiges Register liefert Bearbeitungszeiten oder Fehlerraten. Die Kontaktinformationen in RFC 627 beweisen, dass ein Korrekturkanal existierte; sie beweisen nicht die damit erzielten Ergebnisse.

Die fehlenden Verträge sind aus einem anderen Grund wichtig. Ein Bundesvertrag kann ein Recht auf Leistung verleihen, ohne das Eigentum an jedem Datensatz, das Eigentumsrecht an einem technischen System oder uneingeschränkte Rechte an den vom Auftragnehmer erstellten Daten zu verleihen. Er kann Liefergegenstände, Datenlizenzen, Übergangsunterstützung und Rechtsbehelfe spezifizieren, aber diese Konsequenzen hängen von seinen tatsächlichen Klauseln ab.

Eine viel spätereAnalyse des Government Accountability Office zu den Arrangements der föderalen Internetfunktionenunterschied sorgfältig zwischen Leistungsrechten, Datennutzungsrechten, Eigentum und Besitz. Diese Stellungnahme von 2016 betraf spätere DNS- und IANA-Arrangements und liefert nicht die fehlenden Bedingungen der SRI-Verträge der 1970er Jahre. Ihr Wert hier ist methodisch. Bundesfinanzierung allein kann nicht verwendet werden, um auf jedes Eigentum oder jedes Übergangsrecht zu schließen.

Der Abschlussbericht stützt eine engere Schlussfolgerung: Die DCA beabsichtigte ursprünglich, das SRI für die NIC-Funktion zu behalten, und konnte später einen anderen Auftragnehmer verwenden. Dies zeigt die in Betracht gezogene Möglichkeit eines Anbieterwechsels. Es belegt nicht, dass der Wechsel ohne Verzögerungen, Datenstreitigkeiten, Softwarekonvertierung, Verlust von institutionellem Wissen oder Serviceunterbrechung erfolgen konnte.

Aufzeichnungen über die Implementierung fehlen auch für die Verkehrsbedingung von RFC 810. Um von einer veröffentlichten Regel zu einer nachgewiesenen Durchsetzung zu gelangen, würde man DCA-Richtlinien, Host-Software, Prüfprotokolle, Vorfallberichte, Sanktionen oder einen dokumentierten blockierten Datenstrom benötigen. Ohne dieses Material kann der Artikel den erklärten Geltungsbereich der Regel, aber nicht ihre beobachtete Stärke identifizieren.

Das Schweigen muss in beide Richtungen wirken. Das Fehlen eines veröffentlichten Berufungsverfahrens beweist nicht, dass keine informelle Eskalation existierte. Telefonanrufe, Netzpost, NLS-Austausch und Sponsorvermittlung könnten Streitigkeiten ohne RFC gelöst haben. Umgekehrt beweist das Fehlen veröffentlichter Beschwerden nicht, dass jede Entität den Prozess als legitim ansah oder dass jede Aktualisierung rechtzeitig erfolgte.

Die resultierende Unsicherheit ist institutionell und nicht einfach antiquarisch. Wenn Anfragen regelmäßig durch transparente Standortbestätigung korrigiert wurden, erscheint der Dienst klerikaler und kooperativer. Wenn das NIC Einträge ohne Erklärung ablehnen konnte und keine Sponsorenüberprüfung existierte, würde dieselbe Datei eine andere Governance-Bedeutung tragen. Die öffentlichen Beweise stützen weder das eine noch das andere Extrem als allgemeinen Bericht.

Die Alternative der lokalen Liste und ihre tatsächlichen Kosten

Eine historisch realistische 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, erhielt Änderungen durch persönliche Kommunikation und übersetzte entfernte Informationen in sein eigenes Betriebssystem.

Bei vier Standorten könnte dies handhabbar sein. Die Administratoren kannten sich, Protokolldesigner trafen sich regelmäßig, und eine Korrektur konnte per Telefon, Dokument oder Netzpost verbreitet 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.

Die Wartungslast wuchs schnell. Bei zehn Standorten, die jeweils Einträge für die neun anderen unterhielten, konnte es bis zu 90 gepflegte lokale Zuordnungen geben. Bei hundert Standorten könnten es bis zu 9.900 sein. Diese Zahlen beschreiben gepflegte Kopien, die an Standorten gehalten werden, nicht 90 oder 9.900 separate bilaterale Beziehungen. Die Anzahl der tatsächlich benötigten Zuordnungen würde von den Kommunikationsmustern abhängen, aber jedes neue Ziel schuf mehr Stellen, an denen Informationen veralten konnten.

Ein Host-Zusatz 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 umgesetzt werden. Betreiber müssten identifizieren, welche Ausgabe sie hatten, widersprüchliche Berichte vergleichen und feststellen, ob ein scheinbarer Serviceausfall vom Netzwerk, vom entfernten Host oder von einer veralteten Zuordnung herrührte.

Die RFC 606 liefert die beobachtete Warnung: Die vier genannten TENEX-Systeme hatten bereits unvollständige und unterschiedliche Tabellen. Sie quantifiziert nicht die durch diese Unterschiede verursachten Ausfälle. Die Abweichung selbst demonstriert duplizierte Wartung und inkonsistente Antworten.

Eine gemeinsame Quelle reduzierte diese Last. Der betroffene Host konnte Informationen über einen anerkannten Kanal übermitteln. Das SRI konnte eine einzige Ausgabe generieren. Standorte konnten dieselbe Datei abrufen und ihren lokalen Stand mit einer datierten Referenz vergleichen. Ein Support-Mitarbeiter, der eine Anomalie untersuchte, hatte einen Anlaufpunkt, von dem aus er beginnen konnte.

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 eine Verzögerung zwischen einer gemeldeten Änderung und ihrem Erscheinen in der nächsten Ausgabe ein. Der Abruf konnte fehlschlagen, wenn der Host-Server oder ein Netzwerkpfad nicht verfügbar war. Die lokale Installation konnte nach einem erfolgreichen Abruf in Verzug geraten. Die Architektur zentralisierte die Kompilierung, nicht alle operativen Aufgaben.

Eine gemeinsame Quelle garantierte auch nicht die Wahrheit. Das SRI war auf Hosts und Kontakte angewiesen, um genaue Informationen zu liefern. Eine von einem Standort gelieferte fehlerhafte Adresse konnte in das Master gelangen. Eine korrekte zentrale Aktualisierung konnte durch eine veraltete lokale Bereitstellung untergraben werden. Ein Konflikt konnte andauern, wenn das Verfahren zu seiner Beilegung unklar war. Die Referenz machte die Abweichung sichtbar und reduzierte die Duplizierung, aber sie beseitigte nicht die Notwendigkeit einer Überprüfung.

Die Alternative der lokalen Liste erklärt, warum Organisationen sich auf die NIC-Datei verließen, ohne eine Theorie der unbegrenzten Befehlsgewalt zu benötigen. Eine einzige gepflegte Antwort war kostengünstiger zu konsumieren als viele unabhängig rekonstruierte Antworten. Software und Dokumentation wurden zuverlässiger, wenn sie gemeinsame Namen verwendeten. Die daraus resultierende Abhängigkeit verlieh dem gepflegten Register operative Stärke.

Ein gemeinsames Register mit mehr als einem Verteiler

Eine zweite zeitgenössische machbare Alternative hätte eine einzige kanonische Datei bewahrt, während Speicherung und Abruf breiter verteilt wurden.

Die Idee tauchte in zeitgenössischen Dokumenten auf. DieRFC 623schlug vor, dass das NIC das Master behält, während ein anderer Host eine häufig aktualisierte Sekundärkopie unterhält. Ihr Autor meldete sich freiwillig für die UCSB und schlug eine tägliche Synchronisation vor. Der Zweck war Verfügbarkeit: Wenn der NIC-Host die Datei nicht bedienen konnte, könnten Benutzer den Sekundären versuchen.

DieRFC 625akzeptierte das Prinzip, dass mehr als ein Host eine Kopie unterhalten sollte, und begrüßte die UCSB als potenziellen Sekundären. Sie widersprach dem Ersatz von FTP durch ein dediziertes Abrufprotokoll. Die RFC 627, später im März veröffentlicht, lud jeden Host, der eine Sekundärkopie unterhalten wollte, ein, das NIC zu kontaktieren.

Diese Aufzeichnungen belegen einen vorgeschlagenen und akzeptierten Replikationsentwurf. Sie beweisen nicht, dass die UCSB oder ein anderer Host einen funktionsfähigen Spiegel betrieben hat. Die Bestätigung würde eine Betriebsanzeige, ein Serverprotokoll, eine archivierte Sekundärdatei, ein Host-Handbuch oder einen späteren Bericht erfordern. Der Vorschlag sollte nicht als Einsatz umgeschrieben werden.

Wenn ein solcher Sekundärer funktioniert hätte, hätte er zeitgemäße Ressourcen benötigt. Der Standort benötigte 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 müssten wissen, welchen Host sie kontaktieren und wie sie die neueste kanonische Version erkennen können. Der Sekundäre benötigte eine Regel, um zu wissen, was zu tun ist, wenn seine lokale Kopie von der des SRI abwich.

Ein Ausfall könnte die Angleichung erschweren. Angenommen, der Sekundäre verpasst zwei Aktualisierungen, während das SRI verfügbar blieb, und kehrt 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 das SRI nicht verfügbar war, während eine umstrittene Korrektur eintraf, müsste der Sekundäre wissen, ob er die Änderung veröffentlichen oder einfach weiterhin das letzte bestätigte Master bedienen darf.

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

Die Standortbestätigung hätte ohne moderne Infrastruktur gestärkt werden können. Vor der wöchentlichen Veröffentlichung hätte das NIC eine vorgeschlagene Änderung an den betreffenden Verbindungsagenten oder den autorisierten Standortkontakt senden können. Eine datierte Änderungsmitteilung hätte die generierte Datei begleiten können. Sekundäre Hüter könnten angekündigte Änderungen mit der erhaltenen Datei vergleichen. Standorte könnten Anomalien im Verhältnis zu einer bestimmten Ausgabe melden, anstatt zu einer undatierten lokalen Kopie.

Diese Verfahren hätten Kosten verursacht. Kontakte müssten antworten. Korrekturen könnten auf Bestätigung warten. Das Personal müsste Protokolle führen und unbeantwortete Anfragen abgleichen. Ein sich schnell ändernder Host könnte einen wöchentlichen Zyklus zu langsam finden, während eine häufigere Verteilung Rechenleistung, Netzwerkauslastung und Arbeitsbelastung des Betreibers erhöhte. Eine formelle Überprüfung könnte die Rechenschaftspflicht verbessern, aber gleichzeitig dringende Korrekturen verzögern.

Der Auftragnehmerwechsel stellte ein größeres Problem dar. Die Fähigkeit der DCA, einen anderen Anbieter auszuwählen, garantierte nicht die reibungslose Ablösung des SRI. Ein Nachfolger benötigte die aktuelle kanonische Datei, die Software, die sie generierte, die Dokumentation der Formate und Veröffentlichungspläne, ausstehende Anfragen, den Korrekturverlauf, Kontaktlisten, Personalwissen und Zugang zur Dienstumgebung. Wenn der Vertrag keine Datenlieferung oder Datennutzungsrechte spezifizierte, könnte der Übergang rechtlich ebenso wie operativ schwierig werden.

Die überlebenden öffentlichen Dokumente belegen nicht, dass diese Übergangsmaterialien als durchsetzbare Liefergegenstände existierten. Sie zeigen, dass ein anderer Auftragnehmer in Betracht gezogen wurde, nicht dass ein getesteter Übergangsmechanismus vorhanden war. Die Möglichkeit eines Austauschs auf dem Papier und die 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, bewahrten Änderungen und einem Ersatzdienstanbieter koexistieren. Jede Hinzufügung hätte Kosten und Verantwortlichkeiten verschoben, ohne die Notwendigkeit einer endgültigen Koordination zu beseitigen.

Eine datierte Autoritätskette, kein universelles Mandat

Zwischen 1969 und 1983 akkumulierte die Host-Tabellen-Autorität über eine Reihe unterschiedlicher Beziehungen.

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

1971 wurden Hosts eingeladen, Namen über Verbindungsagenten im Rahmen veröffentlichter Konventionen zu wählen. Die Debatte und Antwort unter den ARPANET-Entitäten lieferte eine begrenzte Peer-Akzeptanz. Die vorgeschlagene Rolle des NIC wurde durch lokale Wahl eingeschränkt, während der gemeinsame Namensraum dennoch kompatible Ergebnisse erforderte.

1973 und Anfang 1974 führten unterschiedliche lokale Tabellen zu einer gemeinsamen maschinenlesbaren Datei. Die RFCs 606 und 608 dokumentierten den Vorschlag und das Quelldesign. Die RFCs 620 und 627 dokumentierten eine spezifische standortweite Änderungsanweisung, die verfügbare ASCII-Datei, wöchentliche Aktualisierungen, die Verantwortung für den lokalen Abruf und Korrekturkanäle. Sie dokumentierten kein allgemeines NIC-Veto oder ein vollständiges Streitbeilegungssystem.

Am 1. Juli 1975, gemäß dem im Abschlussbericht beschriebenen ARPA-DCA-Memorandum, wurde das ARPANET-Management an die DCA übertragen, gefolgt von einer Übergangsphase bis zum 31. Dezember. Die DCA behielt das SRI zunächst für die NIC-Funktionen bei und konnte einen anderen Auftragnehmer in Betracht ziehen. Die widersprüchliche Behauptung einer operativen Übertragung von 1973 im Findbuch und der Finanzierungsbericht nach 1974 bleiben ungelöst.

1978 platzierte der DCA-Teilnehmerrahmen die Aufnahme in ARPANET in das staatliche Netzwerkmanagement und nicht in die SRI-Host-Tabellenpflege. Dies trennte die Befugnis, einen Teilnehmer zuzulassen, von dem Dienst, der Host-Informationen aufzeichnete und verteilte.

1981 listete die Umgebung der zugewiesenen Nummern viele Netzwerke über ARPANET hinaus auf, während die Zuweisung von Netzwerknummern mit Postel bei USC-ISI identifiziert wurde. Das Erscheinen in dieser Liste belegte nicht, dass jedes Netzwerk eine einheitliche rechtliche oder operative Beziehung zur DCA oder zum NIC teilte.

Im März 1982 spezifizierte RFC 810 eine breitere Host-Tabelle für das DoD-Internet und veröffentlichte die Vorabregistrierung als Bedingung für Namen und Adressen, die im Zusammenhang mit dem durch DoD-Hosts geleiteten Verkehr verwendet wurden. Ihre separate vorübergehende Behandlung von Nicht-DoD-Informationen markierte eine Grenze. Die Regel war explizit; ihre Durchsetzung bleibt unbewiesen. Die Umschaltung von Mai bis August zeigte zudem, dass Spezifikation, Übergang und abgeschlossene lokale Implementierung unterschiedliche Schritte waren.

Der Server von RFC 811 machte die gepflegte Antwort durch Online-Abfragen verfügbar und beschrieb die zentrale Datenbank als eine vorübergehende Brücke zu einer verteilten Namensgebung. Dieser Dienst erhöhte die Abhängigkeit von SRI-NIC, erkannte jedoch an, dass die Architektur nicht dauerhaft zentralisiert bleiben sollte.

Die Host-Tabelle übte daher ihre stärkste nachgewiesene Autorität an drei Stellen aus. Das SRI schuldete seinem föderalen Kunden Leistung im Rahmen eines Vertrags, dessen vollständige Bedingungen nicht verfügbar sind. Die DCA konnte operative Anforderungen für die DoD-Umgebung erlassen, die sie verwaltete. Entitätsmaschinen und -benutzer waren für eine konsistente namensbasierte Kommunikation auf das gemeinsame Register angewiesen.

Außerhalb dieser Beziehungen ergab sich der Geltungsbereich der Tabelle aus Interoperabilität und Adoption. Ein externes Netzwerk konnte Informationen beitragen oder die gemeinsame Datei verwenden, 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 einen globalen Wahlkreis, der dem SRI eine allgemeine Autorität delegiert.

Die Tabelle schuf auch nicht alles, was sie verzeichnete. Der Sponsor genehmigte die Netzwerkteilnahme; Auftragnehmer und Standorte stellten die Maschinen und Software; Schaltungen und Paketvermittler transportierten den Verkehr; andere Behörden verwalteten Netzwerknummern; lokale Systeme konsumierten die veröffentlichten Zuordnungen. Die NIC-Registrierung half, einen Namen gemeinhin erkennbar zu machen, aber sie schuf nicht die zugrunde liegende Organisation, die physische Verbindung oder jede numerische Zuweisung.

Ihre praktische Autorität war dennoch substanziell. Ein gemeinsamer Datensatz, der von vielen Maschinen konsumiert wird, kann das Verhalten einschränken, selbst wenn keine Legislative oder öffentliches Gremium Mitglied ist. Ein Host, der vorhersehbare Erkennung wünschte, hatte ein Interesse daran, die Benennungskonventionen zu befolgen. Ein Standort, der aktuelle Antworten wünschte, hatte ein Interesse daran, die gemeinsame Datei abzurufen. Ein DoD-Host war durch eine veröffentlichte Registrierungsvoraussetzung betroffen. Ein Nicht-DoD-Betreiber könnte Abweichung als kostspielig empfinden, weil andere Systeme die gepflegte Antwort erwarteten.

Was unbewiesen bleibt, ist ebenso wichtig. Die überlebenden öffentlichen Beweise zeigen nicht, dass das NIC die von ihm gelisteten Adressen besaß, ein externes Netzwerk nach Belieben ausschließen konnte, Sanktionen gegen jeden nicht konformen Standort verhängte oder jeden fehlenden Eintrag in eine physische Trennung umwandelte. Sie offenbaren keine vollständige Berufungsstruktur, keinen Rechtsbehelf zur Korrektur und keine Ausnahmehierarchie. Sie belegen kein übertragbares staatliches Eigentum an allen NIC-Daten.

Die frühe Host-Tabelle war dort autoritativ, wo Beschaffung, Netzwerkmanagement und Maschinenabhängigkeit zusammenkamen. Sie löste ein konkretes Problem: Inkompatible lokale Zuordnungen machten gemeinsame Namen unzuverlässig. Die zentrale Kompilierung machte eine Antwort leichter zu verteilen, zu vergleichen und zu nutzen. Diese Errungenschaft erklärt, warum das Register an Stärke gewann, bevor Namen und Adressen zu Marktvermögenswerten wurden.

Sie beweist nicht, dass der Betreiber des Registers Autorität über jedes Netzwerk erhielt, das das Register beschreiben konnte. Die historische Kette stützt eine engere Schlussfolgerung: Das SRI unterhielt eine von der Bundesregierung in Auftrag gegebene Referenz für ein gesponsertes Netzwerk, diese Referenz wurde in die Operationen des DoD-Internet integriert, und eine breitere Abhängigkeit erweiterte ihre praktische Reichweite. Der Nutzen des Registers machte es mächtig. Sein öffentliches Mandat blieb unbewiesen.