Die fehlende Berufungsinstanz des frühen Internets

Zusammenfassung

• Veröffentlichte Anleitungen aus den Jahren 1983–1992 beschrieben Formulare, technische Anforderungen, zuständige Administratoren, Korrekturwege und Kontaktkanäle. In der hier untersuchten dokumentarischen Stichprobe richteten sie keine allgemeine, unabhängige Berufungsinstanz für einen erfolglosen Antrag auf eine Domain oder numerische Kennung ein.
• Listen registrierter Benutzer, Domains und zugewiesener Netzwerknummern enthalten abgeschlossene oder aktuelle Datensätze. Sie zeigen nicht die Gesamtzahl eingereichter, unvollständiger, verzögerter, zurückgezogener, abgelehnter, korrigierter, erneut geprüfter, eskalierter, aufgehobener oder anderweitig abgeschlossener Anträge.
• NIC-Korrespondenz, telefonische Unterstützung, die Verwaltung übergeordneter Domains, staatliche Förderung, die IANA-Autorität und die Bundesaufsicht hätten helfen können, bestimmte Probleme zu lösen. Die Stichprobe enthält keinen auf Antragsebene nachgewiesenen Fall, in dem einer dieser Wege als Antragstellerberufung mit einem begründeten und dokumentierten Ergebnis funktionierte.
• Die Autoritätskarte ist daher uneinheitlich: NIC-Mitarbeiter konnten Datensätze bearbeiten und korrigieren; Host- und Domain-Administratoren konnten lokale Einreichungen autorisieren oder überarbeiten; Sponsoren konnten die Konnektivität beeinflussen; das IAB konnte Richtlinien empfehlen; und die IANA besaß und delegierte die Autorität zur Zuweisung numerischer Kennungen. Individuelle Berufungsgerichtsbarkeit und Umkehrungspflichten bleiben unbelegt.
• Geringe dokumentierte Konflikte sind sowohl mit wohlwollenden als auch mit skeptischen Deutungen vereinbar. Probleme könnten meist genau durch vertrauensvolle Beziehungen gelöst worden sein, oder erfolglose Antragsteller könnten aus Aufzeichnungen verschwunden sein, die eher auf die Bewahrung von Zuweisungen als auf Verfahrensgeschichten optimiert waren. Die verfügbare Grundgesamtheit kann nicht zwischen diesen beiden Deutungen unterscheiden.

Der Nenner, der sich hinter jeder erfolgreichen Liste verbirgt

Eine veröffentlichte Tabelle von Netzwerknummern ist eine Aufzeichnung von Ankünften. Sie zeigt Kennungen, die in das offizielle Register aufgenommen wurden, und gelegentlich auch Einträge, die sich während eines Übergangs änderten. Eine Domain-Tabelle zeigt ebenfalls Namen, die die Registrierung abgeschlossen haben. Keine der beiden Tabellen erfasst jeden Versuch, der dem Ergebnis vorausging.

Das ist das Nenner-Problem. Eine institutionelle Geschichte der frühen Internetverwaltung muss Anträge zählen und nicht Zuweisungen. Die relevante Grundgesamtheit würde Erstanträge, Duplikate, technisch fehlerhafte Formulare, zur Klärung zurückgesandte Anträge, Rücknahmen, Korrekturen, Verzögerungen, substanzielle Ablehnungen, erneute Anträge, Interventionen von Sponsoren, erneute Prüfungen, Eskalationen, Aufhebungen und Fälle umfassen, die ohne dokumentierten Abschluss endeten. Ein Register, das zur Bewahrung eindeutiger Kennungen aufgebaut ist, liefert nur eine Teilmenge dieser Grundgesamtheit.

Der normale Weg ist weitaus einfacher zu rekonstruieren.

Als unmittelbare Vorperiodenbasis verlangteRFC 810vom 1. März 1982, dass Namen und Adressen für Netzwerke, Gateways und Hosts des Department of Defense vor der Nutzung und bevor ein DoD-Host Datenverkehr weiterleitete, mit dem Network Information Center ausgehandelt und registriert werden mussten. Er nannte elektronische und telefonische Kontaktwege. Für eine Übergangszeit würde das NIC auch versuchen, vergleichbare, von nicht-DoD-Netzwerken und -Hosts gelieferte Informationen zu pflegen. Die Anweisung legte fest, wo die Registrierung stattfand. Sie beschrieb weder ein Antragsbuch noch einen Weg, um eine nachteilige Entscheidung anzufechten.

RFC 920, veröffentlicht im Oktober 1984, legte die Anforderungen für die Einrichtung einer Domain fest. Eine Domain war eine administrative Einheit, nicht nur ein Label. Sie benötigte eine verantwortliche Person mit technischer Kompetenz und organisatorischer Autorität, einen zuverlässigen Nameservice und die Registrierung über die entsprechende Hierarchie. Eine untergeordnete Domain musste den Ansprüchen des ihr unmittelbar übergeordneten Administrators genügen. Das Dokument enthielt einen Fragebogen für die vorgeschlagene Domain, Kontakte, Serverkonfiguration, erwartete Größe und administrative Struktur.

RFC 1032, der Domain-Administratoren-Leitfaden vom November 1987, machte das Arbeitsverfahren expliziter. Ein Administrator besorgte sich 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 sah mehrere Austausche elektronischer Korrespondenz vor der Autorisierung vor. 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, eine administrative Stelle und einen Hilfskanal gab. Sie zeigen nicht, wie viele Anträge in jeder Phase stecken blieben. Ein endgültiger Domain-Eintrag konnte aus einer vollständigen Ersteinreichung, einer routinemäßigen Klärung, wiederholten technischen Korrekturen, einer Intervention eines übergeordneten Domain-Administrators oder der Ersetzung eines früheren Vorschlags hervorgegangen sein. Sobald die Domain im Register erschien, liefen diese Geschichten im gleichen sichtbaren Ergebnis zusammen.

Das gleiche Problem betrifft Veröffentlichungen von Netzwerknummern.RFC 1062, veröffentlicht im August 1988, listete zugewiesene Netzwerknummern auf und unterschied zwischen Forschungs-, Verteidigungs-, nicht-verteidigungsbezogenen Regierungs- und kommerziellen Nutzern. Er markierte auch einige geänderte Nummern für die Übergangsverwendung. 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 Beleg für einen abgelehnten Antragsteller. Eine registrierte Nummer ist kein Beweis dafür, dass der ursprüngliche Antrag vollständig war. Ein Änderungsvermerk offenbart nicht, ob die Änderung beantragt, auferlegt, bestritten oder lediglich technisch bedingt war. Die Tabelle erhält den Betriebszustand, nicht den Weg, auf dem dieser Zustand erreicht wurde.

Eine geringe sichtbare Konfliktlast kann daher zwei Geschichten stützen. Die wohlwollende Darstellung besagt, dass Administratoren und technisch versierte Antragsteller einander im Allgemeinen verstanden, Fehler durch Korrespondenz korrigierten und selten ernsthafte Streitigkeiten produzierten. Die skeptische Darstellung besagt, dass ein System, das um aktuelle Zuweisungen herum organisiert war, wenig betrieblichen Anlass hatte, gescheiterte Versuche, ungeschriebene Erklärungen oder enttäuschte Antragsteller zu bewahren. Beide Geschichten sagen eine saubere Liste erfolgreicher Registrierungen voraus.

Die überlieferten Listen können zwischen ihnen nicht unterscheiden.

Ein Zustandsautomat, keine angenommen-abgelehnt-Binärunterscheidung

Die minimale analytische Sequenz lautet:

submitted -> incomplete -> request for more information -> delayed -> refused -> corrected -> reconsidered -> escalated -> reversed or final

Diese Notation impliziert nicht, dass jeder Antrag jeden Zustand durchlief. Reale Pfade würden sich verzweigen. Ein unvollständiger Antrag könnte korrigiert und fortgesetzt werden. Ein vollständiger Antrag könnte zurückgezogen werden. Eine Ablehnung könnte ohne erneute Prüfung endgültig werden. Eine Eskalation könnte sich eher auf Sponsoring oder Konnektivität als auf die Kennungsentscheidung beziehen. Der Wert der Sequenz liegt darin, dass sie verhindert, dass unterschiedliche Verfahrensereignisse im Wort „abgelehnt“ zusammengeworfen werden.

Eingereichtbedeutet, dass eine identifizierbare Stelle einen Antrag erhalten hat. Der Nachweis sollte das eingehende Formular, die Nachricht oder das Schreiben umfassen, vorzugsweise mit einem Eingangsdatum und genügend Kontext, um festzustellen, welcher Dienst beantragt wurde. Eine spätere Registrierung beweist, dass irgendein Prozess erfolgreich war; sie belegt jedoch nicht das Datum oder den Inhalt der ersten Einreichung.

Unvollständigbeschreibt einen Bearbeitungszustand. Erforderliche Felder, verantwortliche Kontakte, Serverkonfigurationen oder Autorisierungen könnten fehlen. RFC 1032 verlangte einen ausgefüllten Fragebogen, bevor das NIC eine Domain autorisierte. Diese Regel dokumentiert die Kategorie, aber die Stichprobe enthält keine verknüpfte Antragsdatei, die einen namentlich genannten Antrag als unvollständig klassifiziert zeigt.

Aufforderung zur Nachlieferung von Informationenist ein affirmativer Verwaltungsakt. Die Erwartung mehrerer Korrespondenzaustausche in RFC 1032 zeigt, dass Klärung Teil der normalen Bearbeitung war. Ein konkreter Fall würde dennoch die ausgehende Frage, den zugrundeliegenden Antrag und jede Antwort erfordern. Eine zweite Einreichung allein kann nicht offenbaren, ob die erste eine Frage auslöste.

Verzögerterfordert Daten und einen weiterhin ungelösten Antrag. Der Zeitraum muss aufgeteilt werden in Personalbearbeitungszeit, Antwortzeit des Antragstellers, Sponsorprüfung, technische Vorbereitung und etwaige Richtlinienfragen. Eine Domain, die Monate nach der Diskussion eines ursprünglichen Plans registriert wurde, ist nicht automatisch ein verzögerter Antrag. Ohne dokumentierten Beginn, Unterbrechungen und Abschlussereignis bleibt eine Verzögerung unbewiesen.

Zurückgezogenbedeutet, dass der Antragsteller den Antrag beendet hat. Dieser Zustand benötigt eine Erklärung oder ein Verhalten, das dem Antragsteller zuverlässig zugeschrieben werden kann. Schweigen ist mehrdeutig: Der Antragsteller hat den Plan vielleicht aufgegeben, die Vermittler gewechselt, die Angelegenheit telefonisch geklärt oder nie eine Antwort erhalten.

Abgelehntist eine substanzielle nachteilige Entscheidung, nicht das Fehlen einer Zuweisung. Die direkte Aufzeichnung sollte die entscheidende Stelle, die anzuwendende Anforderung, den Grund und die Mitteilung des Ergebnisses identifizieren. Eine fehlerhafte Vorlage, eine unbeantwortete Frage, ein nicht zulässiger Verbindungsantrag und ein an die lokalen Parteien zurückverwiesener Domain-Streit sind unterschiedliche Ereignisse.

Korrigiertbedeutet, dass Daten, die beantragte Konfiguration oder unterstützende Informationen geändert wurden. Eine Korrektur impliziert nicht notwendigerweise Uneinigkeit. Es kann sich um gewöhnliche Qualitätskontrolle handeln. Die zeitgenössischen Dokumente belegen direkt Korrekturverfahren, auch wenn sie diese Verfahren nicht in Berufungen verwandeln.

Erneut geprüftbedeutet, dass die ursprüngliche Behörde oder Verwaltungseinheit eine bereits getroffene Entscheidung wieder aufgegriffen hat. Die fortgesetzte Bearbeitung, nachdem der Antragsteller fehlende Daten nachgereicht hat, mag ähnlich aussehen, ist aber nicht notwendigerweise eine erneute Prüfung einer nachteiligen Entscheidung. Ein Fallprotokoll müsste die frühere Position und die spätere erneute Überprüfung zeigen.

Eskaliertbedeutet, dass eine Angelegenheit an eine andere Behörde oder institutionelle Ebene weitergeleitet wurde. Ein Hostmaster könnte einen älteren Kollegen fragen; ein Antragsteller könnte sich an einen Sponsor wenden; Mitarbeiter des DDN-Programms könnten einbezogen werden; oder eine Richtlinienfrage könnte die IANA oder ein Bundesnetzwerkgremium erreichen. Das bloße Kopieren eines leitenden Beamten in der Korrespondenz beweist keine Eskalation, und eine Eskalation beweist keine Überprüfung.

Aufgehobenerfordert zwei unvereinbare Entscheidungen: ein identifizierbares früheres Ergebnis und ein späteres Ergebnis, das es änderte. Eine korrigierte Schreibweise, eine neue Serveradresse, eine Umnummerierung oder ein überarbeiteter Antrag ist keine Aufhebung, es sei denn, die Aufzeichnung stellt auch die Entscheidung fest, die umgestoßen wurde.

Endgültigist das gefährlichste Etikett. Ein veröffentlichtes Verfahren mag eine Entscheidung für endgültig erklären, oder eine vollständige Fallakte mag zeigen, dass die verfügbare Überprüfung endete. Die letzte erhaltene Nachricht beweist keine Endgültigkeit. Es könnte sich um den letzten erhaltenen Eintrag handeln, nicht um das letzte eingetretene Ereignis.

Der Beweisstatus in dieser Stichprobe ist daher asymmetrisch:

Diese Tabelle schätzt keine Häufigkeiten. Sie hält die Beweislage jedes Zustands in einer Stichprobe veröffentlichter Verfahren fest. Keine Ablehnung, Verzögerung, Eskalation, Aufhebung oder endgültige Erledigung wird als historischer Fall geliefert, weil die erforderlichen direkten Aufzeichnungen nicht festgestellt wurden.

Die dokumentarische Stichprobe und was sie ausschließt

Der interessierende Zeitraum ist 1983–1992. RFC 810 wird nur als Ausgangsbasis vom März 1982 für die überkommene Host-Registrierungsregel verwendet. RFC 1400, veröffentlicht 1993, erscheint nur als kurzer Vergleich, der zeigt, wie explizite Sichtbarkeit des Antragszustands später in ein öffentliches Verfahren Eingang fand.

Die Stichprobe ist eineStichprobe veröffentlichter Verfahren und institutioneller Autoritäten, kein Korpus individueller Anträge. Ihre Einheit ist ein Dokument oder ein öffentliches dokumentarisches Artefakt. Sie besteht aus:

• RFC 920, RFC 1032, RFC 1062, RFC 1174 und RFC 1359;
• dem NIC-Dokument „Instructions for Network User Registration Drive“ vom 20. Oktober 1983, erhalten auf den digitalisierten Bündelseiten 67–73 derDefense Communication Agency Materials; 6 of 13des Computer History Museum;
• „How to Reach the NIC“,NIC KNACKS, Nummer 2, 17. Mai 1985, erhalten auf der digitalisierten Bündelseite 94 derDefense Communications Agency Materials; 3 of 13;
• demGuide to the SRI ARC/NIC Recordsdes Computer History Museum von 2011, Sammlung X3578.2006;
• James Pelkeys Interview mit Jon Postel, aufgezeichnet am 18. Februar 1988;
• und der späteren Rechtsgeschichte des US Government Accountability Office zu Bundesverträgen in Bezug auf DNS und die IANA-Funktionen.

Dokumente wurden aufgenommen, wenn sie eine Antragsanforderung, einen administrativen Kanal, ein Korrekturverfahren, eine Zuweisungsautorität, eine Sponsoring-Unterscheidung, eine Richtlinienempfehlung oder ein Überwachungsverhältnis beschrieben, das für den Zeitraum 1983–1992 relevant ist. RFC 1062 wird als Artefakt veröffentlichter Ergebnisse und nicht als Antragshandbuch einbezogen. Das Findbuch dient der Definition der Archivlandschaft und nicht als Ersatz für die Unterlagen innerhalb der Sammlung. Das Postel-Interview liefert begrenzten Kontext zur Dokumentationskultur, keine Beweise für Kennungsfälle.

Die GAO-Stellungnahme ist spätere Rechtsgeschichte und beschränkt sich auf die Vertragsketten, die sie tatsächlich untersuchte.

Mehrere Beweiskörper liegen außerhalb dieser Stichprobe. Es handelt sich nicht um eine kistenweise Untersuchung der 281 Kisten umfassenden SRI ARC/NIC-Sammlung. Sie erhebt nicht den Anspruch, jeden Domain-Antrag, jede Host-Tabellen-Aktualisierung, jede Nummernanfrage, jedes Hotline-Protokoll, jeden monatlichen Bericht, jedes Sponsorenschreiben oder jede interne Nachricht geprüft zu haben. Sie behandelt die Beschreibungen des Findbuchs nicht als Beweis für das Ergebnis eines Antrags. Sie enthält keine statistisch erhobenen Antragsdateien.

Die Stichprobe schließt auch Rückschlüsse aus aktuellen Registerdaten aus. Ein späterer WHOIS-Eintrag oder eine überlebende Delegation kann einen frühen Antrag ohne zeitgenössische Korrespondenz nicht rekonstruieren. Mündliche Erinnerungen werden nicht als Antrag gezählt, es sei denn, sie sind mit direkten Aufzeichnungen abgeglichen. Zuweisungszeilen sind Ergebnisse, keine Antragseinheiten.

DasSRI ARC/NIC-Findbuchbeschreibt 351 laufende Fuß in 281 Kisten, wobei der Großteil des Materials aus den Jahren 1968–1990 stammt. Relevante Serien umfassen NIC-Vorschläge und -Verträge, formale Monatsberichte, Vertragsergebnisse, Referenz- und Hotline-Operationen, Benennung und Adressierung, TAC-Benutzerzugangsregistrierung, Verwaltung von Netzwerkkontakten sowie sonstige E-Mails und Korrespondenz.

Der Leitfaden besagt, dass die Sammlung einen vollständigen Satz formaler NIC-Monatsberichte enthält. Er sagt nicht, dass diese Berichte einen eindeutigen Antragsnenner enthalten. Monatliche Summen für Anrufe, Nachrichten, Aktualisierungen oder Registrierungen müssten noch mit einzelnen Anträgen verknüpft werden. Zehn Nachrichten könnten zehn Antragsteller oder zehn Austausche bezüglich eines Antragstellers repräsentieren. Ein Hotline-Anruf könnte Dokumentenzugriff, ein Anmeldeproblem, eine Host-Aktualisierung oder einen Kennungsantrag betreffen. Aggregierte Aktivität ist keine Erledigungsserie.

Der Leitfaden kartiert auch sonstige Korrespondenz bis 1989. Da die Korrespondenz aus verschiedenen Quellen zusammengetragen wurde und viele Themen abdeckt, kann ihre Existenz keine Vollständigkeit belegen. Ein Antrag könnte von seiner Antwort getrennt sein. Telefongespräche könnten ohne überlebende Notiz geblieben sein. Aufzeichnungen könnten nach Mitarbeiter, Datum oder Dienst und nicht nach Antragsteller organisiert sein. Eine physische Archivdurchsicht könnte Ausnahmefälle aufdecken, aber dieser Artikel erhebt keine Inzidenzbehauptung, bevor diese Arbeit geleistet ist.

Eine valide Untersuchung auf Antragsebene bräuchte eine explizite Einschlussregel: zum Beispiel alle Erstanträge auf Second-Level-Domains, die in einem festen Quartal eingingen, ob erfolgreich oder nicht. Der eindeutige Antrag, nicht die Nachricht, wäre die Zähleinheit. Duplikate, umbenannte Vorschläge, Wiedereinreichungen, übertragene Fälle und Anträge über zwischengeschaltete Registrierungen bräuchten eine vorab festgelegte Behandlung. Jeder Zustand bräuchte ein Datum und ein dokumentarisches Kriterium. Fehlende Nachrichten und Telefonkontakte bräuchten einen Erhaltungscode. Nichts in der vorliegenden Stichprobe stützt solche Zählungen.

Der Nenner ist daher undefiniert. Es gibt keine berichtete Genehmigungsrate, Ablehnungsrate, Aufhebungsrate oder durchschnittliche Verzögerung. Es gibt auch keinen Zähler für individuelle Berufungen. Diese Grenze ist methodologisch und nicht rhetorisch: Keine noch so große Sicherheit in der Prosa kann Antragsdateien herstellen, die nicht untersucht wurden.

Drei administrative Grundgesamtheiten, die nicht zusammengeführt werden dürfen

Die erhaltenen Dokumente beschreiben verwandte, aber unterschiedliche Dienste. Ihre Kombination würde ein imaginäres gemeinsames Berufungssystem schaffen.

Die erste Grundgesamtheit ist dieNetzwerkbenutzerregistrierung und der TAC-Zugang. Die NIC-Anleitung „Instructions for Network User Registration Drive“ vom 20. Oktober 1983 betraf Einzelpersonen, die MILNET- und ARPANET-Hosts nutzten, und für eine Teilmenge den Zugang über MILNET Terminal Access Controller. Host-Administratoren erhielten Vorlagen für Benutzer, die ihren Hosts zugeordnet waren, korrigierten vorhandene Daten, fügten berechtigte Benutzer hinzu, markierten Löschungen, überprüften die Ergebnisse und sandten das Material an das NIC zurück. Anträge auf TAC-Zugang erforderten die Autorisierung über das Postfach des Host-Administrators.

Dies war ein System der sponsor- und hostseitigen Autorisierung. Das DDN Program Management Office erklärte, dass von lokalen Hosts erwartet wurde, sich innerhalb der Regierungsrichtlinien selbst verantwortlich zu verwalten, und dass es bei Problemen mit Host-Administratoren zusammenarbeiten würde. Diese Sprache etabliert einen Problemkanal zwischen dem DDN-PMO und den Administratoren. Sie begründet kein Recht für eine Einzelperson, deren Host-Administrator die Autorisierung verweigerte.

Die zweite Grundgesamtheit ist dieDomain-Registrierung. RFC 920 und RFC 1032 verteilten Verantwortlichkeiten zwischen dem Antragsteller, dem verantwortlichen Domain-Administrator, der unmittelbar übergeordneten Autorität und dem NIC. Technische Bereitschaft, zuverlässige Server, kompetente Kontakte, organisatorische Klassifizierung und administrative Verantwortung spielten eine Rolle. Das NIC konnte die Vollständigkeit prüfen und technische Fragen beantworten. Übergeordnete Domain-Autoritäten übten ein hierarchisches Urteil über die Zulassung aus.

RFC 1032 zog eine bedeutende Zuständigkeitsgrenze. Er besagte, dass das NIC nicht als Schiedsrichter in Streitigkeiten darüber fungieren würde, wer das Recht habe, eine bestimmte Top- oder Second-Level-Domain für eine Organisation zu registrieren. Solche Konflikte wurden als private lokale Angelegenheiten behandelt, die vor Beginn der Registrierung zu klären waren. Das NIC-Personal konnte technische Anleitung geben, aber keine Schiedsgerichtsbarkeit.

Diese Grenze ist kein Beweis dafür, dass es keine Abhilfe gab. Sie verortete den Streit woanders: innerhalb einer Organisation, in der Hierarchie der übergeordneten Domain, durch vertragliche Beziehungen oder möglicherweise durch ein rechtliches Forum mit unabhängiger Gerichtsbarkeit. Dennoch benannte RFC 1032 kein Ersatztribunal und legte nicht fest, wer entschied, ob eine Meinungsverschiedenheit tatsächlich gelöst worden war.

Die dritte Grundgesamtheit ist dieZuweisung numerischer Kennungen. RFC 1062 veröffentlichte zugewiesene Netzwerknummern.RFC 1174, veröffentlicht im August 1990, beschrieb die IANA als die Organisation mit der primären Autorität zur Zuweisung und Vergabe numerischer Kennungen, wobei diese Funktion vom Information Sciences Institute der USC ausgeführt wurde. Er beschrieb das Internet Registry bei SRI als sammelnde und registrierende Stelle für Informationen über Netzwerke, die delegierte Zuweisungsarbeiten durchführte.

Die numerische Zuweisung muss auch von derKonnektivitätgetrennt werden. RFC 1062 erklärte, dass unabhängige Netzwerke, die Internetprotokolle verwendeten, 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 „verbundenen“ Status als Sanktion einer US-Regierungssponsororganisation, sich mit dem staatlich geförderten System zu verbinden.

Eine Organisation konnte daher eine eindeutige Nummer erhalten, während ihr die gewünschte Verbindung fehlte. Die Weigerung eines Sponsors, die Zusammenschaltung zu sanktionieren, war nicht notwendigerweise eine Weigerung des Internet Registry, eine Nummer zuzuweisen. Die möglichen Prüfer unterschieden sich ebenfalls. IANA und Internet Registry besetzten die numerische Zuweisungskette; eine Sponsoring-Agentur oder ein Backbone-Betreiber besetzten die Konnektivitätskette.

RFC 1359, veröffentlicht im August 1992, fügte eine weitere institutionelle Schicht für Campusnetze hinzu. Er riet Organisationen, mit einem IP-Dienstanbieter zusammenzuarbeiten, und beschrieb diesen Anbieter als Quelle für Beratung 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 Registerentscheidung Berufung einlegte.

Benutzerregistrierung, TAC-Zugang, Domain-Zulassung, numerische Zuweisung und Netzwerkverbindung hatten somit unterschiedliche Antragsteller, Regeln, Autoritäten und mögliche Abhilfen. Eine in einer Grundgesamtheit dokumentierte Korrektur kann keine Überprüfung in einer anderen beweisen.

Die direkte Ausnahmendokumentation: Korrektur und fortgesetzte Bearbeitung

Der stärkste Ausnahmenachweis in der Stichprobe betrifft Korrekturen.

Die „Instructions for Network User Registration Drive“ vom 20. Oktober 1983 legten eine konkrete Sequenz fest. Das NIC bereitete Vorlagen für Personen vor, die sich bereits in seiner Identifikationsdatenbank befanden. Host-Administratoren holten diese Vorlagen ab, ersetzten falsche Daten, fügten fehlende Benutzer hinzu, markierten Löschungen, überprüften und autorisierten die resultierenden Listen und sandten sie an den Registrar zurück. Das NIC bearbeitete die Einreichungen und trug sie in die WHOIS-Identifikationsdatenbank ein.

Das Dokument war streng hinsichtlich des Formats. Die Daten mussten in der vorgegebenen Vorlage zurückgesandt werden, damit sie mit weniger manuellem Aufwand verarbeitet werden konnten. Material in einer anderen Form würde nicht akzeptiert. Dies ist eine direkt dokumentierte Nichtannahmebedingung, die jedoch die Form der Benutzerregistrierungsdaten betrifft. Sie ist keine substanzielle Ablehnung eines IP-Adress- oder Domain-Antrags.

Die Anleitung behandelte auch Duplikate. Wenn mehr als ein Host-Administrator eine Vorlage für dieselbe Person einreichte, erklärte das NIC, dass es bereit sei, die Dopplung aufzulösen. Auch dies ist eine administrative Qualitätskontrolle. Die Quelle beschreibt keine Anhörung zwischen konkurrierenden Sponsoren oder eine Antragstellerberufung.

Der TAC-Zugang fügte eine separate Autorisierungsschicht hinzu. Das NIC behandelte einen Antrag als autorisiert, 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 Beschaffung eines unterschriebenen Papierformulars. Er erklärte einem Benutzer nicht, wie er den Host-Administrator anfechten konnte.

Die dokumentierte Sequenz ist daher:

existing data -> administrator review -> correction or addition -> authorization -> structured resubmission -> NIC processing

Jeder Pfeil hat eine angegebene administrative Funktion. Keiner ist eine unabhängige Überprüfung einer vorherigen substanziellen Ablehnung.

Domain-Anträge hatten einen ähnlich iterativen, aber anders gesteuerten Pfad. RFC 1032 verlangte vollständige Informationen und erwartete mehrere Korrespondenzaustausche vor der Autorisierung. Eine Hostmaster-Frage hielt den Antrag in Bearbeitung. Die Antwort eines Antragstellers konnte einen technischen oder administrativen Mangel beheben. Spätere Aktualisierungen konnten registrierte Informationen aktuell halten.

Der Leitfaden definierte nicht den Zeitpunkt, an dem eine erfolglose fortgesetzte Bearbeitung zur Ablehnung wurde. Er verlangte kein Abschlussschreiben, nachdem der Antragsteller den Hostmaster nicht zufriedenstellen konnte. Er bot kein Zeitfenster für eine erneute Prüfung und keinen separaten Gutachter. Diese Auslassungen beweisen nicht, dass das Personal eine Schlussfolgerung niemals erklärte oder wieder 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 Netzwerknummern. Alte Nummern konnten vorübergehend mit Übergangsmarkierungen sichtbar bleiben. Die Veröffentlichung zeigt, dass der Registerzustand überarbeitet wurde, während Kontinuitätsinformationen erhalten blieben. Sie identifiziert nicht den Grund, den Antragsteller, den Entscheidungsträger oder das Ausmaß der Meinungsverschiedenheiten hinter einer Änderung.

Diese Aufzeichnungen stützen drei enge Befunde. Die frühe Verwaltung erkannte an, dass Daten fehlerhaft sein konnten. Sie bot Mechanismen, damit korrigierte Informationen vorhandene Aufzeichnungen ersetzen oder ergänzen konnten. Sie bewahrte manchmal Übergangsausgaben, nachdem sich eine Nummer geändert hatte.

Sie liefern keinen abgelehnten Antragsteller, keine Berufung und keine Aufhebung.

Die Aufhebungskarte

Eine Berufungsuntersuchung wird klarer, wenn jedem Akteur nur das Verb zugewiesen wird, das durch die Aufzeichnung gestützt wird. Einige Akteure konnten Informationen empfangen oder korrigieren. Einige konnten eine lokale Einreichung autorisieren. Einige konnten Richtlinien empfehlen. Die Autorität über eine Kennungsfunktion zu besitzen, erzeugte nicht automatisch eine Berufungsgerichtsbarkeit.

Diese Karte enthält viele Wege zu fragen und weniger Wege zu erzwingen. NIC-Mitarbeiter konnten einen von ihnen gepflegten Datensatz korrigieren. Ein Host-Administrator konnte einen Benutzer autorisieren. Ein übergeordneter Domain-Administrator konnte ein lokales Urteil revidieren. Ein Sponsor konnte die Sponsoring-Entscheidung ändern, die die Verbindung betraf. Ein Regierungskunde konnte die Auftragnehmerleistung ansprechen. Das IAB konnte eine Richtlinienänderung empfehlen.

Keine dieser Fähigkeiten begründete, nach den hier vorliegenden Beweisen, ein allgemeines Antragstellerrecht, eine separate Person zur Überprüfung eines erfolglosen Registrierungsantrags zu bestellen und eine dokumentierte endgültige Entscheidung zu erlassen.

NIC-Personal: Bearbeitungsbefugnis ohne veröffentlichte zweite Instanz

Das Personal des NIC und des Hostmasters besetzte den ersten sichtbaren Entscheidungspunkt für mehrere Dienste. Seine Aufgaben umfassten die Entgegennahme von Formularen, die Prüfung erforderlicher Informationen, die Beantwortung von Fragen, die Pflege von Datenbanken und die Durchführung von Korrekturen. In der Domain-Verwaltung agierten sie innerhalb einer Hierarchie, in der das NIC Registrar oder Agent sein konnte, während übergeordnete Domain-Autoritäten die substanzielle Verantwortung behielten.

Die öffentlichen Anleitungen stützen einen erheblichen Personalermessensspielraum bei der Bearbeitung. Vollständigkeit ist selten ein rein mechanisches Konzept. Ein Fragebogen mochte jedes Feld enthalten und dennoch keinen zuverlässigen Serverbetrieb oder keine organisatorische Autorität nachweisen. Das Personal konnte entscheiden, dass mehr Erklärung notwendig war. Die veröffentlichte Anleitung zeigt nicht, ob schwierige Fälle einem leitenden Hostmaster zugewiesen, kollektiv erörtert oder nach oben verwiesen wurden.

Eine erneute Prüfung durch dasselbe Personal konnte wirksam sein. Wenn ein Antragsteller bessere Nachweise lieferte und der Hostmaster seine Position änderte, war das praktische Problem gelöst. Die historische Klassifizierung hängt dennoch von der früheren Aufzeichnung ab. Ohne eine erklärte nachteilige Entscheidung ist die Sequenz fortgesetzte Bearbeitung. Ohne die spätere Begründung ist es unmöglich zu wissen, was das Ergebnis änderte.

Die Ausgabe vonNIC KNACKSvom 17. Mai 1985 mit dem Titel „How to Reach the NIC“ zeigte differenzierte Kanäle für Benutzerunterstützung, Computerbetrieb, WHOIS-Aktualisierungen und Benutzerregistrierung, Host-Änderungen, Newsletter-Material sowie Vertrags- oder Managementfragen. Sie beschrieb auch eine Hotline, die durch Referenz- und Betriebspersonal unterstützt wurde. Dies ist ein Beleg für Dienstwegeleitung. Eine Person, die einen Datensatz für falsch hielt, hatte einen Ort, an den sie die Korrektur senden konnte; jemand mit einem Host-Problem konnte die Hostmaster-Funktion erreichen; ein breiteres Anliegen konnte an das Management gerichtet werden.

Ein Management-Postfach ist ein Beschwerdekanal, nicht automatisch ein Berufungsbüro. Die Quelle sagt nicht, dass das Management einen Registrierungsentscheid wiedereröffnen, einen anderen Beweisstandard anwenden, Gründe angeben oder das Ergebnis bewahren musste. Der Kanal mag exzellente informelle Überprüfung hervorgebracht haben. Seine Leistung bleibt ungemessen.

Postel, IANA und delegierte numerische Autorität

RFC 1174 liefert die klarste zeitgenössische Aussage über numerische Autorität. Er beschrieb die IANA als Inhaberin der primären Autorität für die numerischen Kennungen, die für den Betrieb des Internets erforderlich sind, wobei die Funktion am Information Sciences Institute der USC ausgeübt wurde. Er beschrieb das Internet Registry bei SRI als Pfleger von Registrierungsinformationen und Ausführender von Zuweisungsarbeit unter delegierter Verantwortung.

Delegation schafft eine vertikale Beziehung, aber ihre genauen Abhilfekonsequenzen hängen von den Delegationsbedingungen und der Praxis ab. IANA konnte den Umfang der delegierten Arbeit definieren, die Zuweisungsrichtlinie koordinieren und Fragen dazu beantworten, wer die Zuweisungsautorität innehatte. Diese Fähigkeiten belegen nicht, dass ein Antragsteller eine Entscheidung des SRI-Registers persönlich bei Jon Postel anfechten konnte.

Keine geprüfte Anweisung besagt: Reichen Sie eine Anfechtung bei der IANA ein, innerhalb einer bestimmten Frist, und erhalten Sie eine Entscheidung in der Sache. Kein Fall auf Antragsebene in der Stichprobe zeigt, dass Postel eine Ablehnung eines Antragstellers empfing, die ursprüngliche Aufzeichnung prüfte und eine andere Zuweisung anordnete. Es wäre ebenso unsicher, das Gegenteil zu folgern. Postels Position und die kleine professionelle Gemeinschaft machten informelle Konsultation möglich, aber Möglichkeit ist kein aufgezeichnetes Verfahren.

James PelkeysInterview mit Postel vom 18. Februar 1988liefert Kontext über die Erhaltung technischer Erörterungen. Postel erörterte, wie die vollständigen Diskussionen zu technischen Ideen, die diskutiert, aber nicht angenommen wurden, nicht immer in der veröffentlichten Dokumentation festgehalten wurden. Diese Beobachtung betrifft technische Ideen und die RFC-Geschichte. Sie kann nicht als Beleg dafür übertragen werden, dass Kennungsablehnungen, Berufungen oder Aufhebungen in gleicher Weise gehandhabt wurden.

Das Interview ist daher eine Warnung vor der Dokumentationskultur und keine Quelle für Antragsergebnisse. Es unterstreicht die Notwendigkeit von Korrespondenz, bevor ein Ausnahmefall rekonstruiert wird, beweist aber nichts über die Häufigkeit oder Fairness solcher Fälle.

Das IAB und die Bundesnetzwerkgremien: Empfehlungen sind keine Urteile

RFC 1174 war vom Vorsitzenden des Internet Activities Board an den Vorsitzenden des Federal Networking Council adressiert. Er enthielt Empfehlungen zur Verteilung der Kennungszuweisung und zur Änderung der alten Connected-Status-Richtlinie.

Das Memo empfahl, zentralisierte IANA- und Internet-Registry-Funktionen beizubehalten, während Blöcke von Netzwerk- und Autonomous-System-Nummern an genehmigte Organisationen delegiert werden sollten. Es empfahl außerdem, die Kennungsregistrierung von der Connected-Status-Beschränkung zu trennen. Das Internet Registry würde Richtlinieninformationen sammeln, und die DNS-Aufnahme wäre nicht mehr an dieselbe bundesstaatliche Verbindungsgenehmigung gebunden.

Dies ist ein echter Beleg für institutionelle Überprüfung auf Richtlinienebene. Es zeigt, dass das IAB erkannte, dass eine administrative Regelung, die für ein militärisches, staatliches und gefördertes Forschungsumfeld konzipiert war, nicht mehr zu einem wachsenden kommerziellen und internationalen Internet passte. Es zeigt auch, dass das IAB dem FNC eine vorgeschlagene Antwort übermittelte.

Die Verben sind entscheidend. Das IABempfahl. Der FNCerhieltdie Empfehlung. Das Dokument schlug vor, dass das Internet Registryangewiesen werden sollte, Änderungen vorzunehmen. RFC 1174 allein belegt weder das Annahmedatum des FNC, die Umsetzungsrichtlinie noch den Abschluss jeder vorgeschlagenen Änderung.

Wichtiger ist, dass das Memo keinen Antragstellerfall entschied. Es überprüfte keinen Grund eines Hostmasters, stellte keine Kennung wieder her und ordnete keine erneute Prüfung einer früheren Ablehnung an. Eine Richtlinienreform kann auf angesammelte Probleme reagieren, ohne die Namen oder Akten der Betroffenen zu bewahren. Sie kann prospektiv wirken, während frühere Ergebnisse unberührt bleiben.

Diese Unterscheidung verhindert einen häufigen Analysefehler. Die Existenz eines Gremiums, das Systemrichtlinien empfehlen kann, beweist nicht, dass dasselbe Gremium individuelle Berufungen hörte. Umgekehrt beweist das Fehlen eines Antragstellerkalenders in einem RFC nicht, dass Bundesbeamte niemals informell intervenierten. Die Empfehlung etabliert eine institutionelle Stimme, nicht die Fallgerichtsbarkeit.

DCA, Sponsoren und der Unterschied zwischen Registrierung und Verbindung

Die Benutzerregistrierungsanweisungen von 1983 stellen das DDN-PMO hinter die Registrierungsaktion. Host-Administratoren waren für autorisierte Benutzer verantwortlich, und das DDN-PMO erklärte, es würde mit ihnen zusammenarbeiten, wenn Probleme aufträten. Dies war eine direkte Problemklärungsaussage, aber die Beziehung verlief über die Administratoren.

Eine Einzelperson, die mit einem Host-Administrator nicht einverstanden war, befand sich in einer schwierigen Lage. Das DDN-PMO mochte die geltenden Richtlinien klären oder ein systemisches Problem ansprechen. Das Dokument versprach nicht, dass die Einzelperson den Administrator umgehen und eine unabhängige Überprüfung erhalten konnte. Der Autorisierer war auch der lokale institutionelle Vertreter.

Staatliches Sponsoring spielte für die Konnektivität eine andere Rolle. Die Geschichte des verbundenen Status in RFC 1174 beschreibt die Sanktion durch eine US-Regierungssponsororganisation. Ein Sponsor konnte bestätigen, dass ein Netzwerk für die Verbindung qualifiziert war, Unterstützung zurückziehen oder den Umfang einer geförderten Aktivität klarstellen. Eine solche Handlung mochte den praktischen Zugang bestimmen, selbst wenn das Internet Registry bereits eine Nummer zugewiesen hatte.

Eine Sponsoren-Eskalation muss daher präzise bezeichnet werden. Einen Sponsor zu bitten, die Berechtigung zu bestätigen, ist keine Berufung gegen eine numerische Zuweisung. Einen Sponsor zu überzeugen, seine eigene Entscheidung zu ändern, ist eine erneute Prüfung innerhalb der Sponsoring-Kette. Den Sponsor zu bitten, das Register zu kontaktieren, kann institutionelle Interessenvertretung sein. Nur eine direkte Fallakte kann feststellen, was geschah.

Die gleiche Präzision gilt für Bundesauftragnehmer und Universitäten. Ein Auftragnehmer mochte ein Netzwerkproblem als Hindernis für die Regierungsarbeit vorbringen. Ein Universitätsforscher mochte einen Programmbeauftragten um Hilfe bitten. Ein militärischer Host hatte Administratoren und Programmmanagementbeziehungen. Diese Strukturen schufen mögliche Wege der Nachfrage. Die Stichprobe enthält keine vergleichenden Antragsdaten, die zeigen, wie oft sie Ergebnisse veränderten.

Zwei Vertragsketten, beide kein automatisches Antragstellerrechtsmittel

Bundesförderung schafft Aufsicht, aber sie schafft nicht von selbst ein Berufungsrecht.

Die erste relevante Kette istDCA–SRI/NIC. Das SRI ARC/NIC-Findbuch identifiziert DCA-finanzierte NIC-Arbeit, Vertragsvorschläge, Liefergegenstände, Monatsberichte und laufende Überprüfungen. Die DCA-Materialien von 1987 enthalten ein Vertragsüberprüfungstreffen und beschreiben NIC-Aufgaben und Dienstkanäle. Diese Aufzeichnungen belegen, dass der Regierungskunde die Auftragnehmeraktivität überwachte.

Dieser Artikel hat die operativen SRI-Vertragsklauseln, die jeden Registrierungsdienst regelten, nicht geprüft. Er erhebt daher nicht den Anspruch, dass diese Verträge eine Antragsfrist, eine Aufzeichnungsaufbewahrungspflicht, ein Antragstellerbeschwerdeverfahren oder die Befugnis eines Vertragsbeamten auferlegten, ein bestimmtes Registrierungsurteil umzustoßen. Die staatliche Aufsicht über Liefergegenstände und Dienstleistungserbringung mag erheblich gewesen sein, ohne einem Antragsteller durchsetzbare Rechte zu verleihen.

Die zweite Kette istDARPA–USC/ISI/IANA. DieGAO-Entscheidung B-327398, die viel später erging, berichtete, dass das GAO keine Kopien der DARPA-Verträge aus den 1970er–1990er Jahren erhalten konnte, unter denen die IANA-Funktionen entwickelt und ausgeführt wurden, obwohl es Informationen über eine spätere Vertragsaufgabe ab 1995 wiedererlangte. Diese Feststellung begrenzt Schlussfolgerungen über die frühen DARPA-USC-Bedingungen.

Sie stellt nicht fest, dass die separate DCA-SRI-Vertragsaufzeichnung fehlt. Die beiden Auftragnehmer, Regierungsbeziehungen und Funktionen müssen getrennt bleiben. Die SRI-Sammlung kartiert Vertragsmaterialien, die Fragen zur NIC-Leistung beantworten könnten. Die GAO-Beweislücke betrifft historische DARPA-USC/IANA-Verträge.

Ein Vertragsbeamter konnte durchsetzen, welche Verpflichtungen ein anwendbarer Vertrag tatsächlich enthielt. Diese Befugnis würde gewöhnlich das Vertragsinteresse der Regierung schützen. Ein Antragsteller bräuchte dennoch einen Weg, über den ein Registrierungsproblem zu einem Vertragserfüllungsproblem wurde. Ohne die Klausel, die Beschwerde, die Regierungsmaßnahme und das Ergebnis bleibt „Überprüfung durch den Vertragsbeamten“ ein möglicher Kontrollmechanismus und keine dokumentierte Abhilfe.

Sechs verschiedene Dinge, die später als Berufung beschrieben wurden

Institutionelle Geschichten verwenden „Berufung“ oft für jedes Ereignis, bei dem auf ein ursprüngliches Problem ein besseres Ergebnis folgt. Dieses Vokabular verschleiert, wer handelte und was sich änderte.

Korrekturrepariert Daten oder Form. Die Benutzerregistrierungsanweisungen von 1983 dokumentierten direkt Korrektur, Hinzufügung, Löschung, Duplikatsprüfung und Wiedereinreichung. RFC 1032 dokumentierte Domain-Datenaktualisierungen und iterative Korrespondenz. Korrektur kann ohne eine bestrittene Entscheidung auftreten.

Informelle erneute Prüfungfindet statt, wenn der ursprüngliche Mitarbeiter oder das Büro eine frühere Ansicht wieder aufgreift. Eine telefonische Erklärung, neue technische Nachweise oder die Klärung organisatorischer Autorität konnten eine erneute Prüfung veranlassen. Die dichte Kontaktinfrastruktur der Zeit macht dies plausibel, aber die Stichprobe enthält keinen vollständigen Antragstellerfall, der dies demonstriert.

Sponsoren-Eskalationverlagert die Angelegenheit zu einer Organisation, die Autorisierung, Finanzierung oder Verbindungssanktion liefert. Der Sponsor kann die Berechtigung klären, sich bei einer anderen Institution einsetzen oder seine eigene Position ändern. Das Ergebnis kann den Zugang beeinflussen, ohne die Entscheidung des Registers umzustoßen.

Beschwerdemeldet Dienstversagen, Verzögerung, Inkonsistenz oder Personalverhalten. Das Kontaktblatt von 1985 trennte Managementfragen von routinemäßigen Dienstkanälen und zeigte, dass ein breiteres Anliegen einen Adressaten hatte. Es sagte nicht, dass eine Beschwerde einen Kennungsantrag wiedereröffnete.

Veröffentlichte Berufungist ein regelbasierter Weg, auf dem eine betroffene Partei eine Entscheidung bei einem benannten Gutachter anfechten kann. Sie identifiziert normalerweise die anfechtbare Entscheidung, wohin die Anfechtung geht und wer die Antwort erteilt. Die hier untersuchte Verfahrensstichprobe identifiziert keine allgemeine veröffentlichte Berufung dieser Art für erfolglose Domain- und numerische Kennungsanträge von 1983–1992.

Durchsetzbares Rechtsmittelstammt von einer Autorität, die in der Lage ist, Handlungen nach Gesetz, Vertrag oder verbindlichen Programmregeln zu erzwingen. Ein Gericht, eine Behörde oder ein Vertragsbeamter könnte ein solches Rechtsmittel bieten, wenn Gerichtsbarkeit, ein rechtliches Interesse und eine anwendbare Verpflichtung bestanden. Die Registrierungshandbücher versprachen es nicht, und die Stichprobe enthält kein qualifizierendes Urteil oder keine behördliche Anordnung, die ein NIC- oder IANA-Kennungsergebnis im Zeitraum umstieß.

Diese Kategorien können sich in einer faktischen Sequenz überschneiden. Ein Antragsteller mag ein Formular korrigieren, Hostmaster-Personal um erneute Prüfung bitten, einen Sponsor einbeziehen, sich beim Management beschweren und schließlich einen externen Rechtsanspruch verfolgen. Die Etiketten sollten dem Beweis in jedem Schritt folgen, anstatt die gesamte Sequenz als „Berufung“ zu behandeln.

Das Telefon als praktisches Rechtsmittel und archivarischer blinder Fleck

Die stärkste wohlwollende Alternative beginnt mit der Erreichbarkeit des NIC.

Das NIC veröffentlichte elektronische Kanäle und betrieb telefonische Unterstützung. RFC 1032 erwartete Korrespondenz vor der Domain-Autorisierung. Das Blatt „How to Reach the NIC“ von 1985 leitete verschiedene Themen an verschiedene Rollen, einschließlich Unterstützung, Registrierung, Host-Änderungen, Betrieb und Management. Das Findbuch beschreibt eine Referenz- und Hotline-Operation, die Telefon- und E-Mail-Anfragen beantwortete und Aktivitätsstatistiken in Monatsberichten berichtete.

Eine kleine, technisch verbundene Gemeinschaft mag viele Probleme gesprächsweise gelöst haben. 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 Dienstanbieter konnte die Anforderungen an Adressklassen erklären. Ein Sponsor konnte bestätigen, dass ein Netzwerk in eine geförderte Aktivität fiel.

Aus Sicht des Teilnehmers mochte ein solcher Anruf nützlicher gewesen sein als ein formelles Verfahren. Geschwindigkeit, Kontext und Vertrauen können informelle Verwaltung hochwirksam machen.

Aus Sicht des Historikers ist derselbe Anruf ein fehlender Übergang. Das eingehende Formular mag erhalten sein. Die endgültige Zuweisung mag erhalten sein. Die Erklärung, die sie verband, mag nicht erhalten sein. Wenn keine Fallsnotiz gemacht wurde, kann ein Forscher nicht feststellen, ob das Ergebnis routinemäßiger Beratung, erneuter Prüfung, Sponsoring oder einem neuen Antrag folgte.

Telefonaufzeichnungen, wo sie erhalten sind, brauchen sorgfältige Interpretation. Ein Anrufprotokoll mag das Datum, das grobe Thema, die Anruferklasse und ob eine Nachverfolgung nötig war, identifizieren. Es kann dennoch den Antrag, die Beratung, die Autorität und das Endergebnis auslassen. Anrufzählungen können nicht zu Berufungszählungen werden ohne Fallverknüpfung.

E-Mail bietet mehr Details, aber keine Garantie für Vollständigkeit. Nachrichten können getrennt vom Antrag abgelegt sein. Teilnehmer mögen zum Telefon wechseln. Eine Antwort mag ohne die Frage erhalten sein oder umgekehrt. Ein Thread kann eine Verhandlung dokumentieren, während die endgültige Entscheidung unerwähnt bleibt.

Dieses Erhaltungsproblem schneidet in beide Richtungen. Es blockiert die Behauptung, dass niemals eine Überprüfung stattfand. Es blockiert auch die Behauptung, dass informelle Überprüfung durchgängig funktionierte. Die Kontaktinfrastruktur ist beobachtbar; die Qualität der Lösung ist es nicht.

Wer hatte Zugang zu praktischer erneuter Prüfung?

Die institutionelle Karte legt eine Verteilungsfrage nahe, keinen Verteilungsbefund.

Ein militärisches Netzwerk mochte einen Host-Administrator, eine Verbindungsperson, eine Programmmanagementbeziehung und einen Regierungssponsor haben. Ein Bundesauftragnehmer mochte ein ungelöstes Netzwerkproblem über einen technischen Vertreter oder eine Auftragskette vorbringen. Eine geförderte Universität konnte sich auf Campus-Administratoren, einen Forschungssponsor und, ab 1992, einen Netzwerk- oder Dienstanbieter der mittleren Ebene stützen.

Ein kommerzieller oder internationaler Antragsteller mochte ebenfalls fachkundige Vermittler und direkte professionelle Beziehungen haben. RFC 1174 erkannte ausdrücklich an, dass das Internet über seine ursprüngliche bundesstaatliche und geförderte Forschungspopulation hinausgewachsen war. Einige internationale Netzwerke waren tief in Forschungskooperationen integriert. Die institutionelle Kategorie allein kann den Zugang nicht bestimmen.

Die Hypothese ist, dass praktische erneute Prüfung teilweise von Beziehungen abgehangen haben mag: den richtigen Administrator zu kennen, einen Sponsor zu haben, der Fragen stellen kann, oder über einen Anbieter zu arbeiten, der mit dem Registerverfahren vertraut ist. Diese Hypothese ist plausibel, weil die dokumentierten Kanäle rollenbasiert und hierarchisch waren.

Sie ist nicht getestet. Die Stichprobe enthält keinen Antragsnenner, aufgeteilt nach militärischen, staatlichen, akademischen, kommerziellen und internationalen Antragstellern. Es gibt keine vergleichbaren Maße für Vollständigkeit, verstrichene Zeit, gestellte Fragen, Sponsorenbeteiligung oder Endergebnis.

Vertrauenswürdige Vermittler mögen Ungleichheit reduziert haben, indem sie weniger erfahrenen Antragstellern halfen, korrekte Anträge einzureichen. Sie mögen Abhilfe auch beziehungsabhängig gemacht haben, was Institutionen zugutekam, die bereits mit dem administrativen Netzwerk verbunden waren. Beide Effekte könnten gleichzeitig wirken.

Ein vertretbarer Vergleich bräuchte Antragsebenendaten und Kontrollen für technische Bereitschaft, beantragte Ressource, Sponsoring-Anforderungen und Antragsvollständigkeit. Ohne diese Beweise sollte weder Gleichbehandlung noch Ungleichbehandlung als Ergebnis berichtet werden.

Gerichte und Behörden außerhalb der technischen Hierarchie

Ein Gericht ist kein Berufungsschalter für jede administrative Unannehmlichkeit. Es handelt, wo das Gesetz Gerichtsbarkeit bietet, ein Kläger ein anerkennenswertes Interesse hat und einem geeigneten Beklagten aufgegeben werden kann, Abhilfe zu leisten.

Ein früher Domain-Streit mochte organisatorische Autorität, Vertrag, Markenrecht oder ein anderes rechtliches Interesse betreffen. Ein Bundesauftragnehmer mochte Rechte aus seinem eigenen Vertrag besitzen. Die Handlung eines Regierungssponsors mochte einem separaten Gesetz oder einer Programmregel unterliegen. Diese Möglichkeiten hingen von Tatsachen jenseits des Kennungsformulars ab.

Die technischen Leitfäden der Zeit besagten nicht, dass ein erfolgloser Antragsteller ein Gericht bitten konnte, das technische Urteil des Hostmasters zu überprüfen. Sie stellten auch nicht fest, dass jede NIC- oder IANA-Handlung eine endgültige Behördenentscheidung war. Auftragnehmerstatus, delegierte technische Autorität, bundesstaatliches Sponsoring und Regierungsfinanzierung fallen nicht in eine einzige öffentlich-rechtliche Kategorie.

Behördliche Kanäle erfordern die gleiche Sorgfalt. DCA, DARPA, DDN-PMO oder eine andere Bundesbehörde konnten Beschwerden im Rahmen ihrer Programm- oder Auftragsverantwortung entgegennehmen. Ob sie den Anspruch eines Antragstellers entscheiden, einen Auftragnehmer zur Änderung einer Registrierung zwingen oder ein durchsetzbares Rechtsmittel bieten musste, hinge von der maßgeblichen Autorität ab.

Keine direkte Aufzeichnung von 1983–1992 in dieser Stichprobe paart eine Kennungsablehnung mit einem Gerichtsurteil, einer behördlichen Anordnung oder einer Auftragsentscheidung, die sie aufhob. Ein externes Rechtsmittel bleibt abstrakt rechtlich möglich und in der relevanten Fallpopulation historisch unbewiesen.

Gegenfaktische Überlegung A: Die Entscheidungen bewahren, die Gründe hinzufügen

Man stelle sich vor, jede substanzielle Kennungs- und Verbindungsentscheidung von 1983–1992 wäre unverändert geblieben. Die gleichen vollständigen Anträge waren erfolgreich. Die gleichen technischen Mängel erforderten Korrektur. Die gleichen Sponsorenregeln regelten den Zugang zu bundesgeförderter Infrastruktur.

Ändern Sie nur die Aufzeichnung. Geben Sie jedem eindeutigen Antrag ein Eingangsdatum und eine dauerhafte Kennung. Wenn die Bearbeitung endet, bewahren Sie einen kurzen Grund und das verantwortliche Büro. Wenn dasselbe Büro erneut prüft, verknüpfen Sie die zweite Entscheidung mit der ersten. Wenn die Angelegenheit zu einem Sponsor, der IANA, dem Management oder einer anderen Autorität wechselt, protokollieren Sie die Überweisung und das Endergebnis.

Eine solche Aufzeichnung würde die Prüfbarkeit verbessern, selbst wenn sich die Genehmigungsraten nicht bewegten. Forscher könnten ein fehlendes Feld von einer substanziellen Ablehnung unterscheiden. Wiederholte Anträge könnten als Korrekturen, Ersetzungen oder erneute Prüfungen identifiziert werden. Die verstrichene Zeit könnte in Antragstellerantwort, Personalbearbeitung, Sponsorprüfung und ungelöste Intervalle aufgeteilt werden. Richtlinienänderungen könnten mit den Falltypen verknüpft werden, die ein Problem aufdeckten.

Die zusätzliche Aufzeichnung könnte die Fehlererkennung verbessern. Vergleichbare Gründe könnten inkonsistente Klassifizierungen offenbaren, oder sie könnten zeigen, dass scheinbar unterschiedliche Ergebnisse auf unterschiedlichen Tatsachen beruhten. Dies ist eine Möglichkeit, kein gemessener historischer Effekt.

Es wird nicht behauptet, dass moderne verwaltungsrechtliche Pflichten bereits jede frühe Internetregistrierung beherrschten. Die gegenfaktische Überlegung stellt eine engere institutionelle Frage: Welche Beweise hätten es Zeitgenossen und späteren Historikern erlaubt, die Konsistenz zu testen, ohne die zugrundeliegende Autoritätsstruktur zu ändern?

Ein datiertes Grund- und Ergebnisprotokoll würde selbst keine Unabhängigkeit schaffen. Der Gutachter 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 ihn zu bewerten.

Gegenfaktische Überlegung B: Tatsächlich geringes Konfliktniveau

Nehmen Sie nun an, dass die erstinstanzliche Verwaltung gewöhnlich korrekt war. Antragsteller waren technisch fähig, die Anforderungen waren weithin verstanden, und die meisten Probleme wurden durch vertrauensvolle Korrespondenz gelöst. Substanzielle Ablehnungen und ernsthafte Streitigkeiten waren selten.

Welche Spuren sollte dieses wohlwollende System hinterlassen?

Die meisten unvollständigen Anträge würden von identifizierbaren Fragen und prompten Korrekturen gefolgt. Wiederholte Einreichungen würden gewöhnlich sichtbaren technischen oder administrativen Änderungen entsprechen. Die verstrichene Zeit nach der Vervollständigung wäre kurz oder durch Serverbereitschaft, Sponsoring oder eine andere externe Abhängigkeit erklärt. Sponsorenkontakte würden die Berechtigung häufiger klären, als dass sie frühere Urteile verdrängten. Beschwerdespuren wären im Verhältnis zu einer bekannten Antragspopulation selten.

Zurückgezogene Anträge bräuchten antragstellerseitige Erklärungen, wenn sie von stillschweigenden Ablehnungen getrennt werden sollten. Telefonische Lösungen bräuchten zeitgenössische Notizen, 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 wohlwollenden Infrastruktur sind sichtbar. RFC 1032 erwartete Korrespondenz. Das NIC unterhielt Unterstützungs- und Managementkanäle. Host-Administratoren konnten Benutzerdatensätze korrigieren. Das DDN-PMO erklärte, es würde bei Problemen mit Administratoren zusammenarbeiten. RFC 1359 behandelte Anbieter als Quellen für Antragsberatung. RFC 1174 beschrieb eine Richtlinie, die darauf abzielte, eindeutige Nummern breit zuzuweisen, während die Verbindungssanktion getrennt wurde.

Unbeobachtet bleibt, wie diese Kanäle funktionierten. Die Anzahl der eindeutigen Anträge ist unbekannt. Ebenso unbekannt sind die Zahlen der zur Informationsnachlieferung zurückgesandten, zurückgezogenen, abgelehnten, erneut geprüften, eskalierten und aufgehobenen Anträge. Es gibt keinen Vergleich von Anruferklassen oder Endergebnissen.

Ein System, in dem enttäuschte Antragsteller verschwanden, könnte die gleiche veröffentlichte Zuweisungsliste erzeugen wie ein System mit fast keinen ernsthaften Konflikten. Der unterscheidende Beweis liegt in der Antragskorrespondenz und den Erledigungsaufzeichnungen, 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. Er beschrieb das Parsen und die Überprüfung von Registrierungsvorlagen, die Korrektur durch den ursprünglichen Antragsteller, das Erlöschen nach einem siebentägigen Antwortfenster, Trouble-Ticket-Nummern und öffentliche Statusinformationen, die zeigten, ob ein Ticket noch ausstand und wer es bearbeitete.

Diese Merkmale machten Bearbeitungszustände beobachtbarer. Sie schufen keine unabhängige Berufungsinstanz. Parserfehler, Überprüfung, Korrektur und abschließende Personalbearbeitung blieben Teile der Verwaltung und nicht der Überprüfung durch eine separate Instanz.

Der Vergleich stützt nur diese Schlussfolgerung: Ein öffentliches Verfahren konnte eine Antragskennung und Zwischenstatus offenlegen. Sein Erscheinen 1993 beweist nicht, dass eine frühere interne Nachverfolgung fehlte, und es beantwortet nicht, wie substanzielle Streitigkeiten überprüft wurden.

Was geschlossen werden kann

Drei Aussagen müssen getrennt bleiben.

Erstens identifizierten die hier untersuchten veröffentlichten Verfahren keine allgemeine, unabhängige Berufungsinstanz für erfolglose Domain- oder numerische Kennungsanträge im Zeitraum 1983–1992. Sie legten Anträge, verantwortliche Administratoren, technische Anforderungen, Korrektur, Korrespondenz, lokale Streitgrenzen und institutionelle Autorität fest. Sie richteten keinen allgemeinen Antragstellerweg zu einem benannten Zweitinstanzgutachter und einer dokumentierten endgültigen Entscheidung ein.

Zweitens war informelle Lösung institutionell möglich und für gewöhnliche Probleme plausibel. Das NIC war erreichbar. Das Personal erwartete Korrespondenz. Administratoren und Sponsoren besetzten definierte Rollen. Anbieter konnten Antragsteller beraten. Management und Regierungsstellen konnten Anliegen im Rahmen ihrer Verantwortlichkeiten 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 Antragskorpus, aus dem sich unvollständige, verzögerte, zurückgezogene, abgelehnte, korrigierte, erneut geprüfte, eskalierte, aufgehobene oder endgültige Fälle zählen ließen. Sie enthält keine qualifizierende Ablehnungs-und-Aufhebungs-Akte. Fehlende Beweise verhindern sowohl eine Anschuldigung systematischen Missbrauchs als auch eine Behauptung nachgewiesener Konsistenz.

Die Administratoren des frühen Internets lösten ein schwieriges Koordinationsproblem über sich schnell verändernde technische und institutionelle Grenzen hinweg. Ein System konnte kompetent, kooperativ sein und dennoch ein schwaches Verfahrensarchiv hinterlassen. Es konnte Fehler korrigieren, ohne den Akt erneute Prüfung zu nennen. Es konnte die Richtlinie ändern, ohne individuelle Berufungen zu hören. Es konnte wirksame Hilfe leisten und diese Hilfe über Beziehungen verteilen, die spätere Historiker nicht bewerten können.

Der fehlende Berufungsschalter ist daher kein Beweis, dass ein bestimmtes Büro hätte existieren sollen, aber nicht existierte. Er ist die fehlende Kette von Gründen, Gutachtern und Ergebnissen, die nötig wäre, um festzustellen, was geschah, nachdem der normale Weg versagte.

Ein geringes sichtbares Konfliktniveau mag gute Verwaltung widerspiegeln. Es mag private Lösung widerspiegeln. Es mag Antragsteller widerspiegeln, die aus der überlieferten Aufzeichnung verschwanden. Bis direkte Antragsdateien 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, digitalisierte Bündelseiten 67–73 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, Nummer 2, 17. Mai 1985, digitalisierte Bündelseite 94 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