Zusammenfassung
- Die von 1983 bis 1992 veröffentlichten Anweisungen beschrieben Formulare, technische Anforderungen, verantwortliche Verwalter, Korrekturwege und Kontaktkanäle. In der hier untersuchten Dokumentenstichprobe richteten sie kein allgemeines, unabhängiges Berufungsamt für einen erfolglosen Antrag auf eine Domain oder digitale Kennung ein.
- Die Listen registrierter Nutzer, Domains und zugewiesener Netznummern bewahren abgeschlossene oder aktuelle Aufzeichnungen. Sie geben nicht die Gesamtzahl der eingereichten, unvollständigen, verzögerten, zurückgezogenen, abgelehnten, korrigierten, überdachten, eskalierten, stornierten oder anderweitig abgeschlossenen Anträge preis.
- Der NIC-Schriftwechsel, die Telefonhilfe, die Verwaltung der übergeordneten Domain, die staatliche Schirmherrschaft, die IANA-Autorität und die bundesstaatliche Aufsicht hätten bei der Lösung bestimmter Probleme helfen können. Die Stichprobe enthält keine nachweislichen Beweise auf Antragsebene, dass einer dieser Wege als Beschwerde eines Antragstellers mit einem begründeten und aufgezeichneten Ergebnis funktioniert hat.
- Die Zuständigkeitskarte ist daher uneinheitlich: Das NIC-Personal konnte Aufzeichnungen bearbeiten und korrigieren; Host- und Domain-Administratoren konnten lokale Einreichungen genehmigen oder überarbeiten; Sponsoren konnten die Konnektivität beeinflussen; das IAB konnte Richtlinien empfehlen; und die IANA besaß und delegierte die Befugnis zur Nummernvergabe. Die individuelle Berufungszuständigkeit und die Annullierungspflichten bleiben ungeklärt.
- Ein niedriges Niveau aufgezeichneter Konflikte ist sowohl mit wohlwollenden als auch mit skeptischen Darstellungen vereinbar. Probleme konnten in der Regel durch vertrauensvolle Beziehungen genau gelöst werden, oder erfolglose Antragsteller könnten aus Akten verschwunden sein, die darauf optimiert sind, Zuweisungen und nicht Verfahrenshistorien zu erhalten. Der verfügbare Nenner erlaubt keine Unterscheidung zwischen beiden.
Der verborgene Nenner hinter jeder Erfolgsliste
Eine veröffentlichte Tabelle der Netznummern ist eine Aufzeichnung der Ankünfte. Sie zeigt die Kennungen, die in das offizielle Register eingetragen wurden, und gelegentlich die Einträge, die sich während eines Übergangs änderten. Eine Domaintabelle zeigt ebenso die Namen, die die Registrierung abgeschlossen haben. Keine der beiden Tabellen erfasst jeden Versuch, der dem Ergebnis vorausging.
Das ist das Nennerproblem. Eine institutionelle Geschichte der frühen Internet-Verwaltung muss die Anträge zählen, nicht die Zuweisungen. Die relevante Population würde erste Einreichungen, Duplikate, technisch fehlerhafte Formulare, zur Nachbesserung zurückgesandte Anträge, Rücknahmen, Korrekturen, Verzögerungen, inhaltliche Ablehnungen, erneute Anträge, Eingriffe von Sponsoren, Überlegungen, Eskalationen, Stornierungen und Fälle, die ohne dokumentierte Verfügung endeten, umfassen. Ein Register, das zur Aufbewahrung eindeutiger Kennungen aufgebaut wurde, liefert nur eine Teilmenge dieser Population.
Der normale Weg ist viel einfacher zu rekonstruieren.
Als unmittelbare Basisreferenz für die frühere Periode forderteRFC 810vom 1. März 1982, dass Namen und Adressen von Netzwerken, Gateways und Rechnern des Verteidigungsministeriums vor der Nutzung und bevor ein DoD-Rechner Verkehr sendet, mit dem Network Information Center ausgehandelt und registriert werden müssen. Sie identifizierte elektronische und telefonische Kontaktwege. Für eine Zwischenzeit würde das NIC auch versuchen, vergleichbare Informationen von Nicht-DoD-Netzwerken und -Rechnern zu pflegen. Die Anweisung legte fest, wo die Registrierung stattfand. Sie beschrieb weder ein Antragsregister noch einen Weg, um eine ablehnende Entscheidung anzufechten.
RFC 920, veröffentlicht im Oktober 1984, spezifizierte die Anforderungen für die Einrichtung einer Domain. Eine Domain war eine administrative Einheit, nicht nur eine Bezeichnung. Sie erforderte eine verantwortliche Person mit technischer Kompetenz und organisatorischer Autorität, einen zuverlässigen Namensdienst und eine Registrierung über die entsprechende Hierarchie. Eine Domain niedrigerer Ebene musste den unmittelbar Vorgesetzten zufriedenstellen. Das Dokument enthielt einen Fragebogen für die vorgeschlagene Domain, Kontakte, Serveranordnung, geplante Größe und Verwaltungsstruktur.
RFC 1032, der Leitfaden für Domain-Administratoren von November 1987, machte das Arbeitsverfahren expliziter. Ein Administrator besorgte einen Fragebogen, füllte ihn aus und sandte ihn an den NIC-Hostmaster. Das Hostmaster-Personal prüfte die Informationen auf Vollständigkeit. Der Leitfaden erwartete mehrere E-Mail-Wechsel vor der Genehmigung. Korrekturen konnten später eingereicht werden, und Antragsteller konnten Fragen per E-Mail oder über eine gebührenfreie Hotline stellen.
Diese Dokumente belegen, dass es ein Verfahren, ein Verwaltungsbüro und einen Hilfskanal gab. Sie zeigen nicht, wie viele Anträge auf jeder Stufe stehen geblieben sind. Ein endgültiger Domain-Eintrag könnte auf eine erste vollständige Einreichung, eine routinemäßige Klärung, eine wiederholte technische Korrektur, ein Eingreifen eines übergeordneten Domain-Administrators oder den Ersatz eines früheren Vorschlags gefolgt sein. Sobald die Domain im Register erschien, konvergierten diese Verläufe zum selben sichtbaren Ergebnis.
Das gleiche Problem betrifft die Veröffentlichungen von Netznummern.RFC 1062, ausgegeben im August 1988, listete die zugewiesenen Netznummern auf und unterschied Forschungs-, Verteidigungs-, nicht-militärische Regierungs- und kommerzielle Nutzer. Sie markierte auch einige Nummern, die für die vorübergehende Nutzung geändert wurden. Diese Informationen dokumentieren Zuweisungen und Umnummerierungen. Sie identifizieren nicht alle Anträge, geschweige denn alle erfolglosen Anträge.
Eine leere Nummer in der Tabelle ist kein Beweis für einen abgelehnten Antragsteller. Eine registrierte Nummer ist kein Beweis dafür, dass der ursprüngliche Antrag vollständig war. Eine Änderungsmarkierung zeigt nicht, ob die Änderung beantragt, auferlegt, angefochten oder einfach technisch war. Die Tabelle bewahrt den Betriebszustand, nicht den Weg, auf dem der Zustand erreicht wurde.
Ein geringer sichtbarer Konflikt kann daher zwei Erzählungen stützen. Die wohlwollende Erzählung besagt, dass Administratoren und technisch versierte Antragsteller sich im Allgemeinen verstanden, Fehler per Korrespondenz korrigierten und selten ernsthafte Streitigkeiten hervorbrachten. Die skeptische Erzählung besagt, dass ein System, das um aktuelle Zuweisungen herum organisiert war, wenig operative Gründe hatte, fehlgeschlagene Versuche, ungeschriebene Erklärungen oder enttäuschte Antragsteller aufzubewahren. Beide Erzählungen sagen eine saubere Liste erfolgreicher Einträge voraus.
Die überlebenden Listen können nicht zwischen ihnen wählen.
Eine Zustandsmaschine, kein genehmigt-abgelehnt-Binärsystem
Die minimale analytische Sequenz ist:
eingereicht -> unvollständig -> Nachfrage -> verzögert -> abgelehnt -> korrigiert -> überdacht -> eskaliert -> annulliert oder endgültig
Diese Notation soll nicht andeuten, dass jeder Antrag alle Zustände durchlief. Tatsächliche Pfade wären verzweigt. Ein unvollständiger Antrag konnte korrigiert werden und fortfahren. Ein vollständiger Antrag konnte zurückgezogen werden. Eine Ablehnung konnte ohne Überlegung endgültig werden. Eine Eskalation konnte die Schirmherrschaft oder Konnektivität betreffen, nicht die Entscheidung über die Kennung. Der Wert der Sequenz liegt darin, dass sie verhindert, dass verschiedene Verfahrensereignisse auf das Wort „abgelehnt“ reduziert werden.
Eingereichtbedeutet, dass eine identifizierbare Behörde einen Antrag erhalten hat. Der Nachweis sollte das eingehende Formular, die Nachricht oder den Brief enthalten, vorzugsweise mit einem Eingangsdatum und genügend Kontext, um zu bestimmen, welcher Dienst beantragt wurde. Ein späterer Eintrag beweist, dass ein bestimmter Prozess erfolgreich war; er legt nicht das Datum oder den Inhalt der ersten Einreichung fest.
Unvollständigbeschreibt einen Bearbeitungszustand. Erforderliche Felder, verantwortliche Kontakte, Serveranordnungen oder Autorisierung konnten fehlen. RFC 1032 verlangte einen ausgefüllten Fragebogen, bevor das NIC eine Domain genehmigte. Diese Regel dokumentiert die Kategorie, aber die Stichprobe enthält keinen zugehörigen Antragsdatenbestand, der einen namentlich genannten Antrag als unvollständig klassifiziert zeigt.
Nachfrageist ein positiver Verwaltungsakt. Die Erwartung mehrerer Korrespondenzwechsel in RFC 1032 zeigt, dass die Klärung Teil der normalen Bearbeitung war. Ein Einzelfall würde dennoch die ausgehende Frage, den Antrag, auf den sie sich bezieht, und alle Antworten erfordern. Eine zweite Einreichung allein kann nicht zeigen, ob die erste eine Frage hervorrief.
Verzögerterfordert Daten und einen fortlaufenden, ungelösten Antrag. Das Intervall muss unterteilt werden in Personalbearbeitungszeit, Antwortzeit des Antragstellers, Prüfung durch den Sponsor, technische Vorbereitung und etwaige politische Fragen. Eine Domain, die Monate nach der Diskussion eines ersten Plans registriert wurde, ist nicht automatisch ein verzögerter Antrag. Ohne einen dokumentierten Beginn, Pausen und ein Endereignis bleibt die Verzögerung unbewiesen.
Zurückgezogenbedeutet, dass der Antragsteller den Antrag beendet hat. Dieser Zustand erfordert eine Erklärung oder ein Verhalten, das zuverlässig dem Antragsteller zugeschrieben werden kann. Schweigen ist mehrdeutig: Der Antragsteller könnte den Plan aufgegeben, den Vermittler gewechselt, das Problem telefonisch gelöst oder nie eine Antwort erhalten haben.
Abgelehntist eine inhaltlich ablehnende Entscheidung, nicht das Fehlen einer Zuweisung. Die direkte Akte sollte die entscheidende Behörde, die einschlägige Anforderung, den Grund und die Kommunikation des Ergebnisses identifizieren. Ein schlecht geformtes Muster, eine unbeantwortete Frage, ein unberechtigter Verbindungsantrag und ein Domainstreit, der an lokale Parteien verwiesen wird, sind unterschiedliche Ereignisse.
Korrigiertbedeutet, dass sich die Daten, die angeforderte Konfiguration oder die unterstützenden Informationen geändert haben. Die Korrektur muss nicht unbedingt eine Meinungsverschiedenheit beinhalten. Sie kann eine gewöhnliche Qualitätskontrolle sein. Die Dokumente aus der Zeit belegen direkt Korrekturverfahren, obwohl sie diese Verfahren nicht in Berufungen umwandeln.
Überdachtbedeutet, dass der Beamte oder die Verwaltungseinheit eine bereits getroffene Feststellung noch einmal überprüft hat. Die Fortsetzung der Bearbeitung, nachdem der Antragsteller fehlende Daten bereitgestellt hat, mag ähnlich erscheinen, ist aber nicht unbedingt eine Überlegung einer ablehnenden Entscheidung. Eine Fallakte muss die frühere Position und die spätere erneute Prüfung zeigen.
Eskaliertbedeutet, dass ein Problem an eine andere Behörde oder eine andere institutionelle Ebene verschoben wurde. Ein Hostmaster konnte einen leitenden Kollegen einschalten; ein Antragsteller konnte sich an einen Sponsor wenden; das DDN-Programmbüro konnte sich einschalten; oder eine politische Frage konnte die IANA oder ein bundesstaatliches Netzwerkgremium erreichen. Die bloße Kopie eines leitenden Beamten im Schriftverkehr beweist keine Eskalation, und eine Eskalation beweist keine Prüfung.
Annullierterfordert zwei unvereinbare Entscheidungen: ein identifizierbares früheres Ergebnis und ein späteres Ergebnis, das es geändert hat. Eine korrigierte Schreibweise, eine neue Serveradresse, eine Umnummerierung oder ein überarbeiteter Antrag ist keine Annullierung, es sei denn, die Akte legt auch die Entscheidung fest, die aufgehoben wurde.
Endgültigist das gefährlichste Etikett. Ein veröffentlichtes Verfahren kann eine Entscheidung für endgültig erklären, oder eine vollständige Fallakte kann zeigen, dass die verfügbare Prüfung abgeschlossen ist. Die letzte überlebende Nachricht beweist keine Endgültigkeit. Sie kann das letzte aufbewahrte Element sein, nicht das letzte eingetretene Ereignis.
Der Beweisstatus in dieser Stichprobe ist daher asymmetrisch:
| Antragsstatus | Was die Stichprobe belegt | Status auf Fallebene |
|---|---|---|
| Eingereicht | Es gab veröffentlichte Formulare und Kanäle | Keine vollständigen Einzelantragsakten geprüft |
| Unvollständig | Die Domain-Genehmigung erforderte vollständige Informationen | Prozess dokumentiert; kein namentlicher Fall |
| Nachfrage | Iterativer Schriftverkehr wurde erwartet | Prozess dokumentiert; keine verknüpfte Sequenz |
| Verzögert | Verzögerung kann nur durch datierte Fallereignisse definiert werden | Nicht beobachtet |
| Zurückgezogen | Erfordert eine dem Antragsteller zuzuschreibende Beendigung | Nicht beobachtet |
| Abgelehnt | Erfordert eine inhaltliche Entscheidung und einen erklärten Grund | Nicht beobachtet |
| Korrigiert | Benutzermodelle, Domaindaten und veröffentlichte Nummerneinträge konnten korrigiert werden | Direkt dokumentiert, aber nicht als Berufung |
| Überdacht | Die Politik wurde auf Systemebene 1990 überdacht | Kein Einzelfall eines Antragstellers beobachtet |
| Eskaliert | Institutionelle Kanäle bestanden über Administratoren, Sponsoren und Regierungsstellen | Möglicher Weg; kein qualifizierter Fall beobachtet |
| Annulliert | Erfordert gepaarte ablehnende und spätere unvereinbare Entscheidungen | Nicht beobachtet |
| Endgültig | Erfordert eine erklärte oder nachweisbare endgültige Verfügung | Nicht beobachtet |
Diese Tabelle schätzt keine Häufigkeit. Sie hält die Beweislage jedes Zustands in einer Stichprobe veröffentlichter Verfahren fest. Keine Ablehnung, Verzögerung, Eskalation, Annullierung oder endgültige Verfügung wird als historischer Fall geliefert, da die erforderlichen direkten Akten nicht erstellt wurden.
Die Dokumentenstichprobe und was sie ausschließt
Der interessierende Zeitraum ist 1983–1992. Die RFC 810 wird nur als Referenz vom März 1982 für die vererbte Host-Registrierungsregel verwendet. Die RFC 1400, veröffentlicht 1993, erscheint nur als kurzer Vergleich, der zeigt, wie die explizite Sichtbarkeit des Antragsstatus später in ein öffentliches Verfahren aufgenommen wurde.
Die Stichprobe ist eineStichprobe veröffentlichter Verfahren und institutioneller Autorität, kein Korpus einzelner Anträge. Ihre Einheit ist ein Dokument oder ein öffentliches Dokumentenartefakt. Sie besteht aus:
- RFC 920, RFC 1032, RFC 1062, RFC 1174 und RFC 1359;
- dem NIC-Dokument vom 20. Oktober 1983 „Instructions for Network User Registration Drive“, aufbewahrt auf den Seiten 67–73 der digitalisierten Charge des Computer History Museum,Defense Communication Agency Materials; 6 of 13;
- „How to Reach the NIC“,NIC KNACKS, Ausgabe 2, datiert auf den 17. Mai 1985, aufbewahrt auf Seite 94 der digitalisierten Charge vonDefense Communications Agency Materials; 3 of 13;
- dem Leitfaden des Computer History Museum von 2011,Guide to the SRI ARC/NIC Records, Sammlung X3578.2006;
- dem Interview von James Pelkey mit Jon Postel, aufgezeichnet am 18. Februar 1988;
- und der späteren Rechtsgeschichte des Government Accountability Office der USA bezüglich Bundesverträgen über DNS- und IANA-Funktionen.
Die Dokumente wurden aufgenommen, wenn sie eine Antragsanforderung, einen Verwaltungskanal, einen Korrekturprozess, eine Vergabeautorität, eine Sponsorenunterscheidung, eine politische Empfehlung oder eine Aufsichtsbeziehung beschrieben, die für 1983–1992 relevant ist. Die RFC 1062 ist als veröffentlichtes Ergebnisartefakt und nicht als Antragsleitfaden enthalten. Das Findmittel wird verwendet, um die Archivlandschaft zu definieren, nicht als Ersatz für die Aufzeichnungen innerhalb der Sammlung. Das Interview mit Postel liefert einen begrenzten Kontext zur Dokumentenkultur, keine Beweise für Kennungsfälle.
Die GAO-Stellungnahme ist eine spätere Rechtsgeschichte und beschränkt sich auf die Vertragsketten, die sie tatsächlich überprüft hat.
Mehrere Beweiskorpora liegen außerhalb dieser Stichprobe. Es handelt sich nicht um eine kistenweise Prüfung der SRI-ARC/NIC-Sammlung mit 281 Kartons. Es wird nicht behauptet, jede Domain-Anfrage, Host-Tabellen-Aktualisierung, Nummern-Anfrage, Hotline-Protokoll, monatliche Berichte, Sponsorschreiben oder interne Mitteilung geprüft zu haben. Es behandelt die Beschreibungen des Findmittels nicht als Beweis für das Ergebnis irgendeines Antrags. Es enthält keine statistisch beprobten Antragsakten.
Die Stichprobe schließt auch Rückschlüsse aus aktuellen Registerdaten aus. Ein späterer WHOIS-Eintrag oder eine überlebende Delegation kann keinen frühen Antrag ohne zeitgenössische Korrespondenz rekonstruieren. Mündliche Erinnerungen werden nicht als Antrag gezählt, es sei denn, sie werden mit direkten Aufzeichnungen abgeglichen. Zeilen der Zuweisung sind Ergebnisse, keine Antragseinheiten.
Das FindmittelSRI ARC/NICbeschreibt 351 laufende Fuß in 281 Kartons, der Großteil des Materials stammt aus den Jahren 1968–1990. Zu den relevanten Serien gehören NIC-Vorschläge und -Verträge, formelle Monatsberichte, vertragliche Leistungen, Referenz- und Hotline-Betrieb, Benennung und Adressierung, TAC-Benutzerzugriffsregistrierung, Verwaltung von Netzkontakten sowie verschiedene E-Mails und Korrespondenzen.
Der Leitfaden besagt, dass die Sammlung einen vollständigen Satz formeller monatlicher NIC-Berichte enthält. Er besagt nicht, dass diese Berichte einen einzigen Antragsnanner enthalten. Monatliche Summen für Anrufe, Nachrichten, Aktualisierungen oder Registrierungen müssten immer noch mit einzelnen Anträgen verknüpft werden. Zehn Nachrichten könnten zehn Antragsteller oder zehn Austausche zu einem Antragsteller darstellen. Ein Anruf bei der Hotline könnte den Zugriff auf ein Dokument, ein Konnektivitätsproblem, eine Host-Aktualisierung oder eine Kennungsanfrage betreffen. Die aggregierte Aktivität ist keine Reihe von Verfügungen.
Der Leitfaden kartiert auch verschiedene Korrespondenzen bis 1989. Da die Korrespondenz von verschiedenen Orten gesammelt wurde und viele Themen abdeckt, kann ihre Existenz keine Vollständigkeit begründen. Ein Antrag könnte von seiner Antwort getrennt sein. Telefongespräche könnten keine überlebende Notiz haben. Die Akten könnten nach Mitarbeiter, Datum oder Dienst organisiert sein und nicht nach Antragsteller. Eine Prüfung der physischen Archive könnte Ausnahmefälle zutage fördern, aber dieser Artikel erhebt keinen Anspruch auf eine Inzidenz, bevor diese Arbeit getan ist.
Eine gültige Studie auf Antragsebene würde eine explizite Einschlussregel erfordern: zum Beispiel alle Domain-Anträge der zweiten Ebene, die erstmals während eines festgelegten Quartals eingegangen sind, unabhängig vom Erfolg. Der einzelne Antrag, nicht die Nachricht, wäre die Zähleinheit. Duplikate, umbenannte Vorschläge, Mehrfacheinreichungen, übertragene Fälle und Anträge über Zwischenregister würden eine vorab festgelegte Behandlung erfordern. Jeder Status würde ein Datum und ein dokumentarisches Kriterium erfordern. Fehlende Nachrichten und Telefonkontakte würden einen Aufbewahrungscode erfordern.
Nichts in der aktuellen Stichprobe unterstützt solche Zählungen.
Der Nenner ist daher undefiniert. Es gibt keine gemeldete Genehmigungsrate, Ablehnungsrate, Annullierungsrate oder durchschnittliche Verzögerung. Es gibt auch keinen Zähler für individuelle Berufungen. Diese Grenze ist methodisch, nicht rhetorisch: Keine noch so große Sicherheit in der Prosa kann Antragsakten erzeugen, die nicht geprüft wurden.
Drei Verwaltungspopulationen, die nicht verschmolzen werden dürfen
Die überlebenden Dokumente beschreiben verwandte, aber unterschiedliche Dienste. Ihre Kombination würde ein imaginäres gemeinsames Berufungssystem schaffen.
Die erste Population ist dieNetzbenutzerregistrierung und der TAC-Zugriff. Die NIC-„Instructions for Network User Registration Drive“ vom 20. Oktober 1983 betrafen Einzelpersonen, die MILNET- und ARPANET-Hosts nutzten, und, für eine Teilmenge, den Zugriff über MILNET-Terminalzugangskontroller. Host-Administratoren erhielten Vorlagen für die ihren Hosts zugeordneten Benutzer, korrigierten vorhandene Daten, fügten berechtigte Benutzer hinzu, markierten Löschungen, überprüften die Ergebnisse und sandten das Material an das NIC zurück. TAC-Zugriffsanfragen erforderten eine Autorisierung über das Postfach des Host-Administrators.
Dies war ein Autorisierungssystem auf Sponsoren- und Host-Seite. Das DDN-Programmbüro erklärte, dass lokale Hosts sich selbst im Rahmen der Regierungsrichtlinien verantwortungsvoll verwalten müssten, und dass es mit Host-Administratoren zusammenarbeiten würde, wenn Probleme aufträten. Diese Sprache begründet einen Problemmelder zwischen dem DDN-PMO und den Administratoren. Sie begründet kein Recht einer Person, deren Host-Administrator die Autorisierung verweigert hat.
Die zweite Population ist dieDomain-Registrierung. RFC 920 und RFC 1032 teilten die Verantwortlichkeiten zwischen Antragsteller, verantwortlichem Domain-Administrator, unmittelbar vorgesetzter Behörde und NIC. Technische Vorbereitung, zuverlässige Server, kompetente Kontakte, organisatorische Klassifizierung und administrative Rechenschaftspflicht waren wichtig. Das NIC konnte die Vollständigkeit überprüfen und technische Fragen beantworten. Die übergeordneten Domain-Autoritäten übten ein hierarchisches Ermessen über die Aufnahme aus.
RFC 1032 zog eine bedeutsame rechtliche Grenze. Sie besagte, dass das NIC nicht als Schiedsrichter in Streitigkeiten fungieren würde, wer das Recht habe, eine bestimmte Top-Level- oder Second-Level-Domain für eine Organisation zu registrieren. Diese Konflikte wurden als private lokale Angelegenheiten behandelt, die vor Beginn der Registrierung zu klären seien. Das NIC-Personal konnte technische Beratung geben, aber keine Schlichtung.
Diese Grenze ist kein Beweis dafür, dass es keine Abhilfe gab. Sie verortete den Streit anderswo: innerhalb einer Organisation, in der Hierarchie der übergeordneten Domain, über vertragliche Beziehungen oder möglicherweise über ein Rechtsforum mit unabhängiger Zuständigkeit. Dennoch benannte RFC 1032 kein Ersatzgericht und sagte nicht, wer entscheidet, ob eine Meinungsverschiedenheit wirklich beigelegt wurde.
Die dritte Population ist dieVergabe digitaler Kennungen. RFC 1062 veröffentlichte die zugewiesenen Netznummern.RFC 1174, ausgeben im August 1990, beschrieb die IANA als die Organisation mit der primären Autorität zur Zuteilung und Vergabe digitaler Kennungen, wobei diese Funktion vom Information Sciences Institute der USC ausgeführt wurde. Sie beschrieb das Internet-Register bei SRI als Sammler und Registrator von Informationen über Netzwerke und Vollzieher delegierter Vergabeaufgaben.
Die Nummernvergabe muss auch von derKonnektivitätgetrennt werden. RFC 1062 wies darauf hin, dass unabhängige Netzwerke, die Internet-Protokolle verwenden, Nummern erhalten konnten, während sie außerhalb des verbundenen Internets blieben, und dass sie separat die Erlaubnis zur Zusammenschaltung beantragen mussten. RFC 1174 beschrieb später den Status „verbunden“ als eine Genehmigung einer Sponsorenorganisation der US-Regierung, um sich an das föderal geförderte System zu binden.
Eine Organisation konnte daher eine eindeutige Nummer erhalten, während ihr die gewünschte Verbindung fehlte. Die Weigerung eines Sponsors, die Zusammenschaltung zu genehmigen, war nicht unbedingt eine Weigerung des Internet-Registers, eine Nummer zuzuweisen. Die möglichen Prüfer waren ebenfalls unterschiedlich. Die IANA und das Internet-Register besetzten die Kette der Nummernvergabe; eine Sponsoring-Agentur oder ein Backbone-Betreiber besetzte die Konnektivitätskette.
RFC 1359, veröffentlicht im August 1992, fügte eine weitere institutionelle Ebene für Campusse hinzu. Sie riet Organisationen, mit einem IP-Diensteanbieter zusammenzuarbeiten, und beschrieb diesen Anbieter als Quelle für Ratschläge zu Adressklassen und Antragsverfahren. Ein Anbieter konnte eine unvollständige Einreichung verhindern, indem er einem Antragsteller bei der Vorbereitung half. Das Dokument zeigt nicht, dass der Anbieter gegen eine Entscheidung des Registers Berufung einlegt.
Die Benutzerregistrierung, der TAC-Zugriff, die Domain-Aufnahme, die Nummernvergabe und die Netzanbindung hatten daher unterschiedliche Antragsteller, Regeln, Behörden und mögliche Rechtsbehelfe. Eine dokumentierte Korrektur in einer Population kann keine Prüfung in einer anderen belegen.
Der direkte Nachweis von Ausnahmen: Korrektur und laufende Bearbeitung
Der stärkste Ausnahmen-Beweis in der Stichprobe betrifft die Korrektur.
Die „Instructions for Network User Registration Drive“ vom 20. Oktober 1983 enthielten eine konkrete Abfolge. Das NIC bereitete Vorlagen für Personen vor, die sich bereits in seiner Identifikationsdatenbank befanden. Host-Administratoren riefen diese Vorlagen ab, ersetzten falsche Daten, fügten fehlende Benutzer hinzu, markierten Löschungen, überprüften und genehmigten die resultierenden Listen und sandten sie an das Register zurück. Das NIC änderte die Einreichungen und gab sie in die WHOIS-Identifikationsdatenbank ein.
Das Dokument war streng hinsichtlich des Formats. Die Daten mussten in der angegebenen Vorlage zurückgesandt werden, damit sie mit weniger manueller Bearbeitung verarbeitet werden konnten. Material in anderer Form würde nicht akzeptiert. Das ist eine direkt dokumentierte Nichtannahmebedingung, die sich jedoch auf die Form der Benutzerregistrierungsdaten bezieht. Es handelt sich nicht um eine inhaltliche Ablehnung eines IP-Adress- oder Domain-Antrags.
Die Anweisungen behandelten auch Duplikate. Wenn mehr als ein Host-Administrator eine Vorlage für dieselbe Person einreichte, erklärte sich das NIC bereit, die Doppelung aufzulösen. Auch hier handelt es sich um eine administrative Qualitätskontrolle. Die Quelle beschreibt keine Anhörung zwischen konkurrierenden Sponsoren oder eine Berufung eines Antragstellers.
Der TAC-Zugriff fügte eine separate Autorisierungsebene hinzu. Das NIC behandelte einen Antrag als genehmigt, wenn die entsprechende Vorlage aus dem Postfach des verantwortlichen Host-Administrators eintraf. Dieser Mechanismus nutzte die institutionelle Beziehung und die Online-Umgebung als praktische Authentifizierungsmethode. Er vermied die Verzögerung durch die Einholung eines unterschriebenen Papierformulars. Er sagte einem Benutzer nicht, wie er den Host-Administrator anfechten kann.
Die dokumentierte Abfolge ist daher:
vorhandene Daten -> Administratorprüfung -> Korrektur oder Hinzufügung -> Autorisierung -> strukturierte Einreichung -> NIC-Bearbeitung
Jeder Pfeil hat eine deklarierte administrative Funktion. Keiner ist eine unabhängige Überprüfung einer früheren inhaltlichen Ablehnung.
Domain-Anträge hatten einen ähnlich iterativen, aber anders geregelten Weg. RFC 1032 verlangte vollständige Informationen und erwartete mehrere Korrespondenzwechsel vor der Genehmigung. Eine Frage des Hostmasters hielt den Antrag in Bearbeitung. Die Antwort eines Antragstellers konnte einen technischen oder administrativen Mangel beheben. Spätere Aktualisierungen konnten die registrierten Informationen auf dem neuesten Stand halten.
Der Leitfaden definierte nicht, wann eine erfolglose laufende Bearbeitung zu einer Ablehnung wird. Er verlangte kein Abschlussschreiben, nachdem der Antragsteller den Hostmaster nicht zufriedenstellte. Er sah kein Überlegungsfenster und keinen separaten Prüfer vor. Diese Auslassungen beweisen nicht, dass das Personal niemals eine Feststellung erläuterte oder noch einmal aufgriff. Sie bedeuten, dass das veröffentlichte Verfahren es einem Historiker nicht erlaubt, ein individuelles Ergebnis ohne die Korrespondenz zu klassifizieren.
RFC 1062 liefert eine dritte Art von Korrektur: geänderte Netznummern. Alte Nummern konnten vorübergehend mit Übergangsmarkierungen sichtbar bleiben. Die Veröffentlichung zeigt, dass der Registerzustand revidiert wurde, während Kontinuitätsinformationen erhalten blieben. Sie identifiziert nicht den Grund, den Antragsteller, den Entscheider oder den Grad der Meinungsverschiedenheit hinter einer Änderung.
Diese Aufzeichnungen stützen drei enge Feststellungen. Die frühe Verwaltung erkannte an, dass Daten fehlerhaft sein konnten. Sie stellte Mechanismen bereit, damit korrigierte Informationen vorhandene Einträge ersetzen oder ergänzen konnten. Sie bewahrte manchmal vorübergehende Ergebnisse nach einer Nummernänderung auf.
Sie liefern keinen abgelehnten Antragsteller, keine Berufung und keine Annullierung.
Die Karte der Annullierungen
Eine Untersuchung von Berufungen wird klarer, wenn jedem Akteur nur das Verb zugewiesen wird, das durch die Akte gestützt wird. Manche Akteure konnten Informationen empfangen oder korrigieren. Manche konnten eine lokale Einreichung genehmigen. Manche konnten eine Politik empfehlen. Die Autorität über eine Kennungsfunktion zu haben, schuf nicht automatisch eine Berufungszuständigkeit.
| Akteur oder Institution | Dokumentierte Fähigkeit | Was beantragt oder beraten werden konnte | Überprüfungs- oder Annullierungsstatus |
|---|---|---|---|
| NIC-Personal und Hostmaster | Formulare entgegennehmen, Vollständigkeit prüfen, korrespondieren, Einträge korrigieren und Registerdaten pflegen | Antragsteller konnten technische und verfahrenstechnische Fragen stellen; Personal konnte fehlende Informationen anfordern | Administrative Korrektur und laufende Bearbeitung dokumentiert; separate Berufungspflicht und Fallannullierung nicht belegt |
| Host-Administrator | Benutzerregistrierungsvorlagen prüfen, korrigieren und genehmigen; TAC-Zugriffsanfragen autorisieren | Benutzer konnten den Administrator bitten, eine Einreichung zu korrigieren oder zu sponsern | Lokale Überlegung möglich; neutrale Überprüfung der eigenen Entscheidung des Administrators nicht belegt |
| Übergeordneter Domain-Administrator | Musste zufrieden sein, bevor eine untergeordnete Domain eingerichtet wurde | Der Antragsteller konnte die Bereitschaft klären oder die Aufnahme in die Hierarchie beantragen | Konnte seine eigene Position ändern; keine unabhängige Berufungsschicht dokumentiert |
| NIC-Leitung | Arbeitete über den Service-Desks und dem Frontline-Personal | Eine Servicebeschwerde konnte an die Leitung gerichtet werden | Beschwerdekanal durch Rolle dokumentiert; Fallprüfregeln und Annullierungspflicht nicht belegt |
| Jon Postel und die IANA-Funktion | IANA besaß die primäre Autorität für die Nummernvergabe; die Vergabe wurde an das Internet-Register delegiert | Registerpersonal oder Antragsteller konnten Klärungen zur Nummernautorität suchen | Keine Postel/IANA-Berufungsakte für Antragsteller oder verpflichtendes Annullierungsverfahren belegt |
| DCA und DDN-PMO | Finanzierten und leiteten die NIC-Arbeit im Zusammenhang mit dem DDN; genehmigten das Benutzerregistrierungsprogramm von 1983; arbeiteten bei Problemen über Host-Administratoren | Administratoren konnten betriebliche oder autorisierungsbezogene Probleme ansprechen | Konnten die Leistung des Programms oder Auftragnehmers behandeln; allgemeine Kennungsberufungszuständigkeit nicht belegt |
| DARPA | Hatte Rollen in Politik, Sponsoring, Forschungsprogramm und benannter Domain in verschiedenen Kontexten | Projektentitäten oder Auftragnehmer konnten Politik- oder Sponsoringfragen aufwerfen | Keine allgemeine veröffentlichte Pflicht zur Überprüfung individueller NIC-Entscheidungen belegt |
| Regierungs-Sponsor | Genehmigte die Anbindung an eine föderal geförderte Infrastruktur im Rahmen des Connected-Status-Systems | Der Antragsteller konnte die Bestätigung oder Erneuerung der Schirmherrschaft suchen | Konnte die Schirmherrschaft ändern; dies würde die Konnektivität beeinflussen, nicht unbedingt die Nummernzuweisung annullieren |
| Internet Activities Board | Formulierte und übermittelte politische Empfehlungen | Konnte die bundesstaatlichen Netzwerkgremien zur Systempolitik beraten | RFC 1174 belegt die Empfehlung, nicht die individuelle Berufungsbefugnis |
| Federal Networking Council | Empfing die Empfehlungen des IAB | Konnte ressortübergreifende Politikvorschläge prüfen | Annahme, Umsetzung, verbindliche Weisung und Annullierung von Antragstellerfällen werden durch RFC 1174 nicht belegt |
| Federal Engineering Planning Group | Entwickelte eine in RFC 1174 gebilligte Empfehlung | Konnte die bundesstaatlichen Netzwerkinstitutionen beraten | Keine individuelle Überprüfungszuständigkeit nachgewiesen |
| Vertragsbeauftragter | Konnte einen anwendbaren Regierungsvertrag verwalten und durchsetzen | Regierungsbeamte konnten Leistungs- oder Leistungsprobleme ansprechen | Wirksame Antragstellerrechtsklauseln und die Befugnis, ein Registrierungsergebnis zu annullieren, wurden nicht belegt |
| Gericht | Konnte einen unabhängig justiziablen Rechtsstreit entscheiden | Ein Antragsteller konnte Abhilfe suchen, wenn Zuständigkeit und Klagegrund bestanden | Kein qualifiziertes Urteil von 1983–1992, das die Annullierung einer NIC- oder IANA-Kennungsentscheidung anordnet, erscheint in der Stichprobe |
| Behördlicher Schieds- oder Beschwerdekanal | Konnte handeln, wenn ein Gesetz, eine Verordnung, ein Vertrag oder eine Programmregel die Befugnis gab | Eine betroffene Partei konnte sich bei einer sponsernden oder vertragschließenden Behörde beschweren | Keine allgemeine veröffentlichte technische Berufung oder garantierte inhaltliche Prüfung belegt |
Diese Karte enthält viele Möglichkeiten zu fragen und weniger Möglichkeiten zu erzwingen. Das NIC-Personal konnte einen von ihm geführten Eintrag korrigieren. Ein Host-Administrator konnte einen Benutzer autorisieren. Ein übergeordneter Domain-Administrator konnte ein lokales Urteil überdenken. Ein Sponsor konnte die Sponsorenentscheidung ändern, die die Verbindung betraf. Ein Regierungskunde konnte die Leistung des Auftragnehmers ansprechen. Das IAB konnte eine politische Änderung empfehlen.
Keine dieser Fähigkeiten schuf auf der Grundlage der hier vorliegenden Beweise ein allgemeines Recht des Antragstellers, dass eine andere Person einen erfolglosen Registrierungsantrag prüft und eine endgültige aufgezeichnete Entscheidung trifft.
NIC-Personal: Bearbeitungsbefugnis ohne veröffentlichte zweite Instanz
Das NIC- und Hostmaster-Personal besetzte die erste sichtbare Entscheidungsstelle für mehrere Dienste. Zu ihren Aufgaben gehörten das Entgegennehmen von Formularen, die Überprüfung der erforderlichen Informationen, die Beantwortung von Fragen, die Datenbankpflege und die Vornahme von Korrekturen. In der Domain-Verwaltung handelten sie innerhalb einer Hierarchie, in der das NIC Register- oder Agent sein konnte, während übergeordnete Domain-Autoritäten die inhaltliche Verantwortung behielten.
Die öffentlichen Anweisungen stützen ein erhebliches Ermessen des Personals bei der Bearbeitung. Vollständigkeit ist selten ein rein mechanisches Konzept. Ein Fragebogen konnte alle Felder enthalten, aber dennoch keinen zuverlässigen Serverbetrieb oder organisatorische Autorität nachweisen. Das Personal konnte entscheiden, dass weitere Erklärungen erforderlich waren. Die veröffentlichten Richtlinien zeigen nicht, ob schwierige Fälle einem leitenden Hostmaster zugewiesen, gemeinsam diskutiert oder nach oben weitergeleitet wurden.
Eine erneute Überlegung durch dasselbe Personal konnte wirksam sein. Wenn ein Antragsteller bessere Beweise vorlegte und der Hostmaster seine Position änderte, war das praktische Problem gelöst. Die historische Klassifizierung hängt jedoch von der früheren Akte ab. Ohne eine erklärte ablehnende Schlussfolgerung ist die Sequenz eine laufende Bearbeitung. Ohne die spätere Begründung ist unmöglich zu wissen, was das Ergebnis änderte.
Die Ausgabe vom 17. Mai 1985 vonNIC KNACKSmit dem Titel „How to Reach the NIC“ zeigte differenzierte Kanäle für Benutzerhilfe, Rechnerbetrieb, WHOIS-Aktualisierungen und Benutzerregistrierung, Host-Änderungen, Newslettermaterial und Vertrags- oder Managementfragen. Sie beschrieb auch eine Hotline, die von Referenz- und Betriebspersonal unterstützt wurde. Dies ist ein Beweis für die Service-Routing. Eine Person, die glaubte, dass eine Akte falsch war, hatte einen Ort, um die Korrektur einzureichen; jemand mit einem Host-Problem konnte die Hostmaster-Funktion erreichen; ein breiteres Anliegen konnte an die Leitung gerichtet werden.
Ein Leitungspostfach ist ein Beschwerdekanal, nicht automatisch ein Berufungsbüro. Die Quelle besagt nicht, dass die Leitung eine Registrierungsentscheidung wieder aufnehmen, einen separaten Beweisstandard anwenden, Gründe angeben oder das Ergebnis aufbewahren musste. Der Kanal mag eine hervorragende informelle Überprüfung hervorgebracht haben. Seine Leistung bleibt ungemessen.
Postel, die IANA und die delegierte Nummernautorität
RFC 1174 liefert die klarste Aussage dieser Zeit über die Nummernautorität. Sie beschrieb die IANA als die Organisation mit der primären Autorität für die digitalen Kennungen, die für den Betrieb des Internets erforderlich sind, wobei die Funktion am Information Sciences Institute der USC ausgeführt wurde. Sie beschrieb das Internet-Register bei SRI als die Einrichtung, die die Registrierungsinformationen pflegt und die Vergabearbeit unter delegierter Verantwortung durchführt.
Die Delegierung schafft ein vertikales Verhältnis, aber ihre genauen Rechtsfolgen hängen von den Bedingungen und der Praxis der Delegierung ab. Die IANA konnte den Umfang der delegierten Arbeit definieren, die Zuteilungspolitik koordinieren und Fragen beantworten, wer die Vergabeautorität besaß. Diese Fähigkeiten belegen nicht, dass ein Antragsteller gegen eine Entscheidung des SRI-Registers bei Jon Postel persönlich Berufung einlegen konnte.
Keine geprüfte Anweisung besagt: Legen Sie Berufung bei der IANA ein, reichen Sie sie innerhalb einer bestimmten Frist ein und erhalten Sie eine inhaltliche Entscheidung. Kein Antragstellerfall in der Stichprobe zeigt Postel, der die Ablehnung eines Antragstellers erhält, die Originalakte prüft und eine andere Zuweisung anordnet. Es wäre ebenso gefährlich, das Gegenteil abzuleiten. Postels Position und die kleine Berufsgemeinschaft machten informelle Konsultationen möglich, aber die Möglichkeit ist kein aufgezeichnetes Verfahren.
Das James-Pelkey-Interview mit Postel vom18. Februar 1988liefert Kontext zur Bewahrung technischer Überlegungen. Postel diskutierte die Tatsache, dass die vollständigen Diskussionen um technische Ideen, die diskutiert, aber nicht übernommen wurden, nicht immer in der veröffentlichten Dokumentation festgehalten wurden. Diese Beobachtung betrifft technische Ideen und die RFC-Geschichte. Sie kann nicht als Beweis dafür übertragen werden, dass Kennungsablehnungen, Berufungen oder Annullierungen auf die gleiche Weise behandelt wurden.
Das Interview ist daher eine Warnung zur Dokumentationskultur, keine Quelle für Antragsergebnisse. Es unterstreicht die Notwendigkeit von Korrespondenz, bevor ein Ausnahmefall rekonstruiert werden kann, beweist aber nichts über die Häufigkeit oder Fairness solcher Fälle.
Das IAB und die bundesstaatlichen Netzwerkgremien: Empfehlungen sind keine Urteile
RFC 1174 war vom Vorsitzenden des Internet Activities Board an den Vorsitzenden des Federal Networking Council gerichtet. Sie enthielt Empfehlungen zur Verteilung der Kennungsvergabe und zur Änderung der alten Connected-Status-Politik.
Das Memorandum empfahl, die zentralen Funktionen der IANA und des Internet-Registers beizubehalten, während Blöcke von Netz- und Autonomen System-Nummern an genehmigte Organisationen delegiert werden. Es empfahl auch, die Kennungsregistrierung von der Connected-Status-Beschränkung zu trennen. Das Internet-Register würde politische Informationen sammeln, und die Aufnahme in das DNS würde nicht mehr an dieselbe bundesstaatliche Konnektivitätsgenehmigung gebunden sein.
Dies ist ein authentischer Beweis für institutionelle Neubewertung auf politischer Ebene. Er zeigt, dass das IAB erkannte, dass eine administrative Regelung, die für eine militärische, staatliche und geförderte Forschungsumgebung konzipiert war, nicht mehr für ein wachsendes kommerzielles und internationales Internet geeignet war. Er zeigt auch, dass das IAB eine vorgeschlagene Antwort an das FNC übermittelte.
Die Verben zählen. Das IABempfahl. Das FNCempfingdie Empfehlung. Das Dokument schlug vor, dass das Internet-Registerbeauftragt werden sollte, Änderungen vorzunehmen. Allein RFC 1174 legt nicht das Datum der Annahme durch das FNC, die Umsetzungsanweisung oder den Abschluss jeder vorgeschlagenen Änderung fest.
Noch wichtiger: Das Memorandum urteilte nicht über einen Antragstellerfall. Es überprüfte nicht die Begründung eines Hostmasters, stellte keine Kennung wieder her oder ordnete keine erneute Prüfung einer früheren Ablehnung an. Politische Reformen können auf angestaute Probleme reagieren, ohne die Namen oder Akten der Betroffenen zu bewahren. Sie können prospektiv wirken, während frühere Ergebnisse intakt bleiben.
Diese Unterscheidung verhindert einen häufigen analytischen Fehler. Die Existenz eines Gremiums, das eine Systempolitik empfehlen kann, beweist nicht, dass dasselbe Gremium individuelle Berufungen angehört hat. Umgekehrt beweist das Fehlen einer Antragstellerakte in einer RFC nicht, dass Bundesbeamte niemals informell eingegriffen haben. Die Empfehlung begründet eine institutionelle Stimme, keine Zuständigkeit für Fälle.
DCA, Sponsoren und der Unterschied zwischen Registrierung und Verbindung
Die Benutzerregistrierungsanweisungen von 1983 stellen das DDN-PMO hinter die Registrierungskampagne. Host-Administratoren waren für autorisierte Benutzer verantwortlich, und das DDN-PMO erklärte, dass es mit ihnen zusammenarbeiten würde, wenn Probleme aufträten. Dies war eine direkte Aussage zur Problemlösung, aber die Beziehung verlief über die Administratoren.
Eine Person, die mit einem Host-Administrator nicht einverstanden war, befand sich in einer schwierigen Position. Das DDN-PMO konnte die geltenden Richtlinien klären oder ein systemisches Problem angehen. Das Dokument versprach nicht, dass die Person den Administrator umgehen und eine unabhängige Überprüfung erhalten konnte. Der Genehmiger war auch der lokale institutionelle Vertreter.
Die staatliche Schirmherrschaft war für die Konnektivität anders relevant. Die Geschichte des Connected-Status in RFC 1174 beschreibt eine Genehmigung durch eine Sponsorenorganisation der US-Regierung. Ein Sponsor konnte bestätigen, dass ein Netzwerk für die Verbindung qualifiziert war, seine Unterstützung zurückziehen oder den Umfang einer finanzierten Aktivität klären. Eine solche Aktion konnte den praktischen Zugang bestimmen, selbst wenn das Internet-Register bereits eine Nummer zugewiesen hatte.
Die Eskalation des Sponsors erfordert daher eine genaue Kennzeichnung. Einen Sponsor zu bitten, die Berechtigung zu bestätigen, ist keine Berufung gegen eine Nummernvergabe. Einen Sponsor zu überzeugen, seine eigene Entscheidung zu ändern, ist eine Überlegung in der Sponsorenkette. Den Sponsor zu bitten, das Register zu kontaktieren, kann eine institutionelle Fürsprache sein. Nur eine direkte Fallakte kann feststellen, was passiert ist.
Die gleiche Genauigkeit gilt für Bundesauftragnehmer und Universitäten. Ein Auftragnehmer konnte ein Netzwerkproblem als Hindernis für die Regierungsarbeit ansprechen. Ein universitärer Forscher konnte die Hilfe eines Programmbeauftragten suchen. Ein militärischer Host hatte Administratoren und Programm-Management-Beziehungen. Diese Strukturen schufen mögliche Wege für die Untersuchung. Die Stichprobe enthält keine vergleichenden Antragsdaten, die zeigen, wie oft sie Ergebnisse geändert haben.
Zwei Vertragsketten, keine ist ein automatisches Rechtsmittel für den Antragsteller
Die Bundesfinanzierung schafft eine Aufsicht, aber sie schafft nicht an sich ein Berufungsrecht.
Die erste relevante Kette istDCA–SRI/NIC. Das SRI-ARC/NIC-Findmittel identifiziert die vom DCA finanzierte NIC-Arbeit, Vertragsvorschläge, Leistungen, Monatsberichte und laufende Überprüfungen. Die DCA-Materialien von 1987 enthalten ein Vertragsprüfungstreffen und beschreiben NIC-Aufgaben und Servicekanäle. Diese Aufzeichnungen belegen, dass der Regierungskunde die Aktivität des Auftragnehmers überwachte.
Dieser Artikel hat die operativen Vertragsklauseln des SRI, die jeden Registrierungsdienst regeln, nicht geprüft. Er behauptet daher nicht, dass diese Verträge eine Antragsfrist, eine Pflicht zur Aufbewahrung von Akten, ein Beschwerdeverfahren für Antragsteller oder die Befugnis des Vertragsbeauftragten, ein bestimmtes Registrierungsurteil aufzuheben, auferlegten. Die staatliche Aufsicht über Leistungen und Servicequalität kann erheblich gewesen sein, ohne einem Antragsteller durchsetzbare Rechte zu verleihen.
Die zweite Kette istDARPA–USC/ISI/IANA. Die EntscheidungGAO B-327398, viel später ergangen, berichtete, dass das GAO keine Kopien der DARPA-Verträge aus den 1970er–1990er Jahren erhalten konnte, in deren Rahmen die IANA-Funktionen entwickelt und ausgeführt wurden, obwohl es Informationen über einen späteren Vertragsauftrag ab 1995 beschaffte. Diese Feststellung schränkt die Schlussfolgerungen zu den frühen DARPA-USC-Bedingungen ein.
Sie belegt nicht, dass die separate DCA-SRI-Vertragsakte fehlt. Die beiden Auftragnehmer, die Regierungsbeziehungen und die Funktionen müssen getrennt bleiben. Die SRI-Sammlung kartiert Vertragsmaterialien, die Fragen zur NIC-Leistung beantworten können. Das Fehlen von Beweisen des GAO betrifft die historischen DARPA-USC/IANA-Verträge.
Ein Vertragsbeauftragter konnte die Verpflichtungen durchsetzen, die ein anwendbarer Vertrag tatsächlich enthielt. Diese Befugnis würde normalerweise das vertragliche Interesse der Regierung schützen. Ein Antragsteller bräuchte dennoch einen Weg, durch den ein Registrierungsproblem zu einem Vertragsleistungsproblem würde. Ohne die Klausel, die Beschwerde, die Regierungsmaßnahme und das Ergebnis bleibt die „Prüfung durch den Vertragsbeauftragten“ ein möglicher Kontrollmechanismus und kein dokumentiertes Rechtsmittel.
Sechs verschiedene später als Berufung bezeichnete Dinge
Institutionsgeschichten verwenden „Berufung“ oft für jedes Ereignis, bei dem auf ein anfängliches Problem ein besseres Ergebnis folgt. Dieses Vokabular verschleiert, wer gehandelt hat und was sich geändert hat.
Korrekturrepariert Daten oder das Formular. Die Benutzerregistrierungsanweisungen von 1983 dokumentierten direkt Korrektur, Hinzufügung, Löschung, Duplikatfilterung und Wiedereinreichung. RFC 1032 dokumentierte Domain-Datenaktualisierungen und iterativen Schriftverkehr. Korrektur kann ohne eine bestrittene Entscheidung erfolgen.
Informelle Neubewertungtritt ein, wenn derselbe Mitarbeiter oder dasselbe Büro eine frühere Ansicht noch einmal überprüft. Eine telefonische Erklärung, neue technische Beweise oder die Klärung der organisatorischen Autorität konnten eine Neubewertung auslösen. Die dichte Kontaktinfrastruktur der Zeit macht dies plausibel, aber die Stichprobe enthält keinen vollständigen Antragstellerfall, der dies zeigt.
Eskalation des Sponsorsverlagert das Problem auf eine Organisation, die Autorisierung, Finanzierung oder Konnektivitätsgenehmigung bereitstellt. Der Sponsor kann die Berechtigung klären, bei einer anderen Institution Fürsprache einlegen oder seine eigene Position ändern. Das Ergebnis kann den Zugang beeinflussen, ohne die Entscheidung des Registers aufzuheben.
Beschwerdemeldet einen Serviceausfall, eine Verzögerung, eine Inkonsistenz oder ein Verhalten des Personals. Das Kontaktblatt von 1985 trennte Managementprobleme von Routine-Servicekanälen und zeigte, dass ein breiteres Anliegen einen Ort hatte, an den es gehen konnte. Es besagte nicht, dass eine Beschwerde einen Kennungsantrag wiedereröffnete.
Veröffentlichte Berufungist ein regelbasierter Weg, auf dem eine betroffene Partei eine Entscheidung vor einem benannten Prüfer anfechten kann. Sie identifiziert normalerweise die anfechtbare Entscheidung, wohin die Anfechtung geht und wer die Antwort ausstellt. Die hier geprüfte Verfahrensstichprobe identifiziert keine solche allgemeine veröffentlichte Berufung für erfolglose Domain- und digitale Kennungsanträge von 1983–1992.
Durchsetzbarer Rechtsbehelfstammt von einer Behörde, die nach Gesetz, Vertrag oder verbindlichen Programmregeln zu einer Handlung zwingen kann. Ein Gericht, eine Behörde oder ein Vertragsbeamter konnte einen solchen Rechtsbehelf gewähren, wenn Zuständigkeit, ein rechtliches Interesse und eine anwendbare Verpflichtung bestanden. Die Registrierungshandbücher versprachen dies nicht, und die Stichprobe enthält kein qualifiziertes Urteil oder keine Behördenanordnung, die ein NIC- oder IANA-Kennungsergebnis während des Zeitraums aufhebt.
Diese Kategorien können sich in einer faktischen Abfolge überschneiden. Ein Antragsteller konnte ein Formular korrigieren, das Hostmaster-Personal um Neubewertung bitten, einen Sponsor einschalten, sich bei der Leitung beschweren und schließlich einen externen Rechtsanspruch verfolgen. Die Etiketten sollten den Beweisen in jedem Schritt folgen, anstatt die gesamte Sequenz als „Berufung“ zu behandeln.
Das Telefon als praktisches Rechtsmittel und archivarisches Blindauge
Die stärkste wohlwollende Alternative beginnt mit der Erreichbarkeit des NIC.
Das NIC veröffentlichte elektronische Kanäle und betrieb eine Telefonhilfe. RFC 1032 erwartete Korrespondenz vor der Domain-Genehmigung. Das Merkblatt „How to Reach the NIC“ von 1985 leitete verschiedene Themen an verschiedene Rollen weiter, einschließlich Hilfe, Registrierung, Host-Änderungen, Betrieb und Management. Das Findmittel beschreibt einen Referenz- und Hotline-Betrieb, der telefonische und E-Mail-Anfragen beantwortete und in monatlichen Berichten Aktivitätsstatistiken meldete.
Eine kleine, technisch verbundene Gemeinschaft konnte viele Probleme gesprächsweise lösen. Ein Antragsteller konnte anrufen, erfahren, dass ein Server nicht bereit war, die Konfiguration korrigieren und erneut einreichen. Ein Host-Administrator konnte die Autorisierung klären. Ein Diensteanbieter konnte die Anforderungen an die Adressklasse erklären. Ein Sponsor konnte bestätigen, dass ein Netzwerk unter eine finanzierte Aktivität fiel.
Aus Sicht des Antragstellers konnte ein solcher Anruf nützlicher sein als ein formelles Verfahren. Geschwindigkeit, Kontext und Vertrauen können die informelle Verwaltung sehr effektiv machen.
Aus der Sicht des Historikers ist derselbe Anruf eine fehlende Transition. Das eingehende Formular kann überleben. Die endgültige Zuweisung kann überleben. Die Erklärung, die sie verband, kann nicht überleben. Wenn keine Fallnotiz gemacht wurde, kann ein Forscher nicht feststellen, ob das Ergebnis auf einen routinemäßigen Ratschlag, eine Neubewertung, eine Schirmherrschaft oder einen neuen Antrag folgte.
Telefonaufzeichnungen erfordern, wenn sie überleben, eine sorgfältige Interpretation. Ein Anrufprotokoll kann das Datum, das allgemeine Thema, die Klasse des Anrufers und identifizieren, ob eine Nachverfolgung erforderlich war. Es kann dennoch den Antrag, den Rat, die Autorität und das Endergebnis auslassen. Anrufzahlen können nicht zu Berufungszahlen werden, ohne eine Fallverknüpfung.
E-Mail bietet mehr Details, aber keine Garantie für Vollständigkeit. Nachrichten können getrennt vom Antrag abgelegt werden. Die Teilnehmer können zum Telefon wechseln. Eine Antwort kann ohne die Frage überleben oder umgekehrt. Ein Thread kann die Verhandlung dokumentieren, während die endgültige Entscheidung nicht erklärt bleibt.
Dieses Aufbewahrungsproblem schneidet in beide Richtungen. Es blockiert eine Behauptung, dass eine Überprüfung nie stattgefunden hat. Es blockiert auch eine Behauptung, dass die informelle Überprüfung konsistent funktioniert hat. Die Kontaktinfrastruktur ist beobachtbar; die Qualität der Lösung nicht.
Wer hatte Zugang zu einer praktischen Neubewertung?
Die institutionelle Karte deutet auf eine Verteilungsfrage hin, nicht auf eine Verteilungsfeststellung.
Ein militärisches Netzwerk konnte einen Host-Administrator, einen Verbindungsoffizier, eine Programm-Management-Beziehung und einen Regierungssponsor haben. Ein Bundesauftragnehmer konnte ein ungelöstes Netzwerkproblem über einen technischen Vertreter oder eine Vertragskette ansprechen. Eine finanzierte Universität konnte sich auf Campus-Administratoren, einen Forschungssponsor und bis 1992 auf ein Intermediate Network oder einen Diensteanbieter stützen.
Ein kommerzieller oder internationaler Antragsteller konnte ebenfalls sachkundige Vermittler und direkte berufliche Beziehungen haben. RFC 1174 erkannte ausdrücklich an, dass sich das Internet über seine ursprüngliche föderale und geförderte Forschungspopulation hinaus ausgeweitet hatte. Einige internationale Netzwerke waren tief in Forschungskooperationen eingebunden. Die institutionelle Kategorie allein kann den Zugang nicht bestimmen.
Die Annahme ist, dass eine praktische Neubewertung teilweise von Beziehungen abhängen konnte: den richtigen Administrator zu kennen, einen Sponsor zu haben, der Fragen stellen konnte, oder über einen Anbieter zu arbeiten, der mit dem Registerverfahren vertraut war. Diese Annahme ist plausibel, da die dokumentierten Kanäle rollenbasiert und hierarchisch waren.
Sie wird nicht getestet. Die Stichprobe enthält keinen Antragsnanner, der auf militärische, staatliche, akademische, kommerzielle und internationale Antragsteller verteilt ist. Es gibt keine vergleichbaren Messungen der Vollständigkeit, der verstrichenen Zeit, der gestellten Fragen, der Einbeziehung des Sponsors oder des Endergebnisses.
Vertrauenswürdige Vermittler könnten Ungleichheiten verringert haben, indem sie weniger erfahrenen Antragstellern halfen, genaue Anträge einzureichen. Sie könnten den Rechtsbehelf auch beziehungsabhängig gemacht haben, was bereits mit dem Verwaltungsnetzwerk verbundenen Institutionen zugute kam. Beide Effekte konnten gleichzeitig wirken.
Ein verteidigbarer Vergleich würde Daten auf Antragsebene und Kontrollen für technische Bereitschaft, angeforderte Ressource, Sponsoring-Anforderungen und Antragsvollständigkeit erfordern. Ohne diese Beweise sollten weder gleiche noch ungleiche Behandlung als Ergebnis berichtet werden.
Gerichte und Behörden außerhalb der technischen Hierarchie
Ein Gericht ist kein Berufungsamt für jede administrative Unannehmlichkeit. Es handelt, wo das Gesetz die Zuständigkeit begründet, wo ein Antragsteller ein anerkennenswertes Interesse hat und wo ein geeigneter Beklagter zur Gewährung von Abhilfe gezwungen werden kann.
Ein früher Domain-Streit konnte die organisatorische Autorität, den Vertrag, die Marke oder ein anderes rechtliches Interesse betreffen. Ein Bundesauftragnehmer konnte Rechte aus seiner eigenen Vereinbarung haben. Die Handlung eines Regierungssponsors konnte einem separaten Gesetz oder einer Programmregel unterliegen. Diese Möglichkeiten hingen von Fakten ab, die über das Kennungsformular hinausgingen.
Die technischen Leitfäden der Zeit erklärten nicht, dass ein erfolgloser Antragsteller ein Gericht anrufen konnte, um das technische Urteil des Hostmasters zu überprüfen. Sie legten auch nicht fest, dass jede Handlung des NIC oder der IANA eine endgültige Behördenhandlung war. Der Auftragnehmerstatus, die delegierte technische Autorität, die bundesstaatliche Schirmherrschaft und die Regierungsfinanzierung fallen nicht in eine einzige Kategorie des öffentlichen Rechts.
Behördliche Kanäle erfordern die gleiche Sorgfalt. Die DCA, DARPA, das DDN-PMO oder eine andere Bundesbehörde konnten Beschwerden im Rahmen ihrer Programm- oder Vertragsverantwortung erhalten. Ob sie über den Anspruch eines Antragstellers entscheiden, einen Auftragnehmer zur Änderung eines Eintrags zwingen oder einen durchsetzbaren Rechtsbehelf bieten musste, hing von der maßgeblichen Autorität ab.
Keine direkte Aufzeichnung von 1983–1992 in dieser Stichprobe verbindet eine Kennungsablehnung mit einem Gerichtsurteil, einer Behördenanordnung oder einer Vertragsentscheidung, die sie aufhob. Der externe Rechtsbehelf bleibt rechtlich im Abstrakten möglich und historisch in der relevanten Fallpopulation unbewiesen.
Kontrafaktisch A: Aufbewahrung von Entscheidungen, Hinzufügung von Gründen
Stellen Sie sich vor, jede inhaltliche Kennungs- und Verbindungsentscheidung von 1983–1992 bleibt unverändert. Dieselben vollständigen Anträge hatten Erfolg. Dieselben technischen Mängel erforderten eine Korrektur. Dieselben Sponsorenregeln regelten den Zugang zur bundesstaatlich unterstützten Infrastruktur.
Ändern Sie nur die Akte. Geben Sie jedem einzelnen Antrag ein Eingangsdatum und eine dauerhafte Kennung. Wenn die Bearbeitung endet, bewahren Sie einen kurzen Grund und das verantwortliche Büro auf. Wenn dasselbe Büro eine Neubewertung vornimmt, verknüpfen Sie die zweite Entscheidung mit der ersten. Wenn der Fall an einen Sponsor, die IANA, die Leitung oder eine andere Behörde übergeben wird, erfassen Sie die Verweisung und das Endergebnis.
Diese Akte würde die Überprüfbarkeit verbessern, selbst wenn sich die Genehmigungsraten nicht änderten. Forscher könnten ein fehlendes Feld von einer inhaltlichen Ablehnung unterscheiden. Wiederholte Anträge könnten als Korrekturen, Ersetzungen oder Neubewertungen identifiziert werden. Die verstrichene Zeit könnte in Antworterwartung, Personalbearbeitung, Sponsorenprüfung und ungelöste Intervalle aufgeteilt werden. Politikänderungen könnten mit den Falltypen verknüpft werden, die ein Problem offenbarten.
Die zusätzliche Akte könnte die Fehlererkennung verbessern. Vergleichbare Gründe könnten inkonsistente Klassifizierungen aufdecken, oder sie könnten zeigen, dass scheinbar unterschiedliche Ergebnisse auf unterschiedlichen Fakten beruhten. Das ist eine Möglichkeit, kein gemessener historischer Effekt.
Es wird nicht behauptet, dass moderne verwaltungsrechtliche Pflichten bereits jede frühe Internet-Registrierung regelten. Das Kontrafaktisch stellt eine engere institutionelle Frage: Welche Beweise hätten es Zeitgenossen und späteren Historikern ermöglicht, die Konsistenz zu testen, ohne die zugrunde liegende Autoritätsstruktur zu ändern?
Ein Journal datierter Gründe und Ergebnisse würde nicht an sich Unabhängigkeit schaffen. Der Prüfer könnte immer noch demselben Büro angehören. Es würde auch keine Fairness garantieren. Es würde den Weg sichtbar genug machen, um bewertet zu werden.
Kontrafaktisch B: Wirklich geringer Konflikt
Nehmen Sie nun an, die erstinstanzliche Verwaltung war im Allgemeinen korrekt. Die Antragsteller waren technisch versiert, die Anforderungen waren weitgehend bekannt und die meisten Probleme wurden durch vertrauensvolle Korrespondenz gelöst. Inhaltliche Ablehnungen und ernsthafte Streitigkeiten waren selten.
Welche Spuren würde dieses gutartige System hinterlassen?
Die meisten unvollständigen Anträge würden von identifizierbaren Rückfragen und schnellen Korrekturen gefolgt. Wiederholte Einreichungen würden gewöhnlich sichtbaren technischen oder administrativen Änderungen entsprechen. Die Zeit nach Fertigstellung wäre kurz oder durch Servervorbereitung, Schirmherrschaft oder eine andere externe Abhängigkeit erklärt. Kontakte zu Sponsoren würden die Berechtigung klären, häufiger als sie frühere Urteile ersetzten. Beschwerdespuren wären im Vergleich zu einer bekannten Antragspopulation selten.
Zurückgezogene Anträge würden Erklärungen auf Seiten des Antragstellers erfordern, um von stillschweigenden Ablehnungen getrennt zu werden. Telefonische Lösungen würden zeitgenössische Notizen erfordern, die den Anruf mit dem Antrag verknüpfen. Eine statistisch vertretbare Stichprobe sollte nach Kontrolle von Vollständigkeit und technischer Bereitschaft wenige ungelöste Meinungsverschiedenheiten zeigen.
Teile der gutartigen Infrastruktur sind sichtbar. RFC 1032 erwartete Korrespondenz. Das NIC unterhielt Hilfe- und Managementkanäle. Host-Administratoren konnten Benutzerakten korrigieren. Das DDN-PMO erklärte, dass es bei Problemen mit den Administratoren zusammenarbeiten würde. RFC 1359 behandelte Anbieter als Quellen für Antragsberatung. RFC 1174 beschrieb eine Politik, eindeutige Nummern weitgehend zuzuweisen, während die Konnektivitätsgenehmigung getrennt wurde.
Was unbeobachtet bleibt, ist die Leistung dieser Kanäle. Die Anzahl der Einzelanträge ist unbekannt. Ebenso die Anzahl der zur Nachfrage zurückgesandten, zurückgezogenen, abgelehnten, überdachten, eskalierten und annullierten Anträge. Es gibt keinen Vergleich der Antragstellerklassen oder der Endergebnisse.
Ein System, in dem enttäuschte Antragsteller verschwanden, könnte dieselbe veröffentlichte Zuweisungsliste hervorbringen wie ein System mit fast keinen ernsthaften Konflikten. Der unterscheidende Beweis liegt in der Antragskorrespondenz und den Verfügungsakten, nicht in der Sauberkeit des Registers.
Ein enger Blick über 1992 hinaus
RFC 1400, veröffentlicht im März 1993, bietet einen begrenzten Vergleich nach dem Zeitraum. Sie beschrieb die Analyse und Verifizierung von Registrierungsvorlagen, die Korrektur durch den ursprünglichen Antragsteller, den Ablauf nach einem siebentägigen Antwortfenster, Ticketnummern und öffentliche Statusinformationen, die anzeigen, ob ein Ticket noch aussteht und wer es bearbeitet.
Diese Merkmale machten Bearbeitungszustände beobachtbarer. Sie schufen kein unabhängiges Berufungsgremium. Analysefehler, Verifizierung, Korrektur und endgültige Bearbeitung durch das Personal blieben Teile der Verwaltung, keine Überprüfungen durch eine separate Autorität.
Der Vergleich stützt nur diese Schlussfolgerung: Ein öffentliches Verfahren konnte eine Antragskennung und einen Zwischenstatus offenlegen. Ihr Erscheinen im Jahr 1993 beweist nicht, dass eine frühere interne Nachverfolgung fehlte, und sie beantwortet nicht, wie inhaltliche Streitigkeiten geprüft wurden.
Was geschlussfolgert werden kann
Drei Aussagen müssen getrennt bleiben.
Erstens identifizierten die hier geprüften veröffentlichten Verfahren kein allgemeines, unabhängiges Berufungsamt für erfolglose Domain- oder digitale Kennungsanträge während 1983–1992. Sie spezifizierten Anträge, verantwortliche Verwalter, technische Anforderungen, Korrektur, Korrespondenz, Grenzen lokaler Streitigkeiten und institutionelle Autorität. Sie begründeten keinen allgemeinen Weg für Antragsteller zu einem benannten Prüfer zweiter Instanz und einer aufgezeichneten endgültigen Entscheidung.
Zweitens war die informelle Lösung institutionell möglich und, für gewöhnliche Probleme, plausibel. Das NIC war erreichbar. Das Personal erwartete Korrespondenz. Administratoren und Sponsoren hatten definierte Rollen. Anbieter konnten Antragsteller beraten. Die Leitung und Regierungsstellen konnten im Rahmen ihrer Verantwortlichkeiten Bedenken entgegennehmen. Diese Kanäle mögen viele Fälle schnell gelöst haben, aber die Stichprobe misst weder ihre Nutzung noch ihre Ergebnisse.
Drittens bleibt der Nenner unbekannt. Die Stichprobe enthält kein Korpus auf Antragsebene, aus dem unvollständige, verzögerte, zurückgezogene, abgelehnte, korrigierte, überdachte, eskalierte, annullierte oder endgültige Fälle gezählt werden können. Sie enthält keine qualifizierte Ablehnungs- und Annullierungsakte. Das Fehlen von Beweisen verhindert sowohl einen Vorwurf systematischen Missbrauchs als auch eine Behauptung nachgewiesener Konsistenz.
Die frühen Internet-Administratoren lösten ein schwieriges Koordinationsproblem über schnell wechselnde technische und institutionelle Grenzen hinweg. Ein System konnte kompetent, kooperativ sein und dennoch schwache Verfahrensarchive hinterlassen. Es konnte Fehler korrigieren, ohne den Akt der Neubewertung zu benennen. Es konnte die Politik ändern, ohne individuelle Berufungen anzuhören. Es konnte wirksame Hilfe leisten, während es diese Hilfe durch Beziehungen verteilte, die spätere Historiker nicht bewerten können.
Das fehlende Berufungsamt ist daher nicht der Beweis dafür, dass ein bestimmtes Amt hätte existieren sollen, aber nicht existierte. Es ist die fehlende Kette von Gründen, Prüfern und Ergebnissen, die notwendig ist, um zu bestimmen, was geschah, nachdem der normale Weg gescheitert war.
Ein geringer sichtbarer Konflikt kann gute Verwaltung widerspiegeln. Er kann private Lösung widerspiegeln. Er kann Antragsteller widerspiegeln, die aus der überlebenden Akte verschwunden sind. Bis direkte Antragsakten den Nenner liefern, müssen diese Erklärungen getrennt bleiben.
Quellen
- RFC 810, „DoD Internet Host Table Specification“, 1. März 1982:https://www.rfc-editor.org/rfc/rfc810.html
- RFC 920, „Domain Requirements“, Oktober 1984:https://www.rfc-editor.org/rfc/rfc920.html
- RFC 1032, „Domain Administrators Guide“, November 1987:https://www.rfc-editor.org/rfc/rfc1032.html
- RFC 1062, „Internet Numbers“, August 1988:https://www.rfc-editor.org/rfc/rfc1062.html
- RFC 1174, „IAB Recommended Policy on Distributing Internet Identifier Assignment and IAB Recommended Policy Change to Internet 'Connected' Status“, August 1990:https://www.rfc-editor.org/rfc/rfc1174.html
- RFC 1359, „Connecting to the Internet“, August 1992:https://www.rfc-editor.org/rfc/rfc1359.html
- RFC 1400, „Transition and Modernization of the Internet Registration Service“, März 1993:https://www.rfc-editor.org/rfc/rfc1400.html
- Network Information Center, „Instructions for Network User Registration Drive“, 20. Oktober 1983, interne Seiten 1–7, Seiten 67–73 der digitalisierten Charge inDefense Communication Agency Materials; 6 of 13:https://archive.computerhistory.org/resources/access/text/2023/07/102707743-05-06-acc.pdf
- DDN Network Information Center, „How to Reach the NIC“,NIC KNACKS, Ausgabe 2, 17. Mai 1985, Seite 94 der digitalisierten Charge inDefense Communications Agency Materials; 3 of 13:https://archive.computerhistory.org/resources/access/text/2023/07/102707743-05-03-acc.pdf
- Computer History Museum,Guide to the SRI ARC/NIC Records, Sammlung X3578.2006, 2011:https://archive.computerhistory.org/resources/access/text/finding-aids/102706170-SRI/102706170-SRI.pdf
- James Pelkey, Interview mit Jonathan „Jon“ Postel, aufgezeichnet am 18. Februar 1988:https://archive.computerhistory.org/resources/access/text/2016/05/102738139-05-01-acc.pdf
- US Government Accountability Office, B-327398, „Department of Commerce—Property Implications of Proposed Transition of U.S. Government Oversight of Key Internet Technical Functions“:https://www.gao.gov/products/b-327398

