RFC 790 und die verborgene Politik in einer Adressliste

Zusammenfassung

• RFC 790 legt direkt fest, dass mehrere Nummernserien als aktuelle operative Referenz gepflegt wurden und Entwickler angewiesen wurden, Jon Postel für Zuweisungen zu kontaktieren, veröffentlicht jedoch keine allgemeine Netzwerkberechtigungsregel oder Aufteilung der Zuweisungsbefugnis.
• RFC 820 fügt Forschungs-, Verteidigungs- und kommerzielle Kategorien hinzu, eine empfohlene Verteilung des Netzwerknummernraums, eine vorgeschlagene Gateway-Bereitschaftsbedingung für Forschungsbewerber und eine voraussichtliche Aufteilung der Verantwortlichkeiten zwischen Institutionen.
• RFC 820 stellt ebenfalls fest, dass seine Empfehlung noch nicht vollständig umgesetzt worden war und Postel immer noch alle Zuweisungen koordinierte, sodass Vereinbarung, vorgeschlagene Politik und Arbeitspraxis nicht als derselbe institutionelle Zustand behandelt werden können.
• Die veröffentlichten Tabellen offenbaren Zuweisungen, Übergänge und interne Inkonsistenzen, nicht die Grundgesamtheit der Antragsteller. Ohne Aufzeichnungen über Anträge, Ablehnungen, Rücknahmen, Nutzung und zeitgenössische Korrespondenz können sie weder die Behandlung der Antragsteller, das Verteilungsmotiv noch eine Absicht zur Verschleierung von Entscheidungen belegen.

Legen Sie die erste Seite zweier nichtproportionaler Dokumente unter dieselbe Leselampe. Auf Seite 1 vonRFC 790, datiert September 1981, heißt es im einleitenden Absatz, dass aktuelle Informationen von Jon Postel bezogen werden können, und fügt hinzu: „Die Zuweisung von Nummern wird ebenfalls von Jon bearbeitet.“ Der entsprechende Absatz im untersuchten Text vonRFC 820behält die persönliche Grammatik bei, fügt jedoch eine Einschränkung ein: Die Zuweisungen werden von demselben Koordinator bearbeitet, vorbehaltlich einer Vereinbarung zwischen DARPA/IPTO und DDN/PMO, die in Anhang A dokumentiert ist.

Der hinzugefügte Klausel ist klein genug, um in einem Dokument, das von Zahlenspalten dominiert wird, zu verschwinden. Anhang A ist nicht klein. Er berichtet über Vereinbarungen, die bei einem Treffen im September 1982 erzielt wurden, empfiehlt die Aufteilung des Netzwerknummernraums auf Forschung und Entwicklung, das Verteidigungsministerium und kommerzielle Nutzungen, benennt voraussichtliche institutionelle Zuständigkeiten, schlägt eine Berechtigungsbedingung für Forschungsnetze vor und endet mit dem Eingeständnis, dass die Regelung noch nicht vollständig umgesetzt wurde.

Die Gegenüberstellung wirft eine präzise Frage auf. Legte das spätere Dokument eine Autorität offen, die im früheren Verzeichnis unsichtbar gewesen war? Kündigte es eine neue Zuweisungspolitik an, dokumentierte es eine bereits in der Praxis entstehende Regelung, bewältigte es den Übergang zu einer anderen Netzwerkarchitektur oder lieferte es lediglich einen vollständigeren redaktionellen Bericht über Arbeiten, die stets Koordination erforderten? Die Seiten gestatten es, einige dieser Möglichkeiten zu überprüfen. Sie erlauben es nicht, eine Wahl zwischen ihnen allein anhand des Layouts zu treffen.

Es handelt sich daher nicht um die Behauptung, dass eine technische Tabelle heimlich für das Internet Gesetze erließ. Es ist eine Untersuchung dessen, was geschehen musste, bevor ein Eintrag Teil einer gemeinsamen operativen Aufzeichnung werden konnte. Die Antwort variiert je nach Nummernserie. Die Auswahl eines ungenutzten Protokollcodes ist nicht derselbe Vorgang wie die Entscheidung, welche Klasse und administrative Kategorie ein Netzwerk enthalten soll. Das Erfassen eines Ports ist nicht gleichbedeutend mit der Entscheidung, ob ein experimentelles Netzwerk betriebsbereit geworden ist.

Die Veröffentlichung eines Kontakts identifiziert weder den Antragsteller, noch den Entscheider oder den Begünstigten. Die zentrale Aufgabe besteht darin, diese Funktionen zu trennen, bevor gefragt wird, welche institutionellen Annahmen die Dokumente stützen.

Zwei Artefakte, eine Katalogdiskrepanz

RFC 790 ist ein 15-seitiges Dokument der Network Working Group, das J. Postel am Information Sciences Institute der University of Southern California zugeschrieben und auf September 1981 datiert ist. Es besagt, dass es aktuell zugewiesene Werte aus mehreren Serien aufzeichnet, die in Netzwerkprotokollimplementierungen verwendet werden. Ein Entwickler, der eine Link-, Socket-, Port-, Protokoll- oder Netzwerknummer benötigt, wird angewiesen, Postel zu kontaktieren, um eine Zuweisung zu erhalten.

Das Dokument durchläuft zugewiesene Netzwerknummern, Internet-Versionsnummern, Internet-Protokollnummern, Port- oder Socket-Nummern und ARPANET-Linknummern. Es folgen Referenzen und ein Verzeichnis verantwortlicher Personen. Eingeklammerte Codes neben den Einträgen verweisen auf Dokumente oder namentlich genannte Kontakte. Die Form dient mindestens drei unmittelbaren Zwecken: der Vermeidung numerischer Kollisionen, der Information der Implementierer darüber, was ein Wert bezeichnet, und der Bereitstellung eines Ansprechpartners, wenn die knappe Zeile nicht ausreicht.

RFC 790 erklärt auch, dass er regelmäßig aktualisiert werden wird. Dieses Versprechen ist grundlegend für seinen Status. Es war nicht dazu bestimmt, das letzte Wort zu bleiben. Es ersetzte frühere Assigned-Numbers-Dokumente und würde selbst ersetzt werden. Sein Anspruch auf Aktualität bezog sich auf einen bestimmten operativen Moment, nicht auf dauerhafte Autorität oder unveränderliche historische Wahrheit.

Der Abschnitt zu den Netzwerknummern umfasst die Seiten 2 bis 4. Er erläutert die drei Adressklassen und druckt ihre Bit-Layouts ab. Klasse A verwendet eine führende Null, sieben Netzwerknummernbits und ein 24-Bit-lokales Feld. Klasse B verwendet das höherwertige Muster10, vierzehn Netzwerknummernbits und ein 16-Bit-lokales Feld. Klasse C verwendet110, einundzwanzig Netzwerknummernbits und ein 8-Bit-lokales Feld. Dies waren technische Kategorien mit radikal unterschiedlichen Kapazitäten, aber die Existenz unterschiedlicher Kapazitäten allein begründet nicht, wie Anträge bewertet wurden oder ob die Schonung der Grund für eine Zuweisung war.

Die benannten Zeilen der Klasse A bilden eine gemischte und unvollständige Momentaufnahme. Sie umfassen Forschungsnetze, Paketfunk-Experimente, militärische Einrichtungen, öffentliche Datennetze, Universitäten, Auftragnehmer und kommerzielle Betreiber in mehreren Ländern. Die Tabelle identifiziert nicht die Grundgesamtheit, aus der diese Einträge hervorgingen. Sie ist weder eine Erhebung von Netzen, die Identifikatoren wünschten, noch eine Antragstellerliste oder eine Aufzeichnung von Anträgen, die nicht zu veröffentlichten Zuweisungen führten.

Das untersuchte RFC-820-Artefakt ist mit 22 Seiten länger. Sein Textkopf zeigt J. Postel und J. Vernon und als Datum Januar 1983. Der aktuelleKatalogeintrag des RFC-Editorshingegen bezeichnet RFC 820 als „Assigned numbers, August 1982“ und führt allein J. Postel auf. Diese Analyse identifiziert Passagen anhand von Kopfzeile und Seitenzahlen des untersuchten Textes, während sie die Katalogdiskrepanz bewahrt. Die verfügbaren Quellen rechtfertigen es nicht, stillschweigend eine Datums- und Autorenkonvention als Korrektur der anderen zu wählen.

RFC 820 behält die frühere Inventarfunktion bei, erweitert jedoch seinen Umfang. Es bezieht sich auf den Übergang von der ARPANET-Umgebung zum ARPA-Internet, fügt autonome Systemnummern hinzu, enthält Ethernet-Nummern und Zuordnungen öffentlicher Datennetze und vergrößert die Netzwerktabellen erheblich. Am wichtigsten hier: Seite 1 unterwirft die Nummernzuteilung der Vereinbarung zwischen DARPA/IPTO und DDN/PMO, während die Seiten 19 bis 22 die daraus resultierenden Empfehlungen und den Implementierungsvermerk wiedergeben.

Beide RFCs sind heute im Legacy-Stream als Historic klassifiziert. RFC 790 wurde durch RFC 820 abgelöst, und RFC 820 wurde durch RFC 870 abgelöst. Diese aktuellen Klassifizierungen implizieren nicht, dass die Dokumente zum Zeitpunkt ihrer Nutzung ungültig oder irrelevant waren. Eine wiederkehrende Registerpublikation veraltet, weil sich Zuweisungen und Praktiken ändern. Die spätere Veraltung ist Teil dieses dokumentarischen Lebenszyklus, nicht eine rückwirkende Aufhebung der früheren Momentaufnahme.

Ein späterer Vergleich hilft, die Grenze zu definieren.RFC 943, veröffentlicht im April 1985, bezeichnet sich ausdrücklich als offiziellen Statusbericht für Nummern, die in Protokollen der ARPA-Internet-Community verwendet werden. Es unterscheidet zudem Netzwerke, die mit dem ARPA- oder DDN-Internet verbunden sind, von unabhängigen Netzwerken, die die Internet-Protokolle verwenden. Diese spätere Artikulation kann nicht in RFC 790 importiert werden. Sie zeigt, dass sich Sprache und Klassifikationsapparat weiterentwickelten.

Die entscheidenden Unterschiede zwischen den beiden Hauptartefakten lassen sich verdichten, ohne zu behaupten, dass jeder Unterschied nur eine Ursache hat:

Merkmal	RFC 790, September 1981	Geprüfter RFC 820-Text, Januar 1983	Unterstützte Erkenntnis
Zuweisungskontakt	Seite 1 besagt, dass Zuweisungen von Jon Postel bearbeitet werden.	Seite 1 behält Postel bei, macht die Zuteilung jedoch von einer Vereinbarung zwischen DARPA/IPTO und DDN/PMO abhängig.	Beide stellen die Zuweisung als organisierte Funktion dar; der spätere Text erkennt eine Agenturvereinbarung an.
Netzwerkklassifikation	Seiten 2–4 verwenden technische Adressklassen ohne administrative Nutzungscodes.	Seiten 2–6 fügenR,DundCfür Forschung und Entwicklung, DoD und kommerziell hinzu.	Die spätere Netzwerktabelle erfasst neben einer Adressklasse auch eine administrative Kategorie.
Übergang	Es wird keine vergleichbare Übergangsnotation erklärt.	Seite 2 erklärt, dass alte Netzwerknummern während Umstellungen mitT-Markierungen beibehalten werden.	Für Kontinuität könnten alte und neue Kennungen nebeneinander im veröffentlichten Datensatz bestehen müssen.
Voraussichtliche Zuteilungsautorität	Es wird kein multiinstitutionelles Zuteilungsschema abgedruckt.	Anhang A, Seiten 19–21, empfiehlt Zuständigkeiten für verschiedene Nutzungskategorien.	Eine gemeinsame Nachverfolgungsfunktion war konzeptionell von allen substanziellen Zuweisungsentscheidungen trennbar.
Berechtigung	Es wird kein allgemeines Kriterium für Netzwerkbewerber abgedruckt.	Seite 20 empfiehlt gateway-bezogene Nachweise für Forschungsbewerber.	Die vorgeschlagene Forschungspolitik umfasste mehr als Kollisionsprüfung.
Implementierung	Es erscheint kein vergleichbarer Anhang.	Seite 22 besagt, dass die Empfehlung noch nicht vollständig umgesetzt ist und Postel derzeit alle Zuweisungen koordiniert.	Empfehlung, Vereinbarung und Arbeitspraxis blieben getrennt.
Entscheidungsaufzeichnung	Es werden keine Gesamtzahlen der Anträge, Begründungen oder Ausnahmevermerke veröffentlicht.	Die erweiterte Richtlinie veröffentlicht sie immer noch nicht.	Die Dokumente zeigen erfolgreiche oder überlebende Einträge, nicht die vollständige Entscheidungsgrundgesamtheit.

Der Vergleich belegt einen dokumentarischen Wandel. Die nächste Frage ist, welche Art von Verwaltung jedes Wort und jede Tabelle erforderte.

„Zugewiesen“, „registriert“, „aktuell“ und „offiziell“ waren keine Synonyme

Die einleitende Anweisung in RFC 790 lädt nicht nur einen Entwickler ein, einen selbst gewählten Wert zu melden. Sie fordert auf, Postel zu kontaktieren, um „eine Nummernzuweisung zu erhalten“. Bevor ein neuer Wert sicher in einer gemeinsamen Liste erscheinen konnte, musste jemand von der Anfrage erfahren, auf Kollision prüfen, einen Wert auswählen oder bestätigen, das Ergebnis mitteilen und den Datensatz aktualisieren. Diese minimale Abfolge ist koordinierte Verwaltung.

Daraus folgt nicht, dass jede Serie eine gleichermaßen folgenreiche Entscheidung beinhaltete. Bei vielen Protokoll- oder Portanfragen könnte der wesentliche Akt darin bestanden haben, einen ungenutzten Codepunkt zu finden und die Interoperabilität zu wahren. Der Text liefert keine Grundlage für die Behauptung, dass die institutionellen Verdienste jedes Entwicklers bewertet wurden. Das Wort „Zuweisung“ bezeichnet einen Vorgang, aber sein bloßes Vorhandensein offenbart weder die Kriterien noch die Urteilstiefe dahinter.

Netzwerknummern sind anders, da RFC 820 sie mit administrativen Nutzungskategorien und einer empfohlenen Berechtigungsbedingung verknüpft. Anhang A besagt, dass innerhalb der Forschungs- und Entwicklungsgemeinschaft Netzkennungen nur solchen Antragstellern gewährt werden, die nachweisen, dass sie die Standard-BBN-Gateway-Software erwerben oder ein Gateway implementiert haben oder erwerben, das die Anforderungen des Exterior Gateway Protocol erfüllt. Er fügt hinzu, dass der Erwerb von Berkeley-BSD-4.2-UNIX-Software als Nachweis für Letzteres gelten könnte.

Die Formulierung geht über eine bloße Eindeutigkeitsprüfung hinaus. Sie knüpft eine empfohlene Zuteilung an den Nachweis technischer Bereitschaft. Sie bleibt jedoch Teil der empfohlenen Richtlinie, nicht Beweis einer bereits universell geltenden Betriebsregel. Der Anhang spezifiziert weder einen vollständigen Evidenzstandard, noch ein Entscheidungsverfahren, einen Berufungsprozess oder eine Aufzeichnung der unter dieser Bedingung bewerteten Anträge. Die letzte Seite stellt ausdrücklich fest, dass die Empfehlung noch nicht vollständig umgesetzt wurde.

„Aktuell“ erfüllt eine andere Funktion. Beide Dokumente erheben den Anspruch, aktuell zugewiesene Werte zu beschreiben, und nennen den Lesern, wo aktuelle Informationen zu erhalten sind. In diesem Zusammenhang ist Aktualität eine Behauptung über Synchronisation: Implementierer sollten in der Lage sein, eine gepflegte Referenz zu konsultieren, anstatt sich auf inkompatible private Listen zu verlassen. Es bedeutet nicht, dass die ursprüngliche Begründung jedes Eintrags, seine institutionelle Geschichte oder sein derzeitiger Inhaber vollständig dokumentiert ist.

RFC 820 verwendet „registriert“ in seinem Abschnitt über autonome Systeme. Das Exterior Gateway Protocol stellt ein 16-Bit-Feld zur Identifizierung autonomer Systeme bereit, und die Werte werden im Dokument registriert. Die anfängliche Tabelle ist nahezu leer: Null ist reserviert, Eins identifiziert die BBN-Gateways, die Werte Zwei bis 65.534 sind nicht zugewiesen und 65.535 ist reserviert. Hier beschreibt die Registrierung die gemeinsame Aufzeichnung einer Kennungsserie in einer frühen Phase.

Sie kann nicht unterschiedslos auf den Netzwerkanhang übertragen werden, wo Klassifikation und empfohlene Antragstellernachweise andere Überlegungen hinzufügen.

„Offiziell“ wird explizit in RFC 943, nicht in der einleitenden Statussprache von RFC 790 oder RFC 820. Diese spätere Formulierung beschreibt die Anerkennung innerhalb der ARPA-Internet-Community. Sie macht nicht jeden früheren Akt der Listenpflege zu einer formellen Regierungsentscheidung, noch begründet sie, dass ein Eintrag außerhalb der Gemeinschaft, für die der Bericht galt, dieselbe Bedeutung besaß.

Die Wörter identifizieren daher überlappende, aber trennbare Funktionen. Zuweisung kann Auswahl oder Bestätigung umfassen. Registrierung zeichnet einen Wert auf. Aktualität drückt Wartung aus. Der offizielle Status kennzeichnet eine anerkannte Stellung in einer definierten Betriebsgemeinschaft. Ihre Nähe in der Assigned-Numbers-Linie lässt sie nicht zu einer universellen Autorität verschmelzen.

Eine Veröffentlichung enthielt mehrere unterschiedliche Register

Der Titel „Assigned Numbers“ fasst mehrere Serien in einem Dokument zusammen, doch ihre Kollisionsprobleme und institutionellen Einsätze waren nicht austauschbar.

Eine Internet-Protokollnummer belegte ein Acht-Bit-Feld im IP-Header und identifizierte das nächste Protokoll, das von einem Paket getragen wurde. Die Koordinierung dieser Nummer ermöglichte es verschiedenen Implementierungen, das Feld konsistent zu interpretieren. RFC 820s Anhang A schlug vor, Teile des Protokollnummernraums für DoD-Standards, Forschungsnutzungen und kommerzielle, nationale oder internationale Standards zu reservieren. Das war Koordinierung über Protokollkennungen, nicht eine Zuweisung von Host-Adresskapazität an eine Organisation.

Eine Portnummer identifizierte einen Servicedienstkontaktpunkt am Ende einer logischen Verbindung. RFC 790 behandelte noch sowohl AHHP-Sockets als auch TCP-Ports, während RFC 820 eine Portliste präsentierte, die sich auf TCP und die Wiederverwendung mit UDP, wo möglich, konzentrierte. Die Zuweisung eines wohlbekannten Ports konnte einen Dienst implementationsübergreifend interoperabel machen. Sie machte den genannten Protokollautor oder Dienstkontakt nicht zum Inhaber eines Netzwerkblocks.

Netzwerknummern erfüllten eine andere Rolle. Sie identifizierten Netzwerke in der Internet-Adressarchitektur. Die gewählte Klasse bestimmte die Breite des lokalen Adressfeldes: 24 Bit für Klasse A, sechzehn für Klasse B und acht für Klasse C. Netzwerkzuweisungen unterschieden sich daher nicht nur als Etiketten, sondern auch in Adresskapazität und Routing-Behandlung. Der Kategoriecode, die Übergangsmarkierung und die Gateway-Bereitschaftsempfehlung in RFC 820 galten für diesen institutionell stärker differenzierten Vorgang.

Autonome Systemnummern stellten eine weitere eigenständige Serie dar. Ihr Zweck war es, Gruppen von Gateways für das Exterior Gateway Protocol zu identifizieren. Ihr Erscheinen in RFC 820 dokumentiert die frühe Entwicklung der Interdomain-Koordination; es liefert keine allgemeine Doktrin für die Netzwerknummernberechtigung.

ARPANET-Linknummern gehörten zur Host/IMP-Schnittstellenumgebung. Der Anhang von RFC 820 empfahl, unnötige Verwendungen zu beseitigen und Interoperabilitätsfragen zwischen den Schnittstellen zu untersuchen. Diese Aufgabe betraf ein anderes Protokollfeld und eine andere Menge operationeller Abhängigkeiten.

Aus dem bloßen Umstand, dass die Port-Tabellen namensbezogene Dienste enthalten, sollte nicht auf eine Namensregistrierung geschlossen werden. RFC 790 weist Port 42 einem Nameserver und Port 43 Whois zu. RFC 820 enthält diese Dienstkontakte und fügt Ports für Hostnamen- oder Mailbox-Nameserver hinzu. Dies sind Einträge zum Erreichen von Diensten, kein Register von Hostnamen oder Domains. Der Abschnitt mit den Personen ist ebenso ein Verzeichnis verantwortlicher Ansprechpartner, kein Namensregister oder Antragstellerverzeichnis.

DasFindmittel des Computer History Museum für die SRI ARC/NIC-Unterlagenverstärkt die institutionelle Unterscheidung. Es beschreibt die Pflege der ARPANET-Host-Tabelle und die späteren Namensübergänge durch das SRI Network Information Center als eigenständige Tätigkeit. Es gibt zudem an, dass die Verwaltung der Assigned Numbers und der globalen Adresszuteilung 1987 vom USC-ISI auf den SRI-NIC-Vertrag überging. Das Findmittel ist späterer archivischer Kontext, kein Beleg dafür, dass SRI die in den beiden RFCs beschriebene Zuweisungsfunktion von 1981–1983 ausübte.

Die Bündelung der Serien in einer Referenzpublikation ergab operationell Sinn. Entwickler konnten verwandte Konstanten und Kontakte an einem Ort finden. Doch das gemeinsame Format machte nicht jede aufgelistete Nummer zu einer Zuteilung gleicher Art. Aus dem Netzwerknummern-Anhang gezogene Governance-Schlussfolgerungen müssen an diesen Anhang gebunden bleiben, es sei denn, ein anderer Abschnitt liefert eigene Belege.

Administrative Kategorien ersetzten technische Klassen nicht

RFC 820 überlagert zwei verschiedene Klassifikationen. Die erste ist architektonisch: Klasse A, B und C definieren Adressformate. Die zweite ist administrativ:R,DundCkennzeichnen Forschung und Entwicklung, DoD und kommerzielle Nutzungen. Sie zu verwechseln, führt zu falschen Vergleichen.

Auf Seite 2 beschreibt der untersuchte RFC 820-Text korrekt, dass Klasse A eine führende Null hat und Klasse B das führende Muster10. Seine Prosa beschreibt die drei höchstwertigen Bits von Klasse C als1-0-0, aber das nebensstehende Diagramm zeigt1 1 0, und sein Klasse-C-Bereich beginnt bei 192, dessen höchstwertige Bits110sind. Auch RFC 790 druckt das Klasse-C-Muster als110. Der1-0-0-Ausdruck in RFC 820 ist daher ein interner Textfehler, kein Beleg für eine andere Adressarchitektur.

Die drei technischen Klassen enthielten 128, 16.384 bzw. 2.097.152 mögliche Netzwerknummernwerte, jeweils vor reservierten Endpunkten und anderen Ausschlüssen. Ihre lokalen Felder enthielten (2^{24}), (2^{16}) und (2^8) numerische Adresswerte pro Netzwerk. Diese Unterschiede machten die Wahl der Klasse folgenreich, aber keiner der beiden RFCs liefert Auslastungsmessungen der Hosts für die aufgeführten Netze.

Die administrativen Codes beantworten eine andere Frage: welche Nutzungskategorie das Dokument mit einer zugewiesenen Kennung verband. Ein Forschungscode impliziert weder eine kleine noch eine große Klasse. Eine kommerzielle Organisation konnte an einem Forschungsprojekt teilnehmen, während das Netz eines Auftragnehmers nach der Nutzung des Netzes klassifiziert werden konnte, nicht nach dem rechtlichen Charakter der Institution. Arbeitgeber eines Kontakts, Netzbeschreibung und Kategoriecode dürfen nicht als austauschbare Belege behandelt werden.

Anhang A empfiehlt, die verfügbaren Klassenbereiche auf die drei Nutzungen aufzuteilen. Für Klasse A weist er acht Netze der Forschung und Entwicklung, 24 dem DoD und 94 der kommerziellen Nutzung zu. Für Klasse B gibt er 1.024, 3.072 und 12.286 an. Für Klasse C druckt der Anhang 65.536 für die Forschung, 458.725 für DoD und 1.572.862 für die kommerzielle Nutzung.

Dies sind vorgeschlagene Zuteilungen, keine Beschreibung einer abgeschlossenen Verteilung. Die Arbeitstabelle auf Seite 6 meldet 26 zugewiesene Forschungs-Klasse-A-Kennungen, vier für Verteidigung und eine kommerzielle. Die 26 Forschungseinträge sind das 3,25-Fache der im Anhang empfohlenen Zuteilung von acht. Mehrere Einträge sind als alte Übergangsnummern markiert. Die Diskrepanz steht im Einklang mit der expliziten Aussage des Dokuments, dass die Implementierung noch nicht abgeschlossen ist.

Das Dokument enthält auch eine numerische Inkonsistenz. Die Zusammenfassung „Maximum Allowed“ auf Seite 6 gibt die Klasse-C-Verteidigungszuteilung als 458.752 an, während Anhang A auf Seite 20 458.725 druckt. Die Differenz beträgt 27 Kennungen.

Verwendet man die Zahl von Seite 6, ergeben die vorgeschlagenen Klasse-C-Kategorien in der Summe:

• 65.536 Forschungskennungen;
• 458.752 Verteidigungskennungen; und
• 1.572.862 kommerzielle Kennungen;

zusammen 2.097.150. Das entspricht dem Klasse-C-Netzwerknummernraum von 2.097.152 Werten nach Reservierung des ersten und letzten Wertes.

Verwendet man stattdessen die im Anhang A gedruckten 458.725, erhält man 2.097.123, was 27 unter der Summe von Seite 6 liegt. Das Dokument liefert keine Erklärung. Eine Rekonstruktion sollte beide gedruckten Angaben bewahren, anstatt eine stillschweigend zu korrigieren.

Anhang A empfiehlt ferner, dass experimentelle Netze, die betriebsbereit werden, nicht umnummeriert werden müssen, wenn eine Umnummerierung Härten verursachen würde. Ihre Kennungen könnten stattdessen vom Forschungs- in den Verteidigungs- oder kommerziellen Status wechseln. Die Gesamtzuteilungen der Kategorien sollten konstant bleiben, während bestimmte Kennungen ihren Zustand änderten. Daher rät der Anhang davon ab, die Kategorien als einfache zusammenhängende Partitionen zuzuweisen, und empfiehlt spezifische Zuweisungen, die über die verantwortlichen Stellen hinweg verfolgt werden.

Dies ist eine politische Empfehlung zu Klassifikation, Kontinuität und Koordination. Sie beweist nicht, wie ein bestimmtes Netz zu seiner vorhandenen Zeile gelangte. Ein Kategoriecode zeichnet das in der Tabelle gedruckte Ergebnis auf; er ist keine überlieferte Begründung.

Empfehlung, Vereinbarung und Arbeitspraxis im selben Anhang

Anhang A beginnt mit der Aussage, dass er Vereinbarungen zusammenfasst, die von DDN/PMO und DARPA bei einem Treffen im September 1982 erzielt wurden. Danach verwendet er wiederholt die Sprache der Empfehlung.

Für Netzkennungen empfiehlt der Text, dass die Zuweisungen für Forschungs-, Verteidigungs- und kommerzielle Nutzungen in die Zuständigkeit von DARPA, DCA PCCO/DDN bzw. des National Bureau of Standards fallen. Die numerischen Tabellen hingegen nennen ARPA als Forschungszuweiser und druckenTBDfür die Verteidigungs- und kommerziellen Zuweiser.

Drei institutionelle Zustände sind daher sichtbar. Die Agenturen hatten eine Vereinbarung erzielt, die ausreichte, um zusammengefasst zu werden. Das Dokument empfahl eine künftige Verteilung der Zuständigkeiten. Wichtige Zuständigkeiten auf Amtsebene blieben in den Tabellen ungeklärt.

Ein vierter Zustand erscheint auf Seite 22: die Arbeitspraxis. Der Implementierungsvermerk besagt, dass die Richtlinienempfehlung noch nicht vollständig umgesetzt wurde und Postel derzeit als Koordinator für alle Nummernzuweisungen fungiert. Welche institutionelle Aufteilung der Anhang auch vorsah – Antragsteller und Implementierer trafen immer noch auf eine zentrale Koordinierungsstelle.

Die Sprache zur Gateway-Bereitschaft muss innerhalb dieser Abfolge eingeordnet werden. Sie gibt an, was „die Richtlinie sein wird“ innerhalb der Forschungsgemeinschaft unter der empfohlenen Regelung. Sie ist ein direkter Beleg für eine vorgeschlagene Berechtigungsbedingung. Sie ist kein direkter Beleg dafür, dass jeder frühere Eintrag in RFC 790, jeder Eintrag in RFC 820 oder jede Art von Nummernanfrage bereits unter dieser Bedingung bearbeitet worden wäre.

Ebenso ist die Härtefallregelung eine empfohlene Übergangsregel. Sie zeigt, dass die Politikgestalter die betrieblichen Kosten einer Umnummerierung erkannten. Sie identifiziert nicht, welche mitTmarkierten Änderungen freiwillig, erforderlich, ausgehandelt oder aus Gründen vorgenommen wurden, die nichts mit der neuen Kategoriezuteilung zu tun hatten.

Der Anhang stützt dennoch eine bedeutende institutionelle Erkenntnis. Seine Autoren konnten die substanzielle Zuweisung von der zentralen Nachverfolgung unterscheiden. Verschiedene Stellen konnten Zuweisungen in verschiedenen Kategorien vornehmen, während DDN/PMO oder ein Beauftragter die kombinierte Aufzeichnung führte, um sicherzustellen, dass die Zuteilung im Rahmen der Empfehlung blieb. Der gemeinsame Aufzeichnungsführer musste nicht die alleinige Quelle jeder Entscheidung sein.

Diese Architektur barg auch ungelöste Probleme. Änderte ein Netz die Kategorie, musste jemand die Kategoriensalden aktualisieren. Überschritt ein Zuweiser seinen Betrag, wäre ein Korrektur- oder Ausnahmeverfahren nötig. Wenn zwei Stellen denselben Antrag als in ihre Zuständigkeit fallend betrachteten, bräuchte das System einen Weg, die Überschneidung aufzulösen. RFC 820 empfiehlt die Nachverfolgung, veröffentlicht aber keinen vollständigen Zuständigkeitskodex.

Das Dokument enthält somit eine administrative Theorie in Teilform: differenzierte Pools, mehrere mögliche Zuweiser, zentrale Koordination, Kontinuitätsschutz und technische Berechtigung für eine Kategorie. Es enthält auch Belege dafür, dass die Theorie und die tatsächliche Zuweisungsschnittstelle noch nicht zusammengefunden hatten.

Das Inventar zählen, ohne aus Zeilen Antragsteller zu machen

Die Netzwerktabellen können prüfen, wie sich der dokumentarische Wandel in den veröffentlichten Zuweisungen zeigte, aber nur, wenn drei Beobachtungseinheiten getrennt bleiben.

Einegedruckte Zeileist ein Zeilen- oder Bereichseintrag, wie er im Dokument erscheint. Sie kann einen einzigen Identifikator, Hunderte von Identifikatoren oder eine alte Nummer beschreiben, die während des Übergangs beibehalten wurde. Doppelte Zeilen bleiben gedruckte Zeilen.

Einexpandierter Netzwerkidentifikatorist eine klassenbasierte Netzwerknummer, die nach Erweiterung eines gedruckten Bereichs dargestellt wird. Der RFC 820-Bereich192.001.xxxbis192.004.xxxbeispielsweise steht für vier Werte des zweiten Oktetts multipliziert mit 256 Werten des dritten Oktetts, also 1.024 Klasse-C-Identifikatoren.

Eineeindeutige literale Identifikator-Zeichenketteist ein expandierter Identifikator, nachdem identische gedruckte Adresszeichenfolgen dedupliziert wurden, ohne zu raten, was eine scheinbare Sequenz aussagen sollte. Diese Einheit bewahrt Transkriptionskonflikte, statt sie unsichtbar zu korrigieren.

Keine dieser Einheiten ist ein Antragsteller, Empfänger, eine Organisation, aktive Route, ein Host oder ein Eigentumsanteil.

Die Klasse-A-Tabelle von RFC 790 druckt benannte Zuweisungszeilen für die Werte 001 bis 044, außer dass 013 ausdrücklich nicht zugewiesen ist. Das ergibt 43 benannte Zuweisungszeilen. Es ergeben sich nicht 43 unbestritten zugewiesene Identifikatoren. Die Zeile für 044 nennt AMPRNET, doch der unmittelbar folgende nicht zugewiesene Bereich beginnt ebenfalls bei 044 und läuft bis 126. Das Dokument liefert daher 42 eindeutige benannte Identifikatoren plus einen intern widersprüchlichen Identifikator, 044.

Klasse B enthält in RFC 790 keine benannte Zuweisung, ebenso wenig Klasse C. Diese Aussage beschreibt die Tabelle, nicht das Fehlen jedes kleineren Netzes weltweit. Die aufgelisteten Klasse-A-Netze umfassen mehrere Experimente, zugehörige Einrichtungen und Testnetze. Eine benannte Zeile ist kein Beleg für einen rechtlich unabhängigen Begünstigten.

RFC 820 liefert auf Seite 6 eine gedruckte Zusammenfassung der „Netzwerksummen“:

RFC 820 gedruckte Zusammenfassung	Klasse A	Klasse B	Klasse C	Gesamt
Forschung	26	19	1.033	1.078
Verteidigung	4	5	7	16
Kommerziell	1	0	2	3
Gesamt	31	24	1.042	1.097

Verwendet man diese gedruckte Zusammenfassung, entfallen auf die Forschung (1.078 / 1.097) oder 98,267 Prozent, gerundet 98,3 Prozent. Dies ist ein Ergebnis der gedruckten Zusammenfassung, nicht die Feststellung, dass 98,3 Prozent der Antragsteller oder Organisationen Forschungseinrichtungen waren.

Der dominierende Beitrag stammt aus einem einzelnen Bereich, der mit BBN-lokalen Netzen verbunden ist. Die Erweiterung von192.001.xxxbis192.004.xxxergibt (4 \times 256 = 1.024) Klasse-C-Identifikatoren. Diese 1.024 Identifikatoren machen (1.024 / 1.097) oder 93,345 Prozent, gerundet 93,3 Prozent, der gedruckten zugewiesenen Gesamtzahl des RFC aus.

Dieser Nenner ist explizit: 1.097 erweiterte Zuweisungen, wie sie die gedruckte Zusammenfassung darstellt. Das Verhältnis bedeutet nicht, dass BBN 1.024 separate Anträge stellte, 1.024 unabhängige Entscheidungen erhielt oder jedes Netz als extern geroutete Einheit nutzte. Das Dokument verknüpft einen Bereich mit „BBN local networks“, erklärt aber nicht die Antragshistorie oder Betriebstopologie dahinter.

Die literale Deduplizierung führt zu einem anderen Ergebnis. In der Klasse-C-Tabelle ist192.005.022für BRLNET2, BRLNET3, BRLNET4 und BRLNET5 gedruckt. Die Namen legen eine beabsichtigte Sequenz nahe, und der nächste nicht zugewiesene Bereich beginnt bei 192.005.026, aber eine literale Rekonstruktion kann 023, 024 und 025 nicht ersetzen, ohne dies als Korrektur zu kennzeichnen.

Dedupliziert man die vier Vorkommen von192.005.022, entfernt man drei doppelte Vorkommen aus der gedruckten Klasse-C-Gesamtzahl:

Rekonstruktion	Klasse A	Klasse B	Klasse C	Gesamt
RFC 820 gedruckte Zusammenfassung	31	24	1.042	1.097
Eindeutige literale Identifikatoren	31	24	1.039	1.094

Weil die wiederholten BRL-Zeilen als Verteidigung codiert sind, werden die eindeutigen literalen Kategoriensummen zu 1.078 Forschung, dreizehn Verteidigung und drei kommerziell, insgesamt 1.094. Die Forschungszahl bleibt 1.078; die Verteidigungszahl sinkt von sechzehn auf dreizehn.

Der Unterschied ist im Vergleich zum BBN-Bereich gering, aber methodisch entscheidend. Eine gedruckte Zusammenfassung kann als Behauptung der Quelle wiedergegeben werden. Eine Zählung eindeutiger Zeichenketten kann als separate literale Lesart wiedergegeben werden. Keine sollte als die andere dargestellt werden.

Übergangseinträge fügen eine weitere Komplikation hinzu. RFC 820 erklärt, dass alte Nummern mit einemTaufgeführt bleiben können, um Änderungen zu erleichtern. Ein Netz kann daher unter einer alten Klasse-A-Kennung und einer neueren Klasse-B-Kennung erscheinen, ohne zwei unabhängig situierte Empfänger zu repräsentieren. Beide zu zählen, kann für die operationelle Anerkennung richtig sein und für die Empfängeranalyse falsch.

Die Bewegung zwischen den Dokumenten ist dennoch sichtbar. RFC 790 enthält benannte Zeilen nur in der Klasse-A-Tabelle. RFC 820 enthält gemäß seiner Zusammenfassung eine Mischung aus 31 Klasse-A-, 24 Klasse-B- und 1.042 Klasse-C-Zuweisungen, zusammen mit expliziten Übergangsmarkierungen. Einige große frühere Identifikatoren waren ersetzt, aufgegeben oder vorübergehend beibehalten worden, während Identifikatoren kleinerer Klassen erschienen.

Diese Veränderung steht im Einklang mit stärker differenzierten Zuweisungsgrößen. Sie ist kein Beweis, dass Knappheit jede Änderung verursachte. Die Tabellen enthalten keine Reihen zur Host-Auslastung, keine Prognosen, Antragsformulare oder Entscheidungsgründe. Die Kapazität eines Klasse-A-Identifikators sagt aus, was das Adressformat erlaubte, nicht wie viele Adressen das benannte Netz nutzte oder warum Administratoren jene Klasse zum maßgeblichen Zeitpunkt wählten.

Der BBN-Bereich ist ein wichtiges Gegenbeleg gegen die einfache Erzählung einer einheitlichen Bevorzugung der größten verfügbaren Klasse. Ein bedeutender Akteur erscheint mit 1.024 kleinen Klasse-C-Identifikatoren sowie weiteren Einträgen. Die Tabellen erklären nicht, ob diese Anordnung Experimente, lokale Segmentierung, Routing-Praxis, administrative Bequemlichkeit oder einen anderen Zweck widerspiegelte. Sie zeigen jedoch, dass institutionelle Prominenz nicht mechanisch in jedem Fall eine Adressklasse hervorbrachte.

Die gedruckte kommerzielle Zahl ist ebenfalls leicht falsch zu lesen. Nur drei Zuweisungen sind in der Zusammenfassung auf Seite 6 als kommerziell codiert, während Anhang A eine große voraussichtliche kommerzielle Zuteilung vorschlägt. Dieser Kontrast könnte einen frühen Politikwechsel, den begrenzten Umfang des operativen Internets, die Codierungspraxis, die Nachfragezusammensetzung oder die unvollständige Implementierung widerspiegeln. Ohne Anträge und Korrespondenz kann man keinen Ausschluss oder keine Vorzugsbehandlung belegen.

Was spätere Zuteilungsdaten beheben können und was nicht

CAIDAsvisuelle Historie der IPv4-Zuteilungbietet eine nützliche Rekonstruktion der Adressraumveränderungen. Sie zeigt auch, warum spätere Visualisierungen den fehlenden Antragsteller-Nenner nicht liefern können.

CAIDA erklärt, dass der frühe Teil der Visualisierung aus Assigned-Numbers-RFCs stammt, während spätere Perioden IANA-Daten verwenden. Die Darstellung arbeitet mit/8-Granularität und platziert kleinere Zuteilungen innerhalb der größeren Adressblöcke, die sie enthalten. Sie weist darauf hin, dass der zugeteilte Adressraum zwischen RFC 790 und RFC 820 zurückging, teils weil einige Organisationen große Blöcke gegen kleinere Zuweisungen eintauschten.

Diese Darstellung ist mit den Übergangsmarkierungen in RFC 820 und dem Rückgang benannter Klasse-A-Einträge vereinbar. Sie ist keine unabhängige Bestätigung auf Empfängerebene, da ihre frühe Rekonstruktion auf der untersuchten RFC-Serie beruht. Die öffentliche Datumssequenz reicht von November 1977 bis Januar 1983, und die zugehörigen Sankey-Daten aggregieren Flüsse nach/8. Sie können nicht unabhängig jede Anfrage, Zuweisungsentscheidung oder jeden Empfängerwechsel zwischen RFC 790 und RFC 820 rekonstruieren.

Spätere Registereinträge bringen andere Probleme mit sich. CAIDAs separater Bericht zur IPv4-Verbrauchsmethodik merkt an, dass eine Aktualisierung von 1993 vielen Legacy-Zuteilungen ein Datum vom August 1993 zuwies, wo genaue frühere Daten nicht verfügbar waren. Nachfolgende Einträge können zudem organisatorische Umbenennungen, Übertragungen administrativer Verantwortung, Korrekturen und Statusänderungen erben.

Ein heutiger Registereintrag ist daher ein Beleg für einen fortbestehenden administrativen Zustand, nicht eine unberührte Aufzeichnung dessen, was ein Antragsteller 1981 beantragte. Er kann helfen, spätere Kontinuität nachzuverfolgen, kann aber allein weder den Grund, das Datum noch die Entscheidungseinheit wiederherstellen, die eine frühe Zeile hervorbrachte.

Die Tabellen können mehrere empirische Befunde stützen, ohne zu weit zu gehen:

• RFC 790 druckt 43 benannte Zeilen mit Klasse-A-Zuweisungen, von denen 42 eindeutig sind und eine mit dem folgenden nicht zugewiesenen Bereich kollidiert.
• Die gedruckte Zusammenfassung von RFC 820 meldet 1.097 Zuweisungen, aber die literale Deduplizierung ergibt 1.094 eindeutige Adresszeichenfolgen.
• 98,3 Prozent der gedruckten Gesamtzahl entfallen auf die Forschung, vor allem weil ein BBN-Bereich auf 1.024 forschungscodierte Klasse-C-Identifikatoren expandiert.
• Allein der BBN-Bereich macht 93,3 Prozent der 1.097 gedruckten Gesamtzuweisungen aus.
• Alte und neue Identifikatoren können nebeneinander bestehen, weil Übergangszeilen die betriebliche Kontinuität wahren.
• Die Arbeitstabelle entspricht noch nicht den empfohlenen Kategoriezuteilungen aus Anhang A.
• Die Dokumente enthalten keinen unmittelbaren Nenner für Anträge, Ablehnungen, Rücknahmen oder entmutigte Bewerbungen.

Diese Befunde zeigen, dass das Inventar administrativ erstellt wurde. Kategorien, Änderungen, Reservierungen und Übergänge mussten aufgezeichnet werden. Sie offenbaren nicht, ob ähnlich situierte Antragsteller ähnlich behandelt wurden, weil die relevante Grundgesamtheit und Entscheidungsakten fehlen.

Vier Erklärungen überdauern das Textdelta

Der Übergang von RFC 790 zu RFC 820 bietet mindestens vier zeitlich plausible Erklärungen.

Die erste ist Politikerstellung. Das Treffen vom September 1982 könnte eine explizitere Antwort auf ein wachsendes und sich diversifizierendes Internet hervorgebracht haben. Die neuen Kategoriecodes, die empfohlenen Poolgrößen, die Gateway-Bereitschaftsbedingung und die vorgeschlagene Aufteilung institutioneller Zuständigkeiten stützen diese Lesart. Anhang A stellt sie unmittelbar als empfohlene Richtlinie dar, die mit einer Agenturvereinbarung verbunden ist.

Die zweite ist Implementierungsmanagement. Der Übergang von der ARPANET-Umgebung zum ARPA-Internet, die Entwicklung von MILNET und die Umnummerierung oder Neuklassifizierung von Netzen könnten ein ausführlicheres Betriebsdokument erfordert haben, selbst ohne eine völlig neue Verteilungsphilosophie. DieT-Markierungen, Zuweisungen kleinerer Klassen und die Härtefallregelung passen zu dieser Erklärung.

Die dritte ist Dokumentationsbereinigung. Praktiken, die zuvor durch Korrespondenz oder Arbeitsbeziehungen verstanden wurden, könnten klarer niedergeschrieben worden sein. Gesamtzahlen, administrative Codes und Implementierungsvermerke könnten eine bessere Publikation widerspiegeln, nicht den Beginn jeder von ihnen beschriebenen Praxis.

Die vierte ist redaktionelle Vorliebe. Der Kopf des untersuchten RFC 820 zeigt einen zusätzlichen Namen, J. Vernon, obwohl der aktuelle Katalog allein Postel aufführt. Ein anderer Redaktionsprozess könnte explizitere institutionelle Prosa hervorgebracht haben, ohne eine proportionale Änderung in den täglichen Entscheidungen. Die Diskrepanz zwischen Katalog und Kopfzeile macht Autorschaft und redaktionelle Überlieferung zu einem Teil der Unsicherheit, nicht zu einer Grundlage für die Zuschreibung einer bestimmten politischen Rolle.

Diese Alternativen schließen einander nicht aus. Der Anhang könnte gleichzeitig eine Vereinbarung festhalten, einen Übergang leiten, bestehende Erwartungen formalisieren und einen ausladenderen redaktionellen Stil widerspiegeln.

Zeitgenössische Korrespondenz könnte sie unterscheiden. Das Findmittel des Computer History Museum weist auf Sitzungsnotizbücher, NIC-Fortschrittsberichte, Dateien zu Namensgebung und Adressierung, chronologische E-Mails, Arbeitsgruppenunterlagen und aus Auftragnehmerbeiträgen gesammelte monatliche Internetberichte hin. Es deutet darauf hin, dass potenziell relevante Kommunikation zwischen NIC-Mitarbeitern, Netzwerknutzern, Arbeitsgruppen und Bundesbehörden in Archivbeständen erhalten ist.

Das Findmittel legt den Inhalt einer bestimmten RFC-790-Anfrage, das Sitzungsprotokoll vom September 1982 oder die Redaktionskorrespondenz zu Anhang A nicht offen. Es belegt Existenz und Umfang von Sammlungen, nicht, was ungeöffnete Unterlagen belegen würden.

Eine gezielte Archivuntersuchung würde fragen, wer den Anhang verfasste, ob die Kategoriecodes bereits intern verwendet wurden, wie Gateway-Nachweise bewertet wurden, warum einige ZuweisungsinstanzenTBDblieben und ob bestimmte Umnummerierungen von den Netzen oder von Administratoren vorgeschlagen wurden. Solange die zugrunde liegenden Unterlagen diese Fragen nicht beantworten, stützt das Textdelta mehrere Erklärungen.

Kontakte offenbarten Verantwortung, ohne die Entscheidungskette festzulegen

Beide RFCs widmen verantwortlichen Personen erheblichen Raum. Ein eingeklammerter Code neben einem Protokoll oder Netzwerk verweist auf einen Namen, eine Zugehörigkeit und eine Mailbox im Personenabschnitt. Dies machte knappe Einträge operationell nutzbar. Ein Entwickler konnte jemanden fragen, was ein undokumentiertes Protokoll bedeutete oder wen man bezüglich eines benannten Netzes kontaktieren solle.

Das Wort „verantwortlich“ ist dennoch dehnbar. Die Person kann ein Protokollautor, Implementierer, Standortkontakt, Ingenieur, eine Dokumentationsquelle oder ein Registerpfleger sein. Die Spalte sagt nicht, ob diese Person die Nummer beantragte, genehmigte, das Netz kontrollierte oder nur genug wusste, um technische Fragen zu beantworten.

Die Mehrdeutigkeit zeigt sich in der Verwendung vonJBP, Postels Code. Er erscheint neben reservierten und nicht zugewiesenen Bereichen sowie zugewiesenen Protokollwerten. An diesen Stellen kann er keinen Begünstigten bezeichnen. Er markiert die Verantwortung für den Registrierungszustand oder die technische Definition. Andere Codes verweisen auf Personen, die mit benannten Netzen in Verbindung stehen. Eine Notation repräsentiert daher mehrere Beziehungen.

Der Kontaktapparat stützt eine begrenzte institutionelle Behauptung: Die frühe Koordination hing von identifizierbaren Experten und erreichbaren Mailboxen ab. Er stützt nicht die Behauptung, persönlicher Ruf sei ein Zuweisungskriterium gewesen. Noch zeigt er, ob Vorgespräche per elektronischer Post, Telefon, schriftlicher Korrespondenz oder in Treffen stattfanden.

Die Veröffentlichung in der gemeinsamen Liste verlieh einer Zuweisung operationelle Sichtbarkeit. Implementierer, die sich auf die Referenz stützten, konnten Duplizierungen vermeiden und den zuständigen Ansprechpartner identifizieren. Diese praktische Bedeutung begründet nicht, dass die Liste die technische Existenz jedes Netzes schuf oder einen Eigentumsanspruch verlieh. Das in Anhang A vorgeschlagene Modell mehrerer Zuweiser legt vielmehr nahe, dass Zuweisungsentscheidungen in mehreren Institutionen entstehen und zur Nachverfolgung zusammengeführt werden konnten.

Ein umfassenderes Verzeichnis war machbar, aber nicht kostenlos

Stellen Sie sich vor, der Netzwerknummern-Teil von RFC 820 hätte fünf zusätzliche Arten von Informationen bewahrt: die anwendbaren Berechtigungskriterien, einen kurzen Begründungscode, die Herkunft jeder Überarbeitung, die aggregierte Antragsdisposition und die zur Entscheidung über Ausnahmen befugte Stelle.

Dies hätte kein modernes öffentliches Antragssystem erfordert. Ein zeitgemäß machbarer Entwurf hätte einen separaten Anhang mit fester Breite, Papierformulare, E-Mail-Vorlagen und monatliche Gesamtsummen verwenden können. Begründungscodes hätten Gateway-Bereitschaft, Experiment, Übergang, Kategorieänderung und Korrektur unterscheiden können. Eine Revisionsspalte hätte die vorherige Kennung und das Gültigkeitsdatum aufzeichnen können. Sensible Details hätten in eingeschränkten Dateien verbleiben können, während die öffentliche Liste einen Minimalcode trug.

Solche Aufzeichnungen würden mehrere historische Fragen überprüfbar machen. Forscher könnten abgeschlossene Zuweisungen mit Rücknahmen oder Ablehnungen vergleichen, vom Antragsteller gewünschte Umnummerierungen von administrativ veranlassten unterscheiden und feststellen, ob das Gateway-Kriterium konsequent angewendet wurde. Eine benannte Ausnahmeinstanz würde zeigen, wo die vorgeschlagene Zuständigkeitsaufteilung endete.

Die zusätzliche Aufzeichnung würde auch Lasten mit sich bringen. Mitarbeiter müssten Eingangsdaten konsistent bewahren, Begründungswortschätze pflegen und Überarbeitungen über aufeinanderfolgende Ausgaben hinweg abgleichen. Experimentelle oder verteidigungsbezogene Anfragen könnten Details enthalten, die für eine öffentliche Freigabe ungeeignet sind. Regeln zur Schwärzung würden weitere Entscheidungen schaffen. DieTBD-Einträge in RFC 820 zeigen, dass die Benennung einer Ausnahmeinstanz selbst noch nicht abgeschlossen war.

Das SRI-NIC-Findmittel beschreibt Medieninkompatibilitäten, Schwierigkeiten bei der Druckproduktion und rasch veraltende Referenzpublikationen im weiteren Zeitraum. Da die Assigned-Numbers-Verwaltung bis 1987 bei USC-ISI verblieb, kann dieser Nachweis nicht den genauen Produktionsprozess oder die Kosten von RFC 790 und RFC 820 belegen. Er ist zeitgenössischer Kontext, der zeigt, dass reichhaltigere Dokumentation mit realen technischen und publizistischen Zwängen interagiert hätte.

Das kontrafaktische Szenario verändert daher die überlieferte Evidenz, nicht notwendigerweise die Legitimität der Institution. Kriterien können schlecht gestaltet sein, Begründungen formelhaft und aggregierte Zählungen können Personen auslassen, die nie erfuhren, wie man sich bewarb. Dennoch hätte der Unterschied zwischen einer Liste erfolgreicher Einträge und einer begründeten Entscheidungsaufzeichnung spätere Behauptungen über die Behandlung wesentlich leichter überprüfbar gemacht.

Nun kehren Sie den Entwurf um. Hätte Eindeutigkeit koordiniert werden können, ohne dass eine zentrale Stelle über jede Zuweisung entschied?

Die eigene Empfehlung von RFC 820 antwortet im Prinzip mit Ja. Forschungs-, Verteidigungs- und kommerzielle Kennungen könnten von verschiedenen Stellen zugewiesen werden, während ein bestimmter Koordinator die kombinierte Aufzeichnung nachverfolgte. Die Zeit unterstützte bereits elektronische Post, telefonische Koordination und regelmäßig aktualisierte Dokumente. Mehrere praktikable Regelungen waren denkbar.

Eine Option waren spezifische Zuweisungen, die an einen gemeinsamen Tracker gemeldet wurden, was Anhang A bevorzugte, weil Kennungen die Kategorie wechseln konnten. Eine andere waren partitionierte Pools, bei denen jeder Zuweiser einen definierten Bereich kontrollierte und regelmäßig Aktualisierungen veröffentlichte. Eine dritte war ein verteilter Satz nachvollziehbarer Listen, die nach Plan abgeglichen wurden, wobei temporäre Reservierungsnachrichten Kollisionen zwischen Ausgaben verhinderten.

Jede Alternative hatte Kosten. Einfache Partitionen erschwerten Kategorieänderungen und konnten ungenutzte Kennungen in einem Pool stranden lassen. Periodischer Abgleich brachte Verzögerung. Verteilte Listen riskierten widersprüchliche Zustände. Spezifische Zuweisung über einen gemeinsamen Tracker verringerte einiges Kollisionsrisiko, machte den Tracker aber operationell wichtig.

Der Punkt ist nicht, dass Dezentralisierung zwangsläufig überlegen gewesen wäre. Es geht darum, dass Kollisionskontrolle, substanzielle Berechtigung und Veröffentlichung geteilt werden konnten. Gemeinsame Nachverfolgung war operationell wertvoll und wurde innerhalb der Architektur von RFC 820 ausdrücklich empfohlen, aber ein einziges universelles Inventar war nicht der einzige logisch mögliche Entwurf.

Diese Unterscheidung ist wichtig für die Interpretation der Rolle des Koordinators. Wenn die vorgesehenen Kategoriezuweiser nicht festgelegt oder nicht verfügbar waren, könnte die Person, die die gemeinsame Aufzeichnung pflegte, in der Praxis weiterhin Anfragen bearbeiten. Diese Ausweitung könnte aus unvollständiger Implementierung resultieren, nicht aus einem Anspruch auf ausschließliche Autorität. RFC 820 dokumentiert genau eine solche Lücke: Verteilte Verantwortung wird empfohlen, während ein Koordinator immer noch alle Zuweisungen handhabt.

Bundesunterstützung erklärt Kapazität, nicht jede Regel

Der staatliche Rahmen kann erst hinzugefügt werden, nachdem die beiden Dokumente ihre eigenen Bedingungen festgelegt haben.

EinRechtsgutachten des U.S. Government Accountability Office (GAO) aus dem Jahr 2016stellt fest, dass Funktionen, die später unter dem Namen IANA zusammengefasst wurden, mit Arbeiten begannen, die von Postel an der UCLA geleitet und 1977 mit ihm zum USC-ISI verlagert wurden. Das GAO beschreibt die Arbeit als durch Forschungsprojekte des US-Verteidigungsministeriums finanziert und durch spätere DARPA-Verträge fortgeführt.

Dieser spätere Bericht stimmt mit den direkten Bezugnahmen von RFC 820 auf DARPA/IPTO, DDN/PMO und das Treffen vom September 1982 überein. Er hilft zu erklären, warum ein globales technisches Inventar ein administratives Zentrum in den Vereinigten Staaten hatte und warum die vorgeschlagene Richtlinie zwischen Forschungs-, Verteidigungs- und kommerziellen Nutzungen unterschied.

Das GAO gibt auch an, die betreffenden DARPA-Verträge aus den 1970er- bis 1990er-Jahren nicht erlangen zu können. Seine detaillierteren vertraglichen Nachweise betreffen spätere Zeiträume, und seine Rechtsfrage entstand Jahrzehnte nach RFC 790 und RFC 820.

Das Gutachten kann daher weder die Klausel eines fehlenden Vertrags von 1981, die auf eine bestimmte Anfrage angewandten Kriterien noch den von jedem Beteiligten verstandenen Autoritätsumfang belegen. Bundesförderung erklärt institutionelle Kapazität und Kontext. Sie beweist allein weder das Eigentum an Kennungen, das universelle Einverständnis noch die Legitimität jeder administrativen Entscheidung.

Die primäre Evidenz bleibt enger. RFC 790 benennt einen Koordinator für Zuweisungen. RFC 820 fügt eine Agenturvereinbarung hinzu, eine empfohlene Aufteilung des Nummernraums, voraussichtliche institutionelle Zuständigkeiten, eine vorgeschlagene Forschungsberechtigungsbedingung und einen Vermerk zur unvollständigen Umsetzung. Die spätere Regierungsgeschichte bestätigt das Umfeld, macht diese Aussagen aber nicht zu einer umfassenden Charta.

Was die Spalten letztlich belegen

Die Politik in einer Adressliste erscheint nicht allein deshalb, weil die Liste Identifikatoren mit unterschiedlichen technischen Kapazitäten verteilt. Sie wird sichtbar, wenn das Dokument Klassifikation, Berechtigung, Übergang, institutionelle Verantwortung und die Konsequenzen des Vertrauens auf eine gepflegte gemeinsame Aufzeichnung zeigt.

RFC 790 etabliert eine konzentrierte Koordinierungsschnittstelle. Mehrere Nummernserien wurden gemeinsam veröffentlicht, Entwickler wurden an einen namentlich genannten Zuweisungskontakt verwiesen und die resultierenden Werte als aktuelle Betriebsinformationen präsentiert. Seine Netzwerktabelle verzeichnet eine gemischte Menge von Forschungs-, Regierungs-, Militär-, öffentlichen Daten- und kommerziellen Netzen, gibt aber kein allgemeines Bewerberkriterium oder eine Aufteilung der Zuweisungsverantwortung an.

RFC 820 fügt eine stärker gegliederte administrative Schicht hinzu. Er klassifiziert Netzkennungen nach Nutzung, bewahrt alte Nummern während Übergängen, druckt Zuweisungssummen und legt empfohlene Kategoriezuteilungen fest. Er schlägt gateway-bezogene Nachweise für Forschungsbewerber vor, erlaubt einem Netz den Kategoriewechsel ohne Umnummerierung, wenn dies Härten verursachen würde, und stellt sich Zuweisungen vor, die von mehreren Institutionen unter einer gemeinsamen Nachverfolgungsregelung vorgenommen werden.

Dasselbe Dokument verhindert, dass diese Empfehlungen mit abgeschlossener Praxis verwechselt werden. Verteidigungs- und kommerzielle Zuweiser bleiben in den numerischen TabellenTBD. Die Arbeitszuweisungen entsprechen nicht der empfohlenen Klasse-A-Verteilung. Der abschließende Implementierungsvermerk besagt, dass Postel immer noch alle Zuweisungen koordiniert.

Die Tabellen widersetzen sich auch einer einfachen distributiven Erzählung. RFC 790s Wert 044 ist intern widersprüchlich. RFC 820 wiederholt eine literale Klasse-C-Adresse viermal und druckt inkompatible Verteidigungs-Klasse-C-Zuteilungssummen. Seine Zusammenfassung von 1.097 Zuweisungen wird von einem 1.024 Identifikatoren umfassenden BBN-Bereich dominiert. Übergangseinträge können dasselbe Netz unter alter und neuer Nummer zählen. Dies sind Betriebsaufzeichnungen mit identifizierbaren redaktionellen und Zählproblemen, kein sauberer Datensatz von Antragstellern.

Die Dokumente stützen folglich den Schluss, dass die Koordination von Netzwerknummern mehr als passive Transkription umfasste. Technische Eindeutigkeit musste gewahrt werden, aber Kategoriezuweisung, Übergangsbehandlung und die vorgeschlagene Bereitschaftsbedingung erforderten administrative Beurteilung. Diese Beurteilung operierte innerhalb eines bundesgestützten institutionellen Rahmens und lief im untersuchten RFC 820-Text immer noch über einen einzigen Arbeitskoordinator.

Sie stützen auch eine weniger zentralisierende Schlussfolgerung. RFC 820 setzte gemeinsame Nachverfolgung nicht mit ausschließlicher substanzieller Zuweisungsbefugnis gleich. Seine empfohlene Architektur erlaubte, dass Entscheidungen in mehreren Institutionen entstanden, während eine Stelle die kombinierte Zuteilung überwachte. Der Entwurf war unvollkommen, aber die konzeptionelle Unterscheidung ist vorhanden.

Die verbleibende Unsicherheit ist keine nebensächliche Einschränkung. Die öffentlichen Listen enthalten keine Antragspopulation, Ablehnungszahlen, Rücknahmehistorie, Nutzungsreihen oder Begründungen für jede Zuweisung. Das verfügbare Findmittel weist auf potenziell relevante Korrespondenz hin, offenbart aber nicht deren Inhalt. Die Dokumente können nicht zeigen, ob das kompakte Format aus Bequemlichkeit, Publikationsbeschränkungen, überkommener Konvention, bewusstem Minimalismus oder einem anderen Grund resultierte.

Noch begründen die Tabellen eine ausgereifte Knappheitsdoktrin. Sie zeigen endliche Klassenbereiche, reservierte Werte, Kategoriezuteilungen und Bewegung zwischen Adressgrößen. Sie zeigen nicht, dass Knappheit eine bestimmte Zuweisung motivierte oder dass ein Antragsteller deswegen abgelehnt wurde. Die spätere Adresserschöpfung erhöhte die Konsequenzen früherer Verteilungen, ohne deren ursprüngliche Motive zu rekonstruieren.

Was überlebt, ist eine dokumentierte administrative Fähigkeit mit echten operationellen Auswirkungen. Die Listen koordinierten Werte, machten bestimmte Zuweisungen sichtbar, klassifizierten Netze und halfen, Kontinuität während des Wandels zu wahren. Die Abhängigkeit von dieser Aufzeichnung konnte ihre Pflege folgenreich machen, selbst wenn der Aufzeichnungsführer nicht beanspruchte, die Legitimität jedes Netzes zu erschaffen.

Unter der Leselampe besteht der wesentliche Unterschied zwischen den beiden Dokumenten daher nicht darin, dass die Politik 1983 plötzlich in die Tabelle eindrang. Es ist, dass RFC 820 mehr von der administrativen Maschinerie lesbar machte: eine Vereinbarung, Nutzungskategorien, voraussichtliche Zuweiser, eine Berechtigungsempfehlung, Übergangsregeln und das Eingeständnis, dass die Umsetzung hinter dem Entwurf zurückblieb.

Diese Maschinerie kann beschrieben werden, ohne ihren Betreibern verborgene Motive zuzuschreiben. Ihre distributiven Konsequenzen können gemessen werden, ohne Bereiche in Antragsteller zu verwandeln. Ihre Autorität kann untersucht werden, ohne anzunehmen, dass eine saubere Spalte ein Beweis für Legitimität oder Verschleierung sei. Die haltbarste Lehre der Zwei-Dokumente-Archäologie ist, dass ein technisches Inventar ein unverzichtbarer Beleg dafür sein mag, was ein Koordinierungssystem anerkannte, während es ein unvollständiger Beleg dafür bleibt, wie, warum und von wem die Anerkennung entschieden wurde.