Zusammenfassung

  • Die Qualifikationserklärung von SRI aus dem Jahr 1988 enthielt Vertragsnummern, Daten, Finanzierung und Arbeitsumfang, aber öffentliche Kopien der zugrunde liegenden Verträge, Änderungen und Leistungsbeschreibungen wurden nicht gefunden, sodass die genauen Verpflichtungen, Rechtsbehelfe und sich überschneidenden Zeiträume ungeklärt bleiben.
  • Die Beschaffung durch die DCA unterstützte NIC-Dienste innerhalb der DDN- und DoD-Kette, während DDN-Betriebsregeln, die Domänenrichtlinien von IAB und DARPA, die IANA-Delegation von USC/ISI und externe Abhängigkeiten separate, dienstspezifische Brücken bereitstellten, die nicht zu einem universellen vertraglichen Mandat zusammengefasst werden können.
  • Die Übergabe von 1991 zeigt, dass der Betriebsanbieter wechselte, während Daten, Anfragekanäle und Dienste weitergeführt wurden; sie belegt weder die fehlenden Beschaffungsbedingungen noch Übergangspflichten, Eigentumsverhältnisse, Kosten oder Rechtsbehelfe für externe Nutzer.

Die Darstellung eines Auftragnehmers über seine eigene Aktenlage

Die detaillierteste öffentliche Tabelle der DDN-NIC-Vertragsnummern stammt weder aus einem unterzeichneten Vertrag der Defense Communications Agency noch aus einer Leistungsbeschreibung oder einem behördlichen Prüfbericht. Sie erscheint in einem Dokument von SRI International vom 27. Oktober 1988, das für eine völlig andere Gelegenheit erstellt wurde:Qualifications Statement for Solicitation F04701-88-R-0043: Technical Support for Global Positioning System Information Center. Das Network Information Systems Center von SRI reichte das Dokument ein, um zu demonstrieren, dass es ein geplantes ziviles GPS-Informationszentrum entwickeln und betreiben könne. Die darin enthaltene Erörterung des DDN-NIC war unternehmerische Erfahrung, die zur Unterstützung dieses Angebots vorgelegt wurde.

Diese Herkunft verändert, wie jeder Eintrag in der Tabelle gelesen werden muss. SRI berichtete, dass DCA200-83-C-0025 vom 1. Juni 1983 bis zum 31. Dezember 1985 lief und eine Finanzierung von 3.122.367 US-Dollar hatte. Es berichtete, dass DCA200-84-C-0024 vom 15. Juni 1984 bis zum 31. Januar 1987 lief, mit einer Finanzierung von 8.128.495 US-Dollar. DCA200-87-C-0020 wurde für zwei Jahresperioden ab dem 1. Februar 1987 aufgeführt, mit 3.772.115 US-Dollar für das erste Jahr und 4.121.252 US-Dollar für das zweite. Die Daten überschneiden sich.

Öffentliche Kopien der zugrunde liegenden Verträge, Änderungen und Leistungsbeschreibungen wurden nicht gefunden, so dass die Überschneidung nicht sicher als Option, separates Arbeitspaket, Übergangsvereinbarung oder Änderung der Vertragsstruktur erklärt werden kann.

SRI beschrieb auch acht Arbeitsbereiche, darunter Kern-Netzwerkinformationsdienste; Informations- und Datenbankprotokolle und -architektur; Netzzugangskontrolle und Benutzerregistrierung; das DDN- und ARPANET-Prüfpfad- und Abrechnungssystem; Namens- und Verzeichnisdienst für das DoD-Internet; und den Betrieb einer staatlichen Computereinrichtung. Es listete WHOIS, Namensdienst, Domänenregistrierung, Protokollverteilung, eine Telefon-Hotline, Benutzerregistrierung, Online-Informationsdienste, Publikationen und Software auf.

Am Ende der Tabelle stellte SRI fest, dass die eigenen Liefergegenstände ohne Überschreitungen abgeschlossen worden seien.

Diese Aussagen sind nützliche Belege dafür, was SRI 1988 über seine Erfahrungen darstellte. Sie sind keine unabhängigen Feststellungen, dass die DCA jede aufgeführte Tätigkeit unter jedem gemeldeten Vertrag bestellt hat, dass die Arbeit den behördlichen Abnahmekriterien entsprach oder dass jeder Internetnutzer zur abgedeckten Population der Beschaffung gehörte. SRI beschrieb sich selbst gegenüber einem potenziellen Kunden. Der Zweck des Dokuments begünstigte eine umfassende Darstellung von Fähigkeiten und erfolgreicher Leistung. Es bot nicht die institutionelle Distanz einer Prüfung oder der Abnahmeentscheidung eines Vertragsbeamten.

Ein Teil der gemeldeten Kette verfügt über eine separate bundesbehördliche Bestätigung. Der National Technical Information Service katalogisiert dasDDN Protocol Handbook, Volume 1: DoD Military Standard Protocolsvon 1985 als einen technischen Bericht des SRI DDN-NIC, der unter DCA200-83-C-0025 erstellt wurde. Der NTIS-Eintrag beschreibt ein Handbuch für Implementierer, die Computer an das Defense Data Network, einschließlich des ARPANET, anschließen wollten. Er identifiziert die Rollen der DCA und des DDN Program Management Office bei der Protokollstandardisierung und Konfigurationsverwaltung. Dies belegt, dass die Vertragsnummer zumindest mit diesem dokumentierten Produkt verbunden war. Es offenbart nicht den übrigen Umfang des Vertrags, seine Zahlungsstruktur, seine Rechtsbehelfe oder die Rechte von Personen, die nicht Vertragspartei waren.

Die evidenzbezogene Vorsicht ist besonders wichtig, weil die Qualifikationserklärung von SRI einige Arbeiten in ihrem Organigramm von 1988 als nicht durch den DCA-Vertrag abgedeckt kennzeichnete. Diese Anmerkung warnt davor, alles, was im selben Zentrum, von demselben Personal oder auf denselben Computern ausgeführt wurde, als Teil einer einzigen Beschaffung zu behandeln. Die DDN-Arbeiten von SRI, DARPA-bezogene Aktivitäten, Verantwortlichkeiten gegenüber der technischen Gemeinschaft und intern finanzierte Entwicklungen konnten im Network Information Systems Center koexistieren, ohne eine identische rechtliche Grundlage zu teilen.

Die anfängliche Beschaffungsfrage muss daher enger bleiben als das überlebende Dienstverzeichnis: Was verlangte die DCA von SRI zu liefern, an wen und unter welchen Aufsichts- und Abhilfevereinbarungen? Die öffentliche Beweislage beantwortet nur Teile dieser Frage. Sie identifiziert die beschaffende Behörde, den Auftragnehmer, drei gemeldete Vertragsnummern und -daten, mindestens einen zugehörigen Liefergegenstand und einen erheblichen Bestand an Dienstleistungen, die während des Zeitraums betrieben wurden. Sie liefert nicht die unterzeichneten Instrumente, die zur Rekonstruktion jeder Verpflichtung erforderlich sind.

Die nachweisbare Beschaffungskette

Die hauptsächliche institutionelle Beziehung ist auf hoher Ebene klar. Das Department of Defense lieferte den staatlichen Rahmen. Die DCA verwaltete das Defense Data Network und beauftragte SRI mit NIC-Arbeiten. SRI International war der Auftragnehmer. Das DDN-NIC war das Betriebszentrum, über das SRI Registrierungs-, Informations- und Unterstützungsdienste bereitstellte. DDN-Einrichtungen sowie dokumentierte ARPANET- und MILNET-Nutzer bildeten die Population, für die die staatliche Betriebsberechtigung am deutlichsten sichtbar ist.

DerGuide to the SRI ARC/NIC Recordsdes Computer History Museum aus dem Jahr 2011 beschreibt das erhaltene Archiv als Vorschläge, Leistungsbeschreibungen, Verträge, Änderungen, Korrespondenz, monatliche Fortschrittsberichte und vertragliche Lieferberichte enthaltend. Darin heißt es, dass die NIC-Arbeit bis 1987 aus zahlreichen Aufgaben mit zugewiesenen Aufgabenleitern und Budgets bestand. Formelle monatliche Berichte werden als bis 1991 fortlaufend beschrieben, während vertragliche Lieferberichte die Jahre 1980 bis 1990 abdecken. Das Findbuch identifiziert daher die Arten von Aufzeichnungen, die normalerweise mit der staatlichen Vertragsverwaltung verbunden sind: nummerierte Instrumente, Aufgabenstrukturen, Budgets, Berichtswesen und Änderungsdateien.

Ein Findbuch ist nicht der Inhalt dieser Dateien. Es zeigt einem Forscher, dass Aufzeichnungen existieren, wie sie organisiert sind und, in einigen Fällen, wie der Archivar sie zusammenfasste. Es legt weder den Wortlaut einer Leistungsbeschreibung fest, noch die Abnahme eines Liefergegenstands durch die Regierung, den Zahlungsanspruch des Auftragnehmers oder die Rechtsbehelfe bei mangelhafter Leistung. Der Leitfaden wurde von Elizabeth Feinler verfasst, die das NIC-Projekt bei SRI geleitet hatte.

Ihr Wissen macht ihn als archivische Karte und institutionelle Geschichte wertvoll, aber es verwandelt seine Zusammenfassungen nicht in geprüfte Feststellungen oder Entscheidungen von Vertragsbeamten.

Die stärksten Belege für tatsächlich erbrachte Dienste stammen aus zeitgenössischen Betriebsdokumenten. RFC 811, im März 1982 veröffentlicht, beschrieb den Hostnames Server als einen einer Reihe von Namensdiensten, die vom NIC von SRI im Auftrag der DCA unterhalten wurden. RFC 954, im Oktober 1985 veröffentlicht, identifizierte den NICNAME/WHOIS-Server auf dieselbe Weise. Der NTIS-Handbucheintrag verbindet eine wichtige DDN-Publikation mit einer gemeldeten Vertragsnummer.

RFC 1032, von SRI im November 1987 veröffentlicht, erklärte, die DCA habe das NIC benannt, um Domänenregistrierungsdienste für die DDN- und DARPA-Teile des Internets bereitzustellen. Im Februar 1991 identifizierte RFC 1206 immer noch SRI International als Betreiber von NIC.DDN.MIL, dem Repositorium für RFCs und Internet Drafts, als Anbieter von DDN-Benutzerunterstützung, als Standort der Internet Registry und als Betreiber von Domänen- und WHOIS-Diensten.

Zusammen zeigen diese Dokumente, dass SRI die beschriebene Arbeit erbrachte. Sie identifizieren funktionierende Server, Mailboxen, Telefonsupport, Publikationen, Datenbanken und Registrierungsverfahren. Sie zeigen nicht, welche Dienstleistung welcher Vertragsposition zugeordnet war. Ein RFC, der eine Betriebsregel beschreibt, kann nicht zu einer Leistungsbeschreibung hochgestuft werden, genauso wie die Existenz eines öffentlichen Servers nicht den vertraglichen Anspruch eines Dritten auf fortgesetzten Dienst belegen kann.

Die Namen der Behörde ändern sich gegen Ende des Zeitraums. Die DCA behielt diesen Namen bis zum 25. Juni 1991, als die Department of Defense Directive 5105.19 sie in Defense Information Systems Agency umbenannte. Zeitgenössische und spätere Darstellungen verwenden die beiden Namen manchmal locker, wenn sie den Übergang diskutierten, aber das Datum ist wichtig. DCA ist der korrekte Behördenname für die SRI-Verträge, die 1983, 1984 und 1987 gemeldet wurden. DISA ist der korrekte Name für die Behörde, die in der Betriebsübergabemitteilung vom September 1991 genannt wird.

Zwischen diesen Punkten besteht eine wesentliche Lücke. Die Qualifikationstabelle von SRI von 1988 gibt den 31. Januar 1989 als Ende des aufgeführten Zeitraums für DCA200-87-C-0020 an. RFC 1206 zeigt, dass SRI das DDN NIC im Februar 1991 noch betrieb, und der Archivleitfaden beschreibt monatliche Berichte bis in dieses Jahr. Kein geprüftes öffentliches Instrument identifiziert die Option, Verlängerung, Übergangsvertrag, Änderung oder Nachfolgevereinbarung, die die Arbeit von Februar 1989 bis zur Übergabe 1991 unterstützte.

Die Lücke beweist nicht, dass SRI ohne Vertrag arbeitete. Sie bedeutet, dass das Beschaffungsinstrument aus den zur Prüfung verfügbaren Dokumenten nicht ermittelt wurde. Eine spätere Betriebsbeschreibung kann eine fehlende Auftragsnummer nicht liefern, und fortgesetzte Dienstleistung offenbart nicht, ob die Kontinuität auf einer ausgeübten Option, einer Änderung einer bestehenden Vereinbarung oder einer anderen Beschaffung beruhte.

Was die DCA-Regeln zwingend machten

Innerhalb der DDN-Umgebung waren die Handlungen des DDN-NIC durch Regeln, die spezifischer waren als der eigene Status des Auftragnehmers, mit der staatlichen Betriebsberechtigung verbunden.

RFC 810, im März 1982 veröffentlicht, spezifizierte die DoD-Internet-Host-Tabelle und schrieb ihre Pflege dem NIC im Auftrag der DCA zu. Die Behandlung von DoD- und Nicht-DoD-Einträgen war nicht symmetrisch. Namen und Adressen für DoD-Netzwerke, Gateways und Hosts sollten vor der Nutzung und bevor ein DoD-Host Datenverkehr zu ihnen weiterleitete, mit dem NIC ausgehandelt und registriert werden. Für eine Übergangszeit würde das NIC versuchen, ähnliche Informationen für Nicht-DoD-Netzwerke und -Hosts zu pflegen, wenn sie geliefert wurden und notwendig blieben, während interoperierende Nameserver entwickelt wurden.

Dies war eine Betriebsspezifikation, kein Vertrag. Dennoch identifiziert sie eine konkrete Autoritätsquelle. Ein DoD-Host unterlag Regeln, die ein von einer DoD-Behörde verwaltetes Netz regierten. Das NIC empfing und pflegte den erforderlichen Eintrag, aber die betriebliche Konsequenz ergab sich aus der Position der DCA über das DoD-Netz und seine teilnehmenden Einrichtungen. SRI benötigte keine unabhängige Regulierungsmacht über einen militärischen Host, wenn die DCA die Registrierung zu den Bedingungen machen konnte, unter denen dieser Host das Netz nutzte.

DasDDN Protocol Handbookvon 1985 passt in dasselbe Muster. Sein erklärter Zweck war es, Implementierer anzuleiten, die Maschinen an das DDN anschlossen. Das Handbuch erklärte DoD-Protokollanforderungen, Konfigurationsmanagement und die Rollen der DCA und des DDN Program Management Office. Seine Verbindlichkeit gegenüber einer erfassten Einrichtung ergab sich aus der Stellung der Einrichtung innerhalb des DDN-Programms, nicht aus der öffentlichen Verfügbarkeit des Handbuchs oder der Autorenschaft von SRI.

RFC 954 liefert ein weiteres abgegrenztes Beispiel. WHOIS war über das Internet zugänglich, und die DCA ermutigte Netzwerk-Hosts, den Dienst den Nutzern zur Verfügung zu stellen. Die Sprache der Registrierung konzentrierte sich jedoch auf Personen mit Konten auf ARPANET- oder MILNET-Hosts, die Datenverkehr über das DoD-Internet senden konnten. Nutzer von MILNET Terminal Access Controllern mussten registriert sein. Das Dokument nannte die Mailbox und Telefonnummer des Registrars, erklärte aber nicht, dass jede Person, die irgendwo TCP/IP nutzte, in das von der DCA unterstützte Verzeichnis aufgenommen werden musste.

Der Dienst konnte sowohl öffentlich nützlich als auch offiziell für eine bestimmte Population verpflichtend sein. Öffentliche Zugänglichkeit machte nicht alle Nutzer zu vertraglichen Begünstigten. Die obligatorische Registrierung für einen MILNET-TAC-Nutzer bewies keine vergleichbare Verpflichtung für einen Mitarbeiter eines ausländischen Universitätsnetzes.

Die Aufsicht der DCA zeigt sich auch in den Anwendungsanweisungen von RFC 1032. Wenn die Annahme eines vollqualifizierten Domänennamens den offiziellen Hostnamen eines ARPANET- oder MILNET-Hosts ändern würde, musste der Antragsteller zuvor die Genehmigung der DCA einholen und Bearbeitungszeit einplanen. Die administrative Brücke ist sichtbar: Der betroffene Host gehörte zu einer von der DCA verwalteten Umgebung; sein vorgeschlagener Name änderte einen offiziellen, in dieser Umgebung verwendeten Eintrag; das NIC bearbeitete die Anfrage; und die Genehmigung der DCA war erforderlich.

Kein geprüftes öffentliches Instrument belegt, dass dieselbe Genehmigungspflicht jeden lokalen Hostnamen in jedem externen Netz regelte. RFC 1032 wies stattdessen einen großen Teil der lokalen Namensverantwortung Domänenadministratoren zu und lehnte eine zentrale Rolle bei der Beilegung privater organisatorischer Streitigkeiten ab. Das DDN-NIC übte an einer Registrierungsgrenze echte Autorität aus, ohne alles Verhalten hinter dieser Grenze zu verwalten.

Diese Anordnung war nicht inhärent fehlerhaft. Eine Regierungsbehörde kann Betriebsanforderungen für ihr Netz definieren, einen Dienstanbieter benennen, von erfassten Nutzern verlangen, genaue Informationen zu liefern, und sich die Genehmigung von Änderungen an offiziellen Einträgen vorbehalten. Die Kompetenz von SRI brachte dieses Design auf wachsende Größenordnung zum Funktionieren. Die unbeantwortete Frage beginnt dort, wo ein Nutzer weder eine DDN-Einrichtung noch anderweitig innerhalb der relevanten staatlichen Sponsoringkette lag.

Die von der Internet-Richtlinie gelieferte Autorität

Die Beschaffung war nicht die einzige Brücke zwischen dem DDN-NIC und dem breiteren Internet. Die positive Autorität, die durch technische Richtlinien verliehen wurde, muss für sich genommen gewogen werden.

RFC 920, im Oktober 1984 von Jon Postel und Joyce Reynolds bei USC/ISI veröffentlicht, erklärte sich selbst zur offiziellen Richtlinie des Internet Activities Board und der DARPA. Es definierte Anforderungen für die Einrichtung von Domänen im ARPA-Internet und der DARPA-Forschungsgemeinschaft. Domänen benötigten verantwortliche Administratoren, zuverlässigen Namensdienst und Registrierung innerhalb der Hierarchie. Das NIC wurde als Agent für die anfänglichen Top-Level-Domänen aufgeführt. Die DARPA wurde als Administrator für ARPA, GOV, EDU, COM und ORG identifiziert; das DDN Program Management Office war Administrator für MIL.

Dies war eine bedeutsame Benennung. Eine Organisation, die eine Second-Level-Domäne unter einer vom NIC verwalteten Top-Level-Domäne beantragte, musste die Registrierungsstruktur durchlaufen. Der Administrator der höheren Ebene musste überzeugt sein, dass die geltenden Anforderungen erfüllt waren, bevor die neue Domäne genehmigt wurde. Von Antragstellern wurde erwartet, verantwortliche Kontakte zu benennen, ihre Nameserver zu beschreiben und andere betriebliche Informationen zu liefern.

Ohne eine akzeptierte Delegation in der gemeinsamen Hierarchie würde der vorgeschlagene Name nicht über die Stammdaten dieser Hierarchie veröffentlicht werden.

RFC 920 teilte Autorität auch, anstatt sie unterschiedslos zu konzentrieren. Der Eigentümer eines Hosts wählte, in welche Domäne er aufgenommen werden wollte, während ein Domänenadministrator wählte, welche Hosts aufzunehmen seien. Ihre Einigung bildete die administrative Grundlage für die Position des Hosts im Namensraum. Administratoren kontrollierten Namen innerhalb ihrer eigenen Domänen und konnten Verantwortung weiter unten im Baum delegieren. Die zentrale Rolle des NIC koexistierte mit erheblicher lokaler Kontrolle.

Das Dokument sah ausdrücklich institutionelle Ersetzung vor. Es bemerkte, dass andere Stellen für einige Domänen geeignetere Agenten oder Registrare sein könnten und dass die Verantwortung dann neu zugewiesen werden sollte. Es sagte auch, dass eine dauerhafte NIC-Verwaltung jeder Top-Level-Domäne nicht erwünscht sei. Das IAB und die DARPA etablierten eine praktikable Anfangsregelung, nicht eine Erklärung, dass SRI unentfernbar sei.

Bis November 1987 beschrieb RFC 1032 die Implementierung in weiter entwickelter Form. Darin hieß es, das NIC sei von der DCA benannt worden, um Registrierungsdienste für das Domänensystem in den DDN- und DARPA-Teilen des Internets bereitzustellen. Es identifizierte das NIC als Registrar für Top- und Second-Level-Domänen, als Administrator von Root-Server-Zonendateien im Auftrag von DARPA und DDN und als vorläufigen Administrator mehrerer benannter Top-Level-Domänen, bis geeignete Organisationen diese übernehmen könnten.

Ein potenzieller Domänenadministrator erhielt einen Fragebogen, lieferte die erforderlichen organisatorischen und technischen Details und sandte das ausgefüllte Formular an HOSTMASTER bei SRI zurück. Der Leitfaden sagte, dass der Antrag vollständig sein müsse, bevor das NIC die Einrichtung der Domäne genehmige. Er beschrieb auch alternative Registrierungsvereinbarungen, unter denen CSNET- und UUCP-Verwaltungsorganisationen Anträge für ihre Gemeinschaften bearbeiteten und relevante Informationen an das NIC zur Aufnahme in die zentrale Datenbank und Root-Dateien weiterleiteten.

Dieses Verfahren stattete das DDN-NIC mit dienstspezifischer Betriebsautorität aus. Das NIC konnte einen vollständigen Antrag verlangen, bevor es eine Delegation zu den von ihm verwalteten Stammdaten hinzufügte. Es konnte Namensformatierungs- und Klassifizierungsregeln innerhalb der in seine Obhut gegebenen Top-Level-Domänen anwenden. Ein Antragsteller, der Zugang zu diesen Domänen suchte, musste das geltende Registrierungsverfahren befolgen.

Diese Autorität leitete sich nicht allein aus der Beschaffungsbeziehung der DCA mit SRI ab. Sie beruhte auf einer Kombination aus Richtlinien des IAB und der DARPA, der Benennung des NIC durch die DCA für dokumentierte Teile des Internets, der Zuweisung von Verantwortung durch die Hierarchie und dem Aufnahmeantrag des Antragstellers. Sie war auch nicht unbegrenzt. RFC 1032 behandelte viele Namensentscheidungen als lokale Angelegenheiten. Es sagte, dass das NIC nicht entscheiden würde, welche Streitpartei das zugrunde liegende Recht habe, einen Namen für eine Organisation zu registrieren.

Konflikte sollten vor der Registrierung gelöst werden, während das NIC sich auf technische Anleitung und Bearbeitung beschränkte.

Die Grenzen machten die Registrierungsentscheidung nicht folgenlos. Eine Domäne, die in der gemeinsamen Stammzone fehlte, konnte keine normale Auflösung durch Systeme erwarten, die dieser Stammzone folgten. Eine verzögerte oder ungenaue Delegation konnte erhebliche Kosten verursachen. Diese Folgen ergaben sich jedoch aus einem kontrollierten Registrierungsdienst innerhalb einer weit verbreiteten Hierarchie. Kein geprüftes öffentliches Instrument belegt, dass das Registrierungsverfahren SRI auch allgemeine Autorität über das interne Netzwerk, Personaleinstellungen, Vertragsbeziehungen oder Verkehrsrichtlinien eines Antragstellers verlieh.

Nummern, IANA und die Internet Registry

Die Verwaltung von Internetnummern folgte einem anderen institutionellen Pfad. Die Unterscheidung zwischen der IANA-Funktion von USC/ISI und der Registry-Funktion von SRI ist wesentlich, weil die gleiche Personalmailbox sonst den Anschein erwecken könnte, alle Autorität aus der DCA-Beschaffung abzuleiten.

RFC 1020, von SRI-Mitarbeitern im November 1987 veröffentlicht, gab bekannt, dass Hostmaster beim DDN-NIC die Verantwortung für die Zuweisung von IP-Netzwerknummern und autonomen Systemnummern übernommen habe. Es erkannte die fortgesetzte Unterstützung von Jon Postel und Joyce Reynolds bei USC/ISI an. Das Dokument war ein offizieller Statusbericht, der zugewiesene Kennungen auflistete; es gab nicht die Vereinbarung wieder, die die operative Arbeit übertrug.

RFC 1174 lieferte im August 1990 die zeitgenössische Richtliniendarstellung. Es beschrieb die IANA-Funktion als bei USC/ISI angesiedelt und erklärte, dass IANA die Ermessensbefugnis besitze, Teile der Kennungsverantwortung zu delegieren. Für Netzwerk- und autonome Systemnummern hieß es, dass die Verantwortung bei der Internet Registry liege, die von SRI beim DDN-NIC betrieben wurde. SRI war daher mehr als ein passiver Empfänger von Formularen. Innerhalb der akzeptierten technischen Vereinbarung war es das hauptsächliche Register für diese Kennungen.

Diese Delegation war eine positive Autoritätsbrücke. Sie erklärt, warum eine Organisation außerhalb der DDN-Beschaffungspopulation dennoch eine Nummernanfrage an das DDN-NIC richten und das Ergebnis als maßgeblich behandeln konnte. Der Antragsteller wollte eine global eindeutige Kennung, die vom gemeinsamen Internet-Koordinationssystem anerkannt wurde. Die IANA-Funktion von USC/ISI hatte SRI die entsprechende Registrierungsverantwortung übertragen. Andere Betreiber konsultierten das Register und nutzten die Zuweisungen, um Kollisionen zu vermeiden.

Die Brücke hatte dennoch definierte Ränder. RFC 1174 hielt IANA und die Internet Registry institutionell getrennt. USC/ISI führte die zentrale IANA-Funktion aus; SRI führte die ihm delegierte Registerarbeit aus. Das IAB empfahl, dass das Register Blöcke an zugelassene regionale Organisationen zuweist und dass die weitere Zuweisungsbefugnis international verteilt werde. Das DDN-NIC sollte ein Standardregister bleiben, wo kein delegiertes Register existierte, während aggregierte Kopien von Registrierungsdaten geteilt werden sollten, um Zugriff und Redundanz zu verbessern.

RFC 1174 begründet nicht die vollständige vertragliche Grundlage für IANAs Beziehung zu DARPA, DCA oder SRI. Seine Aussage, dass IANA diskretionäre Delegationsbefugnis besitze, dokumentiert die vom IAB anerkannte Richtlinienregelung. Es ist kein Ersatz für die fehlenden DARPA- und DCA-Vereinbarungen.

Das US Government Accountability Office stieß 2016 auf ein vergleichbares Beweisproblem, als es staatliche Eigentumsinteressen an historischen Internetfunktionen untersuchte: Schlüsselverträge aus den 1970er bis 1990er Jahren konnten nicht beschafft werden, was sichere Schlussfolgerungen über die Rechte verhinderte, die diese Vereinbarungen vermittelten.

Die institutionelle Darstellung ist daher geschichtet. DoD-Behörden finanzierten wichtige Einrichtungen und Funktionen. Die DCA beschaffte NIC-Dienste für das DDN. DARPA und das IAB lieferten Richtlinien für das Forschungsinternet und das entstehende Domänensystem. USC/ISI führte IANA aus und delegierte Nummernregistrierungsarbeit. SRI betrieb die Internet Registry und das DDN-NIC. Antragsteller befolgten das Registrierungsverfahren, weil sie anerkannte Kennungen suchten. Netzwerk- und DNS-Betreiber nutzten dann die resultierenden Daten.

Jede Schicht war wichtig. Keine liefert die vollständige Autorität aller anderen.

Rice University: eine Momentaufnahme, keine Transaktionsdatei

Die Rice University veranschaulicht sowohl die Reichweite des Registers als auch die Grenzen der überlebenden Fallbeweise.

RFC 1020 listet RICE-NET unter 128.42 und kategorisiert es als Forschungsnetzwerk. RFC 1032 verwendet eine WHOIS-Antwort fürrice.eduals Beispiel dafür, wie ein Domänenadministrator Registrierungsdaten überprüfen konnte. Der angezeigte Datensatz identifiziert die Rice University, ihre Kontakte und ihre Domänenserver. Diese Aufzeichnungen belegen, dass mit Rice verbundene Nummern- und Domäneninformationen im November 1987 in DDN-NIC-Publikationen und -Diensten erschienen.

Sie offenbaren nicht den ursprünglichen Antrag von Rice, die Identität des Beamten, der ihn einreichte, dessen Finanzierungsbeziehung, den Verbindungsweg, den Austausch mit Hostmaster oder die für die Bearbeitung benötigte Zeit. Sie zeigen keine strittige Anfrage, Ablehnung, Aufhebung, formelle Genehmigungsmitteilung oder Beschwerde. RFC 1020 kennzeichnet RICE-NET nicht als eines der unabhängigen Netzwerke, die durch ein Sternchen identifiziert werden, so dass es auch nicht sicher wäre, Rice auf dieser Grundlage als nicht angeschlossenes externes Netz zu beschreiben.

Die Registrierungsanweisungen von RFC 1032 sind allgemein gehalten. Dass sie neben einem Rice-WHOIS-Beispiel stehen, beweist nicht, dass Rice jeden beschriebenen Schritt in der gezeigten Form befolgt hat oder dass eine bestimmte Korrespondenz den angezeigten Eintrag hervorbrachte. Die Nummernauflistung und die WHOIS-Ausgabe sind Register-Momentaufnahmen. Das Verfahren ist ein veröffentlichtes Verfahren. Sie können ohne die fehlende Korrespondenz nicht zu einer Transaktionserzählung zusammengesetzt werden.

Die betriebliche Konsequenz der Aufzeichnungen kann nur auf Systemebene beschrieben werden. Eine zugewiesene Nummer gab dem gemeinsamen Register eine eindeutige Kennung zur Veröffentlichung für RICE-NET. Eine gültige Domänendelegation ermöglichte es Systemen, die die gemeinsame DNS-Hierarchie nutzten, zu erfahren, welche Server fürrice.eduautoritativ waren. Die Dokumente belegen nicht, dass ein bestimmtes Paket geroutet wurde, dass Rice physische Konnektivität vom DDN-NIC erhielt oder dass ein anderes Netzwerk gezwungen war, Rice-Verkehr zu tragen.

Kein geprüftes öffentliches Instrument belegt einen vollständigen Außenseiterstreit von 1983 bis 1991, in dem ein identifizierbarer nicht-vertragschließender Antragsteller einen Domänen- oder Nummernantrag an das DDN-NIC stellte, eine umstrittene Entscheidung erhielt, Überprüfung suchte und ein dokumentiertes Ergebnis erzielte. Dies ist eine Grenze der verfügbaren Analyse, kein Beweis dafür, dass Streitigkeiten nie vorkamen.

Ohne eine solche Akte ist es nicht möglich zu prüfen, wie SRI eine ablehnende Entscheidung erklärte, ob DCA oder USC/ISI sie überprüften, welche Rechtsbehelfe existierten oder ob der Antragsteller einen durchsetzbaren Anspruch hatte.

Was festgestellt werden kann, ist der vom NIC veröffentlichte generische Bearbeitungsweg. Ein Domänenantragsteller lieferte Kontakte, Serverinformationen, Netzwerkadressen und andere betriebliche Details. NIC-Mitarbeiter prüften die Einreichung auf Vollständigkeit und Übereinstimmung mit der geltenden Hierarchie. Die Annahme erlaubte, die Delegation in Register- und Root-Server-Daten aufzunehmen. Ein Nummernantragsteller suchte eine Kennung von der Internet Registry. Die Zuweisung erzeugte einen anerkannten Eintrag, lieferte aber selbst keine Verbindung.

RFC 1020 machte die letztere Trennung explizit. Es verzeichnete Nummernzuweisungen für Netzwerke, die mit dem Forschungs- oder Betriebsinternet verbunden waren, und für unabhängige IP-Netzwerke. Administratoren unabhängiger Netzwerke mussten dennoch separate Erlaubnis zur Verbindung einholen. Kennungszuweisung, Registerveröffentlichung und Netzzugang waren verschiedene Entscheidungen.

Das Rice-Material beweist daher weder Zwang noch Bedeutungslosigkeit. Es zeigt eine Bildungseinrichtung, die mit für die Interoperabilität bedeutsamen Kennungen in einem zentralen Register vertreten ist. Es zeigt nicht die rechtliche Beziehung, durch die Rice eintrat, oder einen Anlass, bei dem das DDN-NIC umstrittene Macht über sie ausübte.

Aufsicht ohne offengelegte Rechtsbehelfsbestimmung

Die Archivaufzeichnungen deuten darauf hin, dass Aufzeichnungen über die Verwaltung auf Käuferseite existierten, aber das hier geprüfte öffentliche Material gibt die vollständige Rechtsbehelfsstruktur nicht preis.

Das Findbuch des Computer History Museum beschreibt Verträge, geordnet nach Nummer und dann nach Dokumenttyp, einschließlich Leistungsbeschreibungen, Vorschlägen, Änderungen, E-Mails und Korrespondenz. Es identifiziert formelle monatliche Fortschrittsberichte und vertragliche Lieferberichte. Es sagt, dass die Arbeit von 1987 in Aufgaben mit getrennten Leitern und Budgets unterteilt war. Dies sind Beschreibungen von Archivkategorien, keine Feststellungen über den Inhalt oder die rechtliche Wirkung jedes Dokuments.

Sie identifizieren nicht die Folgen verfehlter Dienstniveaus. Kein geprüftes öffentliches Instrument belegt eine Nachfrist, ein Zurückbehaltungsrecht, eine Gebührenanpassung, einen Kündigungsstandard, eine Übergangsunterstützungsklausel oder einen Schadensersatz unter den relevanten SRI-Vereinbarungen. Die Feststellung von SRI von 1988, dass alle Liefergegenstände ohne Überschreitungen erreicht worden seien, kann diese Lücke nicht füllen. Es handelt sich um die Leistungsdarstellung des Auftragnehmers, nicht um eine von der DCA unterzeichnete Abnahmebestimmung.

Das Findbuch fasst auch Episoden zusammen, die die Dokumentenproduktion, eine mit der VOID-Datenbank verbundene Ausgabe und das SAM-Personal-Computer-Mailprojekt betreffen. Diese Zusammenfassungen deuten darauf hin, dass das Archiv Material über Finanzierungsfragen, Regierungsbedenken und Entscheidungen enthält, die die Arbeit von SRI betrafen. Die zugrunde liegende Korrespondenz, Vertragsänderungen, Budgetentscheidungen und Handlungen der Vertragsbeamten wurden nicht geprüft.

Die Episoden können daher nicht als geprüfte Prüfungen, formelle Durchsetzungsmaßnahmen oder Registrierungsantragstellern zur Verfügung stehende Rechtsbehelfe dargestellt werden.

Dieselbe Grenze gilt für den Hinweis des Findbuchs auf eine mit SAM verbundene anonyme Beschwerde. Die Zusammenfassung eines Archivars kann eine Forschungsspur identifizieren. Sie legt nicht die genauen Vorwürfe der Beschwerde fest, die betroffene Vertragsaufgabe, die Autorität der Person, die sie entgegennahm, die Reaktion der DCA oder die Bedingungen, unter denen die Arbeit eingestellt oder wiederaufgenommen wurde. Es handelte sich ohnehin nicht um eine dokumentierte Beschwerde eines Domänen- oder Nummernantragstellers.

Selbst wenn die Kontrollen auf Käuferseite vollständig dokumentiert wären, würden sie nur einen Teil der Rechenschaftsfrage beantworten. Ein Regierungskunde kann vertragliche Rechtsbehelfe gegen seinen Lieferanten besitzen. Ein externes Netz, das einen öffentlich zugänglichen Dienst nutzt, erwirbt nicht automatisch dieselben Rechte. Seine Stellung würde von einer Vereinbarung, einem anerkannten Begünstigtenstatus, einer administrativen Verpflichtung oder einer anderen Anspruchsquelle abhängen.

RFC 1032 bot Mailboxen, eine Telefonhotline und Korrespondenz mit Hostmaster. Sie bot technische Anleitung und erwartete Austausche, die zur Vervollständigung eines Antrags notwendig waren. Sie beschrieb kein unabhängiges Schiedsgericht für abgelehnte Anfragen. Ihre Richtlinie, lokale Namensstreitigkeiten den Parteien zu überlassen, war eine Grenze der NIC-Entscheidungsfindung, kein Beschwerdesystem. Kein geprüftes öffentliches Instrument belegt Schadensersatz, Servicegutschriften oder ein formelles Prüfungsrecht für ein überseeisches oder kommerzielles Netz, das von einer SRI-Registrierungsentscheidung betroffen war.

Die Unsicherheit schneidet in beide Richtungen. Das Fehlen einer offengelegten Beschwerdeklausel beweist nicht, dass kein Beschwerdeverfahren existierte. Es verhindert auch die Behauptung, dass externe Nutzer vertragliche Kontinuität oder Verfahrensschutz genossen. Die öffentliche Abhängigkeit wuchs möglicherweise schneller als die in der erhaltenen Aufzeichnung sichtbaren formellen Rechte.

Die technische Richtlinie enthielt Mechanismen zur Verteilung von Verantwortung. RFC 920 erlaubte, Registrarrollen an geeignetere Einrichtungen neu zuzuweisen. RFC 1032 verteilte Administration die DNS-Hierarchie hinunter und lehnte eine Zentralisierung lokaler Streitigkeiten ab. RFC 1174 schlug weitere Delegation der Nummernregistrierung und breitere Replikation von Registerdaten vor. Dies waren keine vertraglichen Rechtsbehelfe oder gerichtliche Überprüfung, aber sie zeigen, dass die Architektur es nicht erforderte, dass ein Auftragnehmer auf unbestimmte Zeit das alleinige Betriebszentrum blieb.

Die Neubewertung der Reichweite von 1990

Bis 1990 entsprach die Internet-Population nicht mehr den Regierungs- und Forschungsgemeinschaften, für die frühere Verfahren entworfen worden waren. RFC 1174 beschrieb das Wachstum in Industrie, Wissenschaft und nicht-US-amerikanische Netzwerke und schlug Änderungen sowohl bei der Kennungszuweisung als auch beim Status „verbunden“ vor.

Das Dokument empfahl nicht, die zentrale Koordination abzuschaffen. Es schlug vor, IANA und die Internet Registry beizubehalten, während Kennungsblöcke an andere qualifizierte Register verteilt würden. Das DDN-NIC würde als Haupt- und Standardregister fortbestehen, aggregierte Daten würden für Aktualisierungszwecke zentralisiert bleiben, und Kopien würden geteilt. Dies war eine Reform der zentralen Verwaltung, keine Leugnung, dass das DDN-NIC operative Autorität besaß.

Seine Behandlung des Verbindungsstatus ist ebenso wichtig. Die frühere Praxis verband die Internet-Verbindung mit der Genehmigung durch eine US-Regierungs-Sponsoring-Organisation. RFC 1174 empfahl, diesen Status aus den Registerformularen und Datenbanken zu entfernen, registrierte Netzwerke unabhängig von einer einzigen Verbindungsklassifizierung ins DNS aufzunehmen und stattdessen die Zugangs-, Transit- und Nutzungsrichtlinien jedes Netzwerks zu erfassen.

Der Vorschlag erkannte eine Grenze an, die allein durch Beschaffung nicht gemanagt werden konnte. Eine Netzwerknummer konnte global eindeutig sein, ohne ihren Inhaber zur Nutzung eines bestimmten Backbones zu berechtigen. Eine Domäne konnte im DNS erscheinen, ohne dass jeder Betreiber verpflichtet war, Datenverkehr dorthin zu leiten. Ein staatlich gefördertes Netzwerk konnte seine Zugangskriterien für den Verkehr über seine Einrichtungen durchsetzen. Andere Netzwerke konnten ihre eigenen Verbindungs- und Transitentscheidungen treffen.

RFC 1174 sagte auch, es sei unangemessen, von jedem nicht-US-Netz zu verlangen, den US-Zugangs- und Nutzungskriterien zu folgen. Bundesrechtliche Kriterien könnten den Verkehr regeln, der staatlich geförderte Netzwerke nutzt. Dies antwortete direkt auf internationales Wachstum: Kontrolle über eine bereitgestellte Einrichtung wurde nicht automatisch zur Kontrolle über alle registrierten Netzwerke.

Das Register übte dennoch folgenreiche Macht aus. Es entschied, ob eine Kennungsanfrage seinen Verfahren entsprach, zeichnete Zuweisungen auf, pflegte die Datenbank und lieferte Informationen, die von anderen Betreibern genutzt wurden. Die DNS-Aufnahme war wichtig genug für das IAB, um zu empfehlen, sie vom staatlich geförderten Verbindungsstatus zu trennen. Diese Empfehlung wäre unnötig gewesen, wenn Registerentscheidungen keine Wirkung gehabt hätten.

Externe Abhängigkeit war nicht in einem friktionslosen Sinne freiwillig. Eine Organisation, die breit interoperabel sein wollte, stand unter starkem Druck, eindeutige Nummern und anerkannte DNS-Delegationen zu erhalten. Die Wahl einer widersprüchlichen Adresse oder einer nicht anerkannten Stammzone konnte sie von Systemen isolieren, die sie erreichen wollte. Das gemeinsame Register hatte Netzwerkeffekte, akkumulierte Expertise und die Unterstützung einflussreicher staatlicher und technischer Institutionen.

Diese Effekte entstammten nicht alle aus der DCA-Vertragsbeziehung von SRI. Die Brücke für die Nummernregistrierung war die IANA-Delegation und die Teilnahme des Antragstellers am gemeinsamen Kennungssystem. Die Brücke für die Domänenregistrierung war die Richtlinienstruktur von IAB und DARPA, die dokumentierte Benennung der DCA, die DNS-Hierarchie und der Aufnahmeantrag des Antragstellers. Die Brücke für DDN-Betriebsregeln war die Nutzung des DDN und die relevante staatliche Beziehung. Die Brücke für die Verkehrsleitung war die Richtlinie des genutzten Netzwerks.

Kein geprüftes öffentliches Instrument belegt, dass der Beschaffungsvertrag von SRI diese Beziehungen zu einer allgemeinen Autorität über jeden abhängigen Betreiber verschmolz.

Die fehlenden Jahre und die Übergabe von 1991

Die letzte Phase der Chronologie enthält sowohl den klarsten Nachweis von Kontinuität als auch die größte Beschaffungsunsicherheit.

Der gemeldete Zeitraum von DCA200-87-C-0020 bei SRI endete am 31. Januar 1989. Zeitgenössische RFCs zeigen, dass SRI 1990 und Anfang 1991 das DDN-NIC weiter betrieb. Der Archivleitfaden beschreibt Fortschrittsberichte bis 1991. Kein geprüftes öffentliches Instrument identifiziert den Vertrag, die Option, die Änderung oder die Übergangsvergabe, die die Fortsetzung unterstützte. Die Beschaffungsgrundlage für den Zeitraum von Februar 1989 bis zur Übergabe 1991 bleibt daher ungeklärt.

Am 25. Juni 1991 wurde die DCA zur DISA. Im September kündigte RFC 1261 an, dass das Network Information Center am 1. Oktober von SRI International in Menlo Park zu Government Systems Inc. in Chantilly umziehen würde. Es identifizierte Dienste, die damals sowohl DDN- als auch Internetnutzern angeboten wurden: Netzwerk- und Benutzerregistrierung, Zuweisung von Netzwerknummern und Top-Level-Domänen, Online-Informationsdienste, Helpdesk-Betrieb sowie RFC- und Internet-Draft-Archive und -Verteilung.

Die Mitteilung wurde von Scott Williamson und Leslie Nobile von Network Solutions verfasst. Sie erklärte, dass SRI bis zum 30. September weiterhin Anrufe und Anfragen beantworten würde. Die WHOIS-Datenbank würde vom 26. bis 30. September nicht geändert, während Registrierungsaktionen ausgesetzt und die Master-Datenbank an GSI übertragen würde. Post- und Faxanfragen sollten an die neue GSI-Adresse gerichtet werden; elektronische Nachrichten, die an die vertrauten Hostmaster- und Registrar-Mailboxen gesandt wurden, würden fortbestehen und entsprechend umgeleitet. Die Registrierungsaktivität würde am 1. Oktober wiederaufgenommen.

Das neue NIC verwendete einen Sun 470 SPARCserver mit SunOS 4.1 und löste die vorherige TOPS-20-Umgebung ab.

Diese Details belegen eine Übergabe des Betriebsanbieters. Daten wanderten. Adressen, Telefonnummern und Computerinfrastruktur änderten sich. Anfragen wurden ausgesetzt, umgeleitet und wiederaufgenommen. Die Mitteilung belegt auch, dass DISA und GSI öffentlich mit dem Übergang verbunden waren und dass Mitarbeiter von Network Solutions an der Implementierung oder Kommunikation des Nachfolgedienstes beteiligt waren.

Ein Bundesbezirksgerichtsurteil von 1998,Thomas v. Network Solutions, lieferte eine spätere rechtliche Darstellung. Das Gericht berichtete, dass Network Solutions einen Unterauftrag unter einem von DISA an GSI vergebenen Beschaffungsvertrag erhalten hatte und dass seine Pflichten Domänenregistrierung und IP-Nummernzuweisung umfassten. Ein separates Bundesurteil von 2000 zitierte eine eidesstattliche Aussage des NSF-Beamten George Strawn, der Network Solutions als Unterauftragnehmer von GSI beschrieb, der das DDN und das Internet unter einem DISA-Vertrag unterstützte.

Diese späteren Darstellungen stützen eine übergeordnete Beschreibung als Haupt- und Unterauftragnehmer: DISA als Regierungsbehörde, GSI als Inhaber der Beschaffungsbeziehung und Network Solutions als Unterauftragnehmer, der Registerarbeit ausführte. Sie geben weder die Auftragsnummer, die Ausschreibung, den Auswahlvermerk, den unterzeichneten Hauptvertrag noch den Unterauftrag preis. Sie enthalten auch rückblickende Zusammenfassungen, die nicht die zeitgenössische Darstellung des operativen Übergangs vom 1. Oktober in RFC 1261 verdrängen sollten.

Kein geprüftes öffentliches Instrument belegt, ob die Auswahl von GSI aus einem erneuten Wettbewerb, einer gewöhnlichen Nachfolgevergabe oder einem anderen Beschaffungsmechanismus resultierte. Kein geprüftes öffentliches Instrument liefert eine Kündigungsklausel für SRI, eine Übergangsunterstützungspflicht, staatliches Eigentum an den Registerdaten, Softwarelizenzbedingungen, Dienstniveaus, Migrationskosten oder Rechte externer Nutzer. Die Bewegung der Master-Datenbank zeigt, dass die Übertragung stattfand. Sie beweist nicht die Vertragsregel, die die Übertragung verlangte oder erlaubte.

Die Übergabe sollte nicht mit mehr rechtlicher Bedeutung befrachtet werden, als ihre Beweise erlauben. Sie zeigt, dass der Betriebsanbieter wechselte, während Dienste, Mailboxen, Stammaufzeichnungen und öffentliche Erwartungen fortgeführt wurden. Sie zeigt nicht, warum SRI rechtlich zur Kooperation verpflichtet war, wer welche Softwarekomponente besaß, welche Partei die Übergangskosten trug oder welchen Rechtsbehelf ein externer Registrant gehabt hätte, wenn die Übertragung gescheitert wäre.

Die Service-Population erfordert ebenfalls Sorgfalt. RFC 1261 richtete sich sowohl an DDN- als auch an Internetnutzer und belegte damit, dass der operative Übergang für eine Gemeinschaft konzipiert war, die über militärische Einrichtungen hinausging. Diese Aussage belegt nicht, dass alle diese Nutzer vertragliche Begünstigte waren. Eine Regierung kann einen Dienst beschaffen, der öffentlich zugänglich gemacht wird, ohne jedem Nutzer das Recht zu verleihen, die Beschaffung durchzusetzen.

Die beobachtbare Leistung war erheblich. Die Registrierungsaktivität wurde für einen definierten Zeitraum pausiert, anstatt aufgegeben zu werden. Die Master-Datenbank wurde übertragen, Kommunikationskanäle wurden umgeleitet und Dienste sollten unter einem neuen Betreiber wieder aufgenommen werden. Der Übergang machte die Abhängigkeit sichtbar, weil Kontinuität bewusste technische Arbeit erforderte. Er zeigte auch, dass der Betrieb von SRI an einen anderen Anbieter übergeben werden konnte.

Was den Transfer überlebte, kann nicht zuversichtlich einer einzelnen Rechtsquelle zugeschrieben werden. Die Dienstnamen überlebten. Vertraute elektronische Adressen wurden umgeleitet. Registerdaten wurden fortgeführt. Nutzern wurde mitgeteilt, dass minimale Auswirkungen zu erwarten seien. Dennoch belegt kein geprüftes öffentliches Instrument, ob diese Ergebnisse aus vertraglichen Übergangspflichten, aus Regierungseigentumsrechten, aus für den Anlass ausgehandelter Kooperation, aus professioneller Praxis oder aus einer Kombination davon stammten.

Das von den Beschaffungsaufzeichnungen aufgeworfene Gegenbeispiel muss daher präzise bleiben. Wenn DCA oder DISA SRI ersetzt hätten, während externe Netzwerke weiterhin auf das Register angewiesen waren, zeigen die erhaltenen Dokumente, dass operative Kontinuität die Bewegung von Daten, die Umleitung von Anfragen, die Kommunikation mit Nutzern und die Erhaltung anerkannter Kennungsaufzeichnungen erfordert hätte. Sie belegen nicht, welche Partei diese Handlungen rechtlich erzwingen konnte, welche Daten oder Software Regierungseigentum waren, welche Zahlung den Transfer begleitete oder welche Nutzer Leistung verlangen konnten.

Andere Beweise könnten diese Antwort ändern. Der SRI-Vertrag und seine Änderungen könnten von der Regierung gestelltes Eigentum, Datenlieferanforderungen, Übergangsunterstützung oder fortbestehende Verpflichtungen identifizieren. Eine Nachfolgeausschreibung und GSI-Vergabe könnten die Service-Population, Übergangmeilensteine und Abnahmebedingungen definieren. Der Network Solutions-Unterauftrag könnte die tatsächliche Arbeitsteilung identifizieren. Keiner dieser Bedingungen kann aus der Tatsache abgeleitet werden, dass die Übergabe erfolgreich war.

RFC 1261 ist dennoch wichtig, weil er demonstriert, dass externe Abhängigkeit ein operatives Anliegen und keine abstrakte Möglichkeit war. Die Mitteilung sprach DDN- und Internetnutzer an, antizipierte Störungen, bewahrte vertraute elektronische Anfragepfade und plante eine kurze Datenbankeinfrierung. Der Dienst wurde als gemeinsame Infrastruktur geführt, auch wenn die rechtliche Stellung jedes externen Nutzers in der Mitteilung nicht preisgegeben wird.

Praktische Abhängigkeit und ihre Grenzen

Bis in die späten 1980er Jahre saß das DDN-NIC an der Schnittstelle mehrerer Arten von Abhängigkeit. Einige waren direkte Folgen staatlicher Betriebsregeln. Andere ergaben sich aus technischer Delegation, Hierarchie und gemeinsamer Annahme.

Für einen erfassten DDN-, ARPANET- oder MILNET-Nutzer konnte die relevante Verpflichtung in einer Betriebsspezifikation oder Managementanweisung ausdrücklich sein. Ein Host musste möglicherweise seinen offiziellen Namen registrieren, Genehmigung für eine Änderung einholen oder genaue Benutzerinformationen liefern, weil der staatliche Netzwerkadministrator dies verlangte. SRI bearbeitete den Eintrag, aber die bindende Beziehung lief über die von der Regierung verwaltete Einrichtung.

Für einen Domänenantragsteller außerhalb dieser Population ergab sich die unmittelbare Konsequenz aus dem gemeinsamen Namensraum. Ein vollständiger Antrag und eine konforme Nameserver-Konfiguration waren Bedingungen für eine Delegation unter der relevanten Top-Level-Domäne. Die Rolle des DDN-NIC wurde durch die Richtlinien von IAB und DARPA, die Benennung der DCA für die DDN- und DARPA-Teile und die hierarchische Autorität, die Registraren und Domänenadministratoren zugewiesen ist, unterstützt. Der Anreiz des Antragstellers war die anerkannte Auflösung durch das gemeinsame System.

Für einen Nummernantragsteller identifizierte RFC 1174 eine andere Brücke: Die IANA-Funktion von USC/ISI hatte die Verantwortung für Netzwerknummern- und AS-Nummernregistrierung bei der Internet Registry von SRI angesiedelt. Der Wert der Zuweisung ergab sich aus der Einzigartigkeit und Anerkennung über teilnehmende Systeme hinweg. Sie allein schuf keine Route, Verbindung oder Erlaubnis, ein staatlich gefördertes Backbone zu nutzen.

Für einen Betreiber, der Registereinträge konsultierte, konnte die Abhängigkeit indirekt sein. Der Betreiber nutzte veröffentlichte Nummern, Namen und Kontakte, weil Koordination Kollisionen reduzierte und Kommunikation praktikabel machte. Diese Abhängigkeit konnte einen Fehler im Register auch ohne direkten Vertrag zwischen dem Betreiber und SRI folgenreich machen. Sie bedeutete dennoch nicht, dass jede Richtlinienentscheidung des Betreibers an das Register delegiert worden war.

Diese Beziehungen sind nicht austauschbar. Der formelle Umfang betrifft die Population und die Aufgaben, die durch eine staatliche Vereinbarung identifiziert werden. Die technische Abhängigkeit betrifft, ob ein System bequem oder zuverlässig ohne eine gemeinsame Aufzeichnung funktionieren kann. Interoperabilitätskonvention betrifft die gemeinsamen Praktiken, durch die unabhängige Systeme Kennungen erkennen. Institutionelle Akzeptanz betrifft das Gewicht, das Betreiber Zuweisungen beimessen, die von etablierten technischen Gremien gebilligt werden.

Geerbte Abhängigkeit betrifft die Abhängigkeit, die sich ansammelt, weil frühere Teilnehmer um den Dienst herum gebaut haben.

Die Beweislage ist am stärksten, wenn sie die genaue Brücke identifiziert. RFC 810 verband die Registrierung mit den Bedingungen, unter denen DoD-Hosts Verkehr austauschten. RFC 920 verband die Domäneneinrichtung mit der Richtlinie und Hierarchie des ARPA-Internet und der DARPA-Forschungsgemeinschaft. RFC 1032 verband die Genehmigung mit einem vollständigen Antrag und den Verantwortlichkeiten der Domänenverwaltung. RFC 1174 verband die Nummernregistrierung mit der IANA-Delegation, während die Registrierung vom Verbindungsstatus und der Routing-Richtlinie getrennt wurde.

RFC 1261 zeigte, dass Dienstkontinuität für DDN- und Internetnutzer einen gesteuerten Betriebsübergang erforderte.

Kein geprüftes öffentliches Instrument belegt, dass eine dieser Brücken alle anderen stillschweigend enthielt. Ein Domänenantrag war keine allgemeine Zustimmung, jeder DDN-Regel zu gehorchen. Eine Netzwerknummernzuweisung war keine Erlaubnis, jedes Backbone zu nutzen. Die Abhängigkeit von WHOIS machte den abfragenden Betreiber nicht zu einem vertraglichen Begünstigten. Die Veröffentlichung in einer gemeinsamen Datenbank übertrug nicht die Kontrolle über das interne Netzwerk einer Organisation an SRI.

Das Gegenteil gilt ebenfalls. Das Fehlen einer universellen Beschaffungsklausel macht die Entscheidungen des NIC nicht in jedem praktischen Sinne optional. Eine Organisation, die eine anerkannte Domäne unter einer vom NIC verwalteten Top-Level-Domäne suchte, konnte das Verfahren des Registrars nicht einfach ignorieren und erwarten, dass dieselbe Delegation in der gemeinsamen Hierarchie erscheint. Ein Netzwerk, das eine eindeutige Nummer vom delegierten Internet-Register suchte, musste sich dessen Zuweisungsverfahren unterwerfen. Die Autorität war schmal, aber sie war real, wo die Dienstgrenze real war.

Deshalb ist der Status eines Auftragnehmers weder ein Vorwurf noch eine vollständige Erklärung. SRI konnte einen kompetenten, vertrauenswürdigen und weitgehend genutzten Dienst unter staatlicher Schirmherrschaft liefern. Seine Mitarbeiter konnten erhebliches Ermessen bei der Prüfung von Anträgen, der Pflege von Daten, der Koordination von Kontakten und dem Betrieb von Servern ausüben. Die Governance-Frage ist nicht, ob diese Arbeit wichtig war.

Es geht darum, welcher Auftraggeber jede Handlung autorisierte, welche Nutzer von den Regeln dieses Auftraggebers erfasst waren und welche zusätzlichen Institutionen den Dienst mit Personen außerhalb der Beschaffungskette verbanden.

Was der Titel sicher bedeuten kann

Die Beweise stützen eine begrenzte Antwort auf drei getrennte Fragen.

Innerhalb der DDN- und DoD-Kette hatte die DCA eine dokumentierte behördliche Rolle und SRI war ein dokumentierter Auftragnehmer. Betriebsspezifikationen und Handbücher verlangten die Registrierung oder Genehmigung für definierte DDN-, ARPANET- und MILNET-Aktivitäten. Das DDN-NIC bearbeitete Aufzeichnungen, unterhielt Dienste und kommunizierte Verfahren im Namen der DCA. Die Verbindlichkeit dieser Handlungen ergab sich aus der Verwaltung des Netzes durch die DCA und den Verpflichtungen der erfassten Einrichtungen.

Da die relevanten Leistungsbeschreibungen und Rechtsbehelfsbestimmungen nicht verfügbar sind, kann der genaue vertragliche Umfang nicht rekonstruiert werden.

Außerhalb dieser Beschaffungspopulation akzeptierten und verließen sich Organisationen auf mehrere Dienste. Sie suchten eindeutige Kennungen von der Internet Registry, beantragten Domänen in der gemeinsamen Hierarchie, fragten WHOIS ab, bezogen RFCs und verließen sich auf Root-Server-Daten. Ihre Gründe umfassten die IANA-Delegation, Richtlinien von IAB und DARPA, die begrenzte Benennung der DCA, die Befolgung von Registrierungsverfahren durch Antragsteller, technische Interoperabilität, akkumuliertes Vertrauen und die praktischen Kosten des Abweichens von einem weit verbreiteten System.

Diese Brücken gaben dem DDN-NIC reale Autorität über bestimmte Registrierungsentscheidungen.

Autorität über einen Registereintrag war nicht Autorität über jede assoziierte Institution oder jedes assoziierte Netzwerk. Domänenadministratoren behielten die Verantwortung innerhalb ihrer Domänen. IANA blieb von der Internet Registry verschieden. DCA und DARPA hatten unterschiedliche institutionelle Rollen. Kennungszuweisung lieferte keine Verbindung. DNS-Aufnahme befahl nicht jede Route. Die akzeptable Nutzungsrichtlinie eines Backbones galt durch die Nutzung dieses Backbones, nicht bloß durch das Erscheinen in einer zentralen Datenbank.

Kein geprüftes öffentliches Instrument belegt eine universelle Brücke, durch die die Beschaffung von SRI-Diensten durch die DCA allein jedes nicht vertragschließende Netzwerk band, das die resultierenden Aufzeichnungen nutzte. Ebenso tilgt das Fehlen eines solchen Instruments die engere Autorität, die durch die IAB-Richtlinie, die DARPA-Förderung, die IANA-Delegation, die Hierarchieregeln und die Antragstellerteilnahme geliefert wurde.

Die Beschaffungsaufzeichnung ist zu unvollständig, um eine größere rechtliche Schlussfolgerung zu stützen. Tatsächliche Verträge könnten mehr offenbaren: eine breitere beschaffte Population, interbehördliche Verpflichtungen, Datenrechte, Übergangsanforderungen oder definierte Rechtsbehelfe. Eine externe Antragsakte könnte zeigen, wie eine umstrittene Entscheidung behandelt wurde. Bis diese Instrumente vorgelegt werden, können Pflichten, Rechte und Rechtsbehelfe nicht aus RFCs, Archivzusammenfassungen oder späteren institutionellen Geschichten zurückgerechnet werden.

In diesem disziplinierten Sinne war das DDN-NIC ein Auftragnehmer, keine Verfassung. Die Formulierung bedeutet nicht, dass das Zentrum keine Autorität oder Legitimität besaß. Sie bedeutet, dass der Status als Auftragnehmer die Bereitstellung eines staatlich geförderten Dienstes und einen Teil der innerhalb der Beschaffungskette ausgeübten Macht erklärt, während Autorität anderswo durch zusätzliche, dienstspezifische Beziehungen nachverfolgt werden muss.

Diese Darstellung gibt dem DDN-NIC die gebührende Anerkennung. SRI betrieb in einer Zeit raschen institutionellen und technischen Wandels wichtige Infrastruktur. Seine Mitarbeiter unterhielten Register, Verzeichnisse, Publikationen, Unterstützungskanäle und Server, die über die engste militärische Population hinaus genutzt wurden. Die Dienste waren so wertvoll, dass ihre Übergabe 1991 die Aussetzung von Registrierungsaktionen, die Bewegung der Master-Datenbank, die Umleitung von Anfragen und einen koordinierten Wechsel der Host-Infrastruktur erforderte.

Die Governance-Lektion liegt in dieser Kombination aus Leistung und unvollständiger Dokumentation. Erfolgreiche Verwaltung kann zur gemeinsamen Infrastruktur werden, bevor die Rechte jeder abhängigen Partei in öffentlichen Aufzeichnungen sichtbar sind. Technische Abhängigkeit kann einem Auftragnehmer großen praktischen Einfluss geben. Sie beseitigt nicht die Notwendigkeit, den Auftraggeber, die delegierte Funktion, die erfasste Population, den Überprüfungsmechanismus und die Grenze zu identifizieren, jenseits derer eine andere Institution Autorität liefern muss.

Quellen