RFC 790 und die versteckte Politik in einer Adressliste

Zusammenfassung

• RFC 790 legt direkt fest, dass mehrere Nummernserien als aktuelle betriebliche Referenz geführt wurden und dass Entwickler angewiesen wurden, sich für Zuweisungen an Jon Postel zu wenden, veröffentlicht jedoch keine allgemeine Netzwerkberechtigungsregel oder Aufteilung der Zuweisungsbefugnis.
• RFC 820 fügt Forschungs-, Verteidigungs- und kommerzielle Kategorien, eine empfohlene Verteilung des Netzwerknummernraums, eine vorgeschlagene Gateway-Bereitschaftsbedingung für Forschungsbewerber und eine voraussichtliche Aufteilung der Zuständigkeiten zwischen Institutionen hinzu.
• RFC 820 stellt auch fest, dass seine Empfehlung noch nicht vollständig umgesetzt wurde 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 zeigen Zuweisungen, Übergänge und interne Inkonsistenzen, nicht die Gesamtheit der Bewerber. Ohne Antrags-, Ablehnungs-, Rückzugs-, Nutzungs- und zeitgenössische Korrespondenzunterlagen können sie keine Behandlung von Bewerbern, Verteilungsmotive oder eine Absicht zur Verschleierung von Entscheidungen belegen.

Legen Sie die erste Seite von zwei Dokumenten mit Festbreitenschrift unter dieselbe Leselampe. Auf Seite 1 vonRFC 790vom September 1981 besagt der Einführungsparagraph, 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 vom selben Koordinator vorgenommen, vorbehaltlich einer Vereinbarung zwischen DARPA/IPTO und DDN/PMO, die in Anhang A dokumentiert ist.

Der hinzugefügte Satz ist klein genug, um in einem von Zahlenspalten dominierten Dokument zu verschwinden. Anhang A ist nicht klein. Er berichtet über Vereinbarungen, die auf einem Treffen im September 1982 erzielt wurden, empfiehlt die Aufteilung des Netzwerknummernraums auf Forschungs- und Entwicklungs-, Verteidigungs- und kommerzielle Nutzungen, benannte voraussichtliche institutionelle Verantwortlichkeiten, schlägt eine Berechtigungsbedingung für Forschungsnetzwerke vor und endet mit der Feststellung, dass die Regelung noch nicht vollständig umgesetzt ist.

Die Gegenüberstellung wirft eine präzise Frage auf. Hat das spätere Dokument eine Autorität offengelegt, die in der früheren Bestandsaufnahme unsichtbar gewesen war? Hat es eine neue Zuteilungspolitik angekündigt, eine sich bereits in der Praxis entwickelnde Regelung dokumentiert, den Übergang zu einer anderen Netzwerkarchitektur verwaltet oder einfach nur einen vollständigeren redaktionellen Bericht über die Arbeit geliefert, die immer Koordination erforderte? Die Seiten erlauben es, einige dieser Möglichkeiten zu testen. Sie erlauben keine Wahl zwischen ihnen allein anhand des Layouts.

Dies ist daher keine Behauptung, dass eine technische Tabelle heimlich für das Internet Gesetze erlassen hat. Es ist eine Untersuchung darüber, was geschehen musste, bevor ein Eintrag Teil einer gemeinsamen betrieblichen 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. Die Aufzeichnung eines Ports ist nicht gleichbedeutend mit der Entscheidung, ob ein experimentelles Netzwerk betriebsbereit geworden ist.

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

Zwei Artefakte, ein Katalogunterschied

RFC 790 ist ein 15-seitiges Dokument der Network Working Group, das J. Postel vom Information Sciences Institute der University of Southern California zugeschrieben wird 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, sich für eine Zuweisung an Postel zu wenden.

Das Dokument durchläuft zugewiesene Netzwerknummern, Internet-Versionsnummern, Internet-Protokollnummern, Port- oder Socketnummern und ARPANET-Linknummern. Es folgen Referenzen und ein Verzeichnis der verantwortlichen Personen. Eingeklammerte Codes neben Einträgen verweisen auf Dokumente oder benannte Kontakte. Das Formular dient mindestens drei unmittelbaren Zwecken: Vermeidung von Nummernkollisionen, Mitteilung an Implementierer, was ein Wert bedeutet, und Bereitstellung eines Ansprechpartners, wenn die knappe Zeile nicht ausreicht.

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

Der Netzwerknummernabschnitt umfasst die Seiten 2 bis 4. Er erklärt die drei Adressklassen und gibt ihre Bit-Layouts an. Klasse A verwendet eine führende Null, sieben Netzwerknummernbits und ein 24-Bit-Lokalfeld. Klasse B verwendet das high-order-Muster10, vierzehn Netzwerknummernbits und ein 16-Bit-Lokalfeld. Klasse C verwendet110, einundzwanzig Netzwerknummernbits und ein acht-Bit-Lokalfeld. Dies waren technische Kategorien mit radikal unterschiedlichen Kapazitäten, aber die Existenz unterschiedlicher Kapazitäten an sich belegt nicht, wie Anträge bewertet wurden oder ob Konservierung der Grund für eine Zuweisung war.

Die benannten Klasse-A-Zeilen bilden eine gemischte und unvollständige Momentaufnahme. Sie umfassen Forschungsnetzwerke, Paketfunk-Experimente, militärische Einrichtungen, öffentliche Datennetze, Universitäten, Auftragnehmer und kommerzielle Betreiber in mehreren Ländern. Die Tabelle identifiziert nicht das Universum, aus dem diese Einträge stammen. Sie ist keine Volkszählung von Netzwerken, die Identifikatoren wollten, keine Liste von Antragstellern und keine 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 sagt Januar 1983. Der aktuelleRFC-Editor-Katalogeintragbezeichnet RFC 820 dagegen als „Assigned numbers, August 1982“ und listet nur J. Postel. Diese Analyse identifiziert Passagen nach dem Kopf und den Seitenzahlen des untersuchten Textes, während sie den Katalogunterschied bewahrt. Die verfügbaren Quellen rechtfertigen es nicht, stillschweigend eine Datums- und Autorschaftskonvention als Korrektur der anderen zu wählen.

RFC 820 behält die frühere Bestandsfunktion 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 öffentliche Datennetz-Zuordnungen und erweitert die Netzwerktabellen wesentlich. Am wichtigsten ist hier, dass Seite 1 die Nummernzuteilung der DARPA/IPTO–DDN/PMO-Vereinbarung unterwirft, während die Seiten 19 bis 22 die resultierenden Empfehlungen und den Implementierungshinweis wiedergeben.

Beide RFCs werden jetzt als Historic im Legacy-Stream klassifiziert. RFC 790 wurde von RFC 820 abgelöst, und RFC 820 wurde von RFC 870 abgelöst. Diese aktuellen Klassifizierungen bedeuten nicht, dass die Dokumente bei ihrer Verwendung ungültig oder irrelevant waren. Eine regelmäßige Registry-Veröffentlichung wird veraltet, weil sich Zuweisungen und Praktiken ändern. Spätere Veralterung ist Teil dieses dokumentarischen Lebenszyklus, keine nachträgliche Annullierung der früheren Momentaufnahme.

Ein späterer Vergleich hilft, die Grenze zu definieren.RFC 943, veröffentlicht im April 1985, beschreibt sich selbst explizit als offiziellen Statusbericht für Nummern, die in Protokollen in der ARPA-Internet-Community verwendet werden. Es unterscheidet auch 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 die Sprach- und Klassifikationsapparatur sich weiterentwickelte.

Die entscheidenden Unterschiede zwischen den beiden Hauptartefakten können komprimiert werden, ohne vorzutäuschen, dass jeder Unterschied eine Ursache hat:

Der Vergleich stellt dokumentarische Veränderung fest. Die nächste Frage ist, welche Art von Verwaltung jedes Wort und jede Tabelle erforderte.

„Assigned“, „registered“, „current“ und „official“ waren keine Synonyme

Die einleitende Anweisung in RFC 790 tut mehr, als einen Entwickler einzuladen, einen selbst gewählten Wert zu melden. Sie besagt, man solle Postel kontaktieren, „um eine Nummer zugewiesen zu bekommen“. 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 die Aufzeichnung aktualisieren. Diese Mindestabfolge ist koordinierte Verwaltung.

Daraus folgt nicht, dass jede Serie eine gleichermaßen folgenreiche Entscheidung beinhaltete. Bei vielen Protokoll- oder Port-Anfragen bestand der wesentliche Akt möglicherweise darin, einen ungenutzten Codepunkt zu finden und die Interoperabilität aufrechtzuerhalten. Der Text liefert keine Grundlage für die Behauptung, dass die institutionellen Meriten jedes Entwicklers bewertet wurden. Das Wort „assignment“ bezeichnet eine Operation, aber seine bloße Anwesenheit offenbart nicht die Kriterien oder die Tiefe des Urteils dahinter.

Netzwerknummern sind anders, weil RFC 820 sie mit administrativen Nutzungskategorien und einer empfohlenen Berechtigungsbedingung verbindet. Anhang A sagt, dass innerhalb der Forschungs- und Entwicklungsgemeinschaft Netzwerkidentifikatoren nur an Antragsteller vergeben werden, die nachweisen, dass sie die standardisierte BBN-Gateway-Software beschaffen oder ein Gateway implementiert haben oder beschaffen, das die Anforderungen des Exterior Gateway Protocol erfüllt. Es fügt hinzu, dass die Beschaffung von Berkeley BSD 4.2 UNIX-Software als Nachweis für Letzteres gelten könnte.

Der Wortlaut ist stärker als eine bloße Einzigartigkeitsprüfung. Er macht eine empfohlene Gewährung von Nachweisen technischer Bereitschaft abhängig. Aber er bleibt Teil der empfohlenen Politik, kein Beweis für eine bereits universelle Betriebsregel. Der Anhang spezifiziert keinen vollständigen Beweisstandard, keine Entscheidungsmethode, kein Berufungsverfahren und keine Aufzeichnung von Anträgen, die unter der Bedingung bewertet wurden. Die letzte Seite sagt ausdrücklich, dass die Empfehlung noch nicht vollständig umgesetzt wurde.

„Current“ erfüllt eine andere Funktion. Beide Dokumente behaupten, aktuell zugewiesene Werte zu beschreiben, und sagen den Lesern, wo aktuelle Informationen bezogen werden können. In diesem Zusammenhang ist Aktualität eine Behauptung über Synchronisierung: 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, die institutionelle Geschichte oder der gegenwärtige Inhaber jedes Eintrags vollständig dokumentiert ist.

RFC 820 verwendet „registered“ 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 fast 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 Identifikatorserie in einem frühen Stadium.

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

„Official“ wird explizit in RFC 943, nicht im einleitenden Status-Sprache von RFC 790 oder RFC 820. Diese spätere Formulierung beschreibt die Anerkennung innerhalb der ARPA-Internet-Community. Sie macht nicht jede frühere Handlung der Listenpflege gleichbedeutend mit einer formellen Regierungsentscheidung, noch legt sie fest, dass ein Eintrag außerhalb der Gemeinschaft, für die der Bericht betrieben wurde, die gleiche Bedeutung hatte.

Die Wörter identifizieren daher überlappende, aber trennbare Funktionen. Assignment kann Auswahl oder Bestätigung beinhalten. Registration zeichnet einen Wert auf. Currentness drückt Wartung aus. Official status identifiziert anerkannten Status 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 ungleiche Registries

Der Titel „Assigned Numbers“ fasst mehrere Serien in einem Dokument zusammen, aber 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 erlaubte es verschiedenen Implementierungen, das Feld konsistent zu interpretieren. Anhang A von RFC 820 schlug vor, Teile des Protokollnummernraums für DoD-Standards, Forschung und kommerzielle, nationale oder internationale Standards zu reservieren. Das war Koordination über Protokollidentifikatoren, keine Zuteilung von Host-Adresskapazität an eine Organisation.

Eine Portnummer identifizierte einen Dienstkontaktpunkt am Ende einer logischen Verbindung. RFC 790 diskutierte noch sowohl AHHP-Sockets als auch TCP-Ports, während RFC 820 eine Portliste präsentierte, die sich auf TCP und Wiederverwendung mit UDP konzentrierte, wo möglich. Die Zuweisung eines bekannten Ports könnte einen Dienst über Implementierungen hinweg interoperabel machen. Sie machte den benannten Protokollautor oder Dienstkontakt nicht zum Inhaber eines Netzwerkblocks.

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

Autonome Systemnummern waren eine weitere eigenständige Serie. Ihr Zweck war die Identifizierung von Gruppen von Gateways für das Exterior Gateway Protocol. Ihr Erscheinen in RFC 820 dokumentiert die frühe Entwicklung der Interdomänenkoordination; 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 eliminieren und Interoperabilitätsfragen zwischen Schnittstellen zu untersuchen. Diese Aufgabe betraf ein anderes Protokollfeld und eine andere Reihe betrieblicher Abhängigkeiten.

Namensregistrierung sollte nicht allein daraus abgeleitet werden, dass die Porttabellen namensbezogene Dienste enthalten. RFC 790 weist Port 42 einem Nameserver und Port 43 Whois zu. RFC 820 enthält diese Dienstkontakte und fügt Hostnamen- oder Mailbox-Nameserver-Ports hinzu. Dies sind Einträge für die Erreichbarkeit von Diensten, kein Register von Hostnamen oder Domänen. Der Personenabschnitt ist ebenfalls ein Verzeichnis verantwortlicher Kontakte, kein Namensregister oder Antragstellerverzeichnis.

DasFindmittel des Computer History Museum für die SRI ARC/NIC-Aufzeichnungenverstärkt die institutionelle Unterscheidung. Es beschreibt die Pflege der ARPANET-Hosttabelle und spätere Namensübergänge durch das SRI Network Information Center als separate Aktivität. Es stellt auch fest, dass die Verwaltung von Assigned Numbers und die globale Adresszuteilung 1987 von USC-ISI zum SRI-NIC-Vertrag wechselten. Das Findmittel ist späterer Archivkontext, kein Beweis dafür, dass SRI die Zuweisungsfunktion von 1981–1983 betrieb, die in den beiden RFCs beschrieben wird.

Die Gruppierung der Serien in einer Referenzpublikation ergab betrieblichen Sinn. Entwickler konnten verwandte Konstanten und Kontakte an einem Ort finden. Doch das gemeinsame Format machte nicht jede aufgeführte Nummer zu einer Gewährung derselben Art. Governance-Schlussfolgerungen, die aus dem Netzwerknummernanhang gezogen werden, müssen mit diesem Anhang verbunden bleiben, es sei denn, ein anderer Abschnitt liefert seine eigenen Beweise.

Administrative Kategorien ersetzten keine technischen Klassen

RFC 820 überlagert zwei verschiedene Klassifikationen. Die erste ist architektonisch: Klasse A, B und C definieren Adressformate. Die zweite ist administrativ:R,DundCidentifizieren Forschung und Entwicklung, DoD und kommerzielle Nutzungen. Wenn man sie verwechselt, entstehen falsche Vergleiche.

Auf Seite 2 beschreibt der untersuchte RFC 820-Text Klasse A korrekt mit einer führenden Null und Klasse B mit dem führenden Muster10. Seine Prosa beschreibt die drei höchstwertigen Bits von Klasse C als1-0-0, aber das nebenstehende Diagramm zeigt1 1 0, und der Klassen-C-Bereich beginnt bei 192, dessen höchstwertige Bits110sind. Auch RFC 790 druckt das Klassen-C-Muster als110. Die Phrase1-0-0in RFC 820 ist daher ein interner Textfehler, kein Beweis für eine andere Adressarchitektur.

Die drei technischen Klassen enthielten jeweils 128, 16.384 und 2.097.152 mögliche Netzwerknummernwerte, bevor reservierte Endpunkte und andere Ausschlüsse berücksichtigt wurden. 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 RFCs liefert Host-Nutzungsmessungen für seine aufgeführten Netzwerke.

Die administrativen Codes beantworten eine separate Frage: Welcher Nutzungskategorie das Dokument einen zugewiesenen Identifikator zuordnet. Ein Forschungscode impliziert keine kleine oder große Klasse. Eine kommerzielle Organisation konnte an einem Forschungsprojekt teilnehmen, während das Netzwerk eines Auftragnehmers nach der Nutzung des Netzwerks und nicht nach dem rechtlichen Charakter der Institution klassifiziert werden konnte. Der Arbeitgeber eines Kontakts, die Netzwerkbeschreibung und der Kategoriecode können nicht als austauschbare Beweise behandelt werden.

Anhang A empfiehlt, die verfügbaren Klassenräume auf die drei Nutzungen aufzuteilen. Für Klasse A gibt er acht Netzwerke an Forschung und Entwicklung, 24 an DoD und 94 an kommerzielle Nutzung. Für Klasse B gibt er 1.024, 3.072 und 12.286. Für Klasse C druckt der Anhang 65.536 für Forschung, 458.725 für DoD und 1.572.862 für kommerzielle Nutzung.

Das sind vorgeschlagene Zuteilungen, keine Beschreibung einer abgeschlossenen Verteilung. Die Arbeitstabelle auf Seite 6 meldet 26 zugewiesene Forschungs-Klasse-A-Identifikatoren, vier Verteidigungs- und einen kommerziellen. Die 26 Forschungs-Einträge sind das 3,25-fache der empfohlenen Zuteilung von acht im Anhang. Mehrere Einträge sind als alte Übergangsnummern markiert. Die Diskrepanz ist konsistent mit der ausdrücklichen Aussage des Dokuments, dass die Implementierung unvollständig bleibt.

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

Unter Verwendung der Zahl von Seite 6 summieren sich die vorgeschlagenen Klassen-C-Kategorien auf:

• 65.536 Forschungsidentifikatoren;
• 458.752 Verteidigungsidentifikatoren; und
• 1.572.862 kommerzielle Identifikatoren;

für eine Gesamtzahl von 2.097.150. Das stimmt mit dem 2.097.152-wertigen Klassen-C-Netzwerknummernraum überein, nachdem der erste und der letzte Wert reserviert sind.

Die Verwendung von 458.725 aus Anhang A ergibt stattdessen 2.097.123, was 27 weniger als die Gesamtzahl von Seite 6 ist. Das Dokument liefert keine Erklärung. Eine Rekonstruktion sollte beide gedruckten Angaben bewahren, anstatt eine stillschweigend zu korrigieren.

Anhang A empfiehlt ferner, dass experimentelle Netzwerke, die betriebsbereit werden, nicht umnummeriert werden müssen, wenn die Umnummerierung eine Härte verursachen würde. Ihre Identifikatoren könnten stattdessen vom Forschungs- in den Verteidigungs- oder kommerziellen Status wechseln. Die gesamten Kategoriezuteilungen sollten konstant bleiben, während bestimmte Identifikatoren den Zustand ändern. Der Anhang rät daher 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 zur Klassifikation, Kontinuität und Koordination. Sie beweist nicht, wie ein bestimmtes Netzwerk seine bestehende Zeile erhalten hat. Ein Kategoriecode zeichnet das in der Tabelle gedruckte Ergebnis auf; er ist keine überlebende Begründung.

Empfehlung, Vereinbarung und Arbeitspraxis belegten denselben Anhang

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

Bei Netzwerkidentifikatoren empfiehlt der Text, dass Zuweisungen für Forschungs-, Verteidigungs- und kommerzielle Nutzungen in die Verantwortung von DARPA, DCA PCCO/DDN bzw. dem National Bureau of Standards fallen. Die numerischen Tabellen nennen jedoch ARPA als Forschungszuweiser und druckenTBDfür die Verteidigungs- und kommerziellen Zuweiser.

Drei institutionelle Zustände sind daher sichtbar. Die Agenturen hatten eine ausreichende Vereinbarung getroffen, um zusammengefasst zu werden. Das Dokument empfahl eine zukünftige Verteilung der Verantwortlichkeiten. Wichtige Verantwortlichkeiten auf Büroebene blieben in den Tabellen ungelöst.

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

Die Sprache der Gateway-Bereitschaft muss innerhalb dieser Sequenz verortet werden. Sie besagt, was „die Politik“ innerhalb der Forschungsgemeinschaft unter der empfohlenen Regelung „sein wird“. Sie ist ein direkter Beweis für eine vorgeschlagene Berechtigungsbedingung. Sie ist kein direkter Beweis dafür, dass jeder frühere Eintrag in RFC 790, jeder Eintrag in RFC 820 oder jede Art von Nummernaufforderung bereits unter dieser Bedingung verarbeitet worden war.

Ebenso ist die Härtefallregelung eine empfohlene Übergangsregel. Sie zeigt, dass die politischen Entscheidungsträger die betrieblichen Kosten einer Umnummerierung erkannten. Sie identifiziert nicht, welcheT-markierten Änderungen freiwillig, erforderlich, ausgehandelt oder aus Gründen erfolgten, die nichts mit der neuen Kategoriezuteilung zu tun haben.

Der Anhang stützt dennoch einen bedeutenden institutionellen Befund. Seine Autoren konnten materielle Zuweisung von zentraler Nachverfolgung unterscheiden. Verschiedene Gremien konnten Zuweisungen in verschiedenen Kategorien vornehmen, während DDN/PMO oder ein Beauftragter die gemeinsame Aufzeichnung führte, um sicherzustellen, dass die Zuteilung innerhalb der Empfehlung blieb. Der gemeinsame Protokollführer musste nicht die alleinige Quelle jeder Entscheidung sein.

Diese Architektur brachte auch ungelöste Probleme mit sich. Wenn ein Netzwerk die Kategorie wechselte, musste jemand die Kategoriesalden aktualisieren. Wenn ein Zuweiser sein Kontingent überschritt, wäre ein Korrektur- oder Ausnahmeverfahren erforderlich. Wenn zwei Gremien denselben Antrag als in ihre Zuständigkeit fallend betrachteten, bräuchte das System eine Möglichkeit, die Überschneidung aufzulösen. RFC 820 empfiehlt die Nachverfolgung, veröffentlicht jedoch keinen vollständigen Zuständigkeitskodex.

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

Zählen des Inventars, ohne Zeilen in Antragsteller zu verwandeln

Die Netzwerktabellen können testen, wie die dokumentarische Veränderung in veröffentlichten Zuweisungen erschien, aber nur, wenn drei Beobachtungseinheiten getrennt bleiben.

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

Einerweiterter Netzwerkidentifikatorist eine klassenbasierte Netzwerknummer, die nach der Erweiterung eines gedruckten Bereichs dargestellt wird. Der RFC-820-Bereich192.001.xxxbis192.004.xxxrepräsentiert beispielsweise vier Werte des zweiten Oktetts multipliziert mit 256 Werten des dritten Oktetts, also 1.024 Klasse-C-Identifikatoren.

Eineeindeutige Literal-Identifikatorzeichenfolgeist ein erweiterter Identifikator, nachdem identische gedruckte Adresszeichenfolgen dedupliziert wurden, ohne zu erraten, was eine scheinbare Sequenz aussagen sollte. Diese Einheit bewahrt Transkriptionskonflikte, anstatt sie unsichtbar zu korrigieren.

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

RFC 790s Klasse-A-Tabelle druckt benannte Zuweisungszeilen für die Werte 001 bis 044, außer dass 013 explizit nicht zugewiesen ist. Das ergibt 43 benannte Zuweisungszeilen. Es ergibt nicht 43 unbestrittene zugewiesene Identifikatoren. Die Zeile für 044 nennt AMPRNET, aber der unmittelbar folgende nicht zugewiesene Bereich beginnt ebenfalls bei 044 und setzt sich bis 126 fort. Das Dokument liefert daher 42 eindeutig benannte Identifikatoren plus einen intern widersprüchlichen Identifikator, 044.

Klasse B enthält in RFC 790 keine benannte Zuweisung, und Klasse C ebenfalls nicht. Diese Aussage beschreibt die Tabelle, nicht das Fehlen jedes kleineren Netzwerks in der Welt. Die aufgeführten Klasse-A-Netzwerke umfassen mehrere Experimente, verwandte Einrichtungen und Testnetzwerke. Eine benannte Zeile ist kein Beweis für einen rechtlich unabhängigen Begünstigten.

RFC 820 liefert eine gedruckte „Network Totals“-Zusammenfassung auf Seite 6:

Bei Verwendung dieser gedruckten Zusammenfassung entfallen auf die Forschung (1.078 / 1.097) = 98,267 Prozent, gerundet auf 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 von einem einzigen Bereich, der mit BBN-Lokalnetzwerken 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) = 93,345 Prozent, gerundet auf 93,3 Prozent, der gedruckten zugewiesenen Gesamtzahl des RFC aus.

Dieser Nenner ist explizit: 1.097 erweiterte Zuweisungen, dargestellt durch die gedruckte Zusammenfassung. Das Verhältnis bedeutet nicht, dass BBN 1.024 separate Anträge gestellt, 1.024 unabhängige Entscheidungen erhalten oder jedes Netzwerk als extern geroutete Einheit genutzt hat. Das Dokument verbindet einen Bereich mit „BBN local networks“, erklärt aber nicht die Antragsgeschichte oder Betriebstopologie dahinter.

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

Die Deduplizierung der vier Vorkommen von192.005.022entfernt drei doppelte Vorkommen aus der gedruckten Klasse-C-Gesamtzahl:

Da die wiederholten BRL-Zeilen als Verteidigung codiert sind, werden die eindeutigen Literal-Kategorie-Gesamtzahlen 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 relativ zum BBN-Bereich gering, aber entscheidend für die Methode. Eine gedruckte Zusammenfassung kann als Anspruch der Quelle reproduziert werden. Eine eindeutige Zeichenfolgenzählung kann als separate wörtliche Lesart reproduziert 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 Netzwerk kann daher unter einem alten Klasse-A-Identifikator und einem neueren Klasse-B-Identifikator erscheinen, ohne zwei unabhängig situierte Empfänger zu repräsentieren. Das Zählen beider kann für die betriebliche Erkennung korrekt und für die Empfängeranalyse falsch sein.

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

Diese Änderung ist konsistent mit stärker differenzierten Zuweisungsgrößen. Sie ist kein Beweis dafür, dass Knappheit jede Änderung verursachte. Die Tabellen enthalten keine Host-Nutzungsreihen, Prognosen, Antragsformulare oder Entscheidungsgründe. Die Kapazität eines Klasse-A-Identifikators sagt, was das Adressformat erlaubte, nicht, wie viele Adressen das benannte Netzwerk nutzte oder warum Administratoren diese Klasse zum relevanten Zeitpunkt wählten.

Der BBN-Bereich ist ein wichtiger Gegenbeweis gegen eine einfache Geschichte einheitlicher Präferenz für die größte verfügbare Klasse. Ein großer Teilnehmer erscheint sowohl durch 1.024 kleine Klasse-C-Identifikatoren als auch durch andere Einträge. 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 Anzahl ist ebenfalls leicht falsch zu interpretieren. Nur drei Zuweisungen sind in der Zusammenfassung auf Seite 6 als kommerziell codiert, während Anhang A eine große zukünftige kommerzielle Zuteilung vorschlägt. Dieser Kontrast kann einen frühen politischen Übergang, den begrenzten Umfang des Arbeits-Internets, die Codierungspraxis, die Zusammensetzung der Nachfrage oder eine unvollständige Implementierung widerspiegeln. Ohne Anträge und Korrespondenz kann er keinen Ausschluss oder eine Vorzugsbehandlung belegen.

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

CAIDAsvisuelle Geschichte der IPv4-Zuteilungbietet eine nützliche Rekonstruktion der Adressraumbewegungen. Sie zeigt auch, warum spätere Visualisierungen den fehlenden Bewerbernenner 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 einer Granularität von/8und platziert kleinere Zuteilungen innerhalb der größeren Adressblöcke, die sie enthalten. Sie stellt fest, dass der zugewiesene Adressraum zwischen RFC 790 und RFC 820 teilweise zurückging, weil einige Organisationen große Blöcke gegen kleinere Zuweisungen eintauschten.

Diese Darstellung ist mit den Übergangsmarkierungen von RFC 820 und dem Rückgang der benannten Klasse-A-Einträge vereinbar. Sie ist keine unabhängige Bestätigung auf Empfängerebene, da ihre frühe Rekonstruktion auf den untersuchten RFC-Reihen basiert. Die öffentliche Datumssequenz bewegt sich 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, jede Zuweisungsentscheidung oder jeden Empfängerübergang zwischen RFC 790 und RFC 820 rekonstruieren.

Spätere Registry-Aufzeichnungen führen andere Probleme ein. CAIDAs separater Bericht über die IPv4-Verbrauchsmethodik stellt fest, dass ein Update von 1993 vielen Legacy-Zuteilungen ein Datum von August 1993 zuwies, wo genaue frühere Daten nicht verfügbar waren. Nachfolgende Aufzeichnungen können auch organisatorische Umbenennungen, Übertragungen administrativer Verantwortung, Korrekturen und Statusänderungen erben.

Ein aktueller Registry-Eintrag ist daher ein Beweis für einen überlebenden Verwaltungszustand, keine unberührte Aufzeichnung dessen, was ein Antragsteller 1981 beantragte. Er kann helfen, spätere Kontinuität zu verfolgen, aber er kann nicht allein den Grund, das Datum oder die Entscheidungseinheit wiederherstellen, die eine frühe Zeile hervorbrachte.

Die Tabellen können mehrere empirische Befunde ohne Übergriffigkeit stützen:

• RFC 790 druckt 43 benannte Klasse-A-Zuweisungszeilen, 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 wörtliche Deduplizierung ergibt 1.094 eindeutige Adresszeichenfolgen.
• Forschung macht 98,3 Prozent der gedruckten Gesamtzahl aus, hauptsächlich weil sich ein einzelner BBN-Bereich auf 1.024 forschungscodierte Klasse-C-Identifikatoren erstreckt.
• Der BBN-Bereich allein repräsentiert 93,3 Prozent der gedruckten Gesamtzahl von 1.097.
• Alte und neue Identifikatoren können koexistieren, weil Übergangszeilen die betriebliche Kontinuität bewahren.
• Die Arbeitstabelle stimmt noch nicht mit den empfohlenen Kategoriezuteilungen des Anhangs A überein.
• Die Dokumente enthalten keinen direkten Nenner für Anfragen, Ablehnungen, Rückzüge oder abgeratene Anträge.

Diese Befunde zeigen, dass das Inventar administrativ erstellt wurde. Kategorien, Änderungen, Reservierungen und Übergänge mussten aufgezeichnet werden. Sie zeigen nicht, ob gleichartige Antragsteller gleich behandelt wurden, da die relevante Population und Entscheidungsdateien fehlen.

Vier Erklärungen überleben das Textdelta

Die Bewegung von RFC 790 zu RFC 820 hat mindestens vier periodenplausible Erklärungen.

Die erste ist die politische Entwicklung. Das Treffen im September 1982 könnte eine explizitere Reaktion auf ein wachsendes und sich diversifizierendes Internet hervorgebracht haben. Die neuen Kategoriecodes, empfohlenen Poolgrößen, die Gateway-Bereitschaftsbedingung und die vorgeschlagene Aufteilung institutioneller Verantwortlichkeiten stützen diese Lesart. Anhang A präsentiert sie direkt als empfohlene Politik, die mit einer Agenturvereinbarung verbunden ist.

Die zweite ist das Implementierungsmanagement. Der Übergang von der ARPANET-Umgebung zum ARPA-Internet, die Entwicklung von MILNET und die Umnummerierung oder Reklassifizierung von Netzwerken könnten ein aufwändigeres Betriebsdokument erforderlich gemacht haben, selbst ohne eine völlig neue Verteilungsphilosophie. DieT-Markierungen, Zuweisungen kleinerer Klassen und die Härtefallregelung passen dazu.

Die dritte ist die Dokumentationsbereinigung. Praktiken, die zuvor durch Korrespondenz oder Arbeitsbeziehungen verstanden worden waren, wurden möglicherweise klarer aufgeschrieben. Summen, administrative Codes und Implementierungshinweise könnten eine bessere Veröffentlichung widerspiegeln, nicht den Beginn jeder von ihnen beschriebenen Praxis.

Die vierte ist die redaktionelle Präferenz. Der untersuchte RFC-820-Kopf zeigt einen zusätzlichen Namen, J. Vernon, obwohl der aktuelle Katalog nur Postel aufführt. Ein anderer Entwurfsprozess könnte explizitere institutionelle Prosa hervorgebracht haben, ohne eine proportionale Änderung der täglichen Entscheidungen. Die Katalog-/Kopf-Diskrepanz macht Autorschaft und redaktionelle Übermittlung zu einem Teil der Unsicherheit, nicht zu einer Grundlage für die Zuschreibung einer bestimmten politischen Rolle.

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

Zeitgenössische Korrespondenz könnte zwischen ihnen unterscheiden. Das Findmittel des Computer History Museum identifiziert Besprechungsnotizbücher, NIC-Fortschrittsberichte, Namens- und Adressdateien, chronologische E-Mails, Arbeitsgruppenaufzeichnungen und Internet-Monatsberichte, die von Auftragnehmern gesammelt wurden. Es zeigt, dass potenziell relevante Kommunikation zwischen NIC-Mitarbeitern, Netzwerknutzern, Arbeitsgruppen und Bundesbehörden in Archivsammlungen überlebt.

Das Findmittel offenbart nicht den Inhalt einer bestimmten RFC-790-Anfrage, des Treffensprotokolls vom September 1982 oder der Entwurfskorrespondenz für Anhang A. Es beweist die Existenz und den Umfang von Sammlungen, nicht, was ungeöffnete Aufzeichnungen ergeben würden.

Eine gezielte Archivprüfung würde fragen, wer den Anhang entworfen hat, ob die Kategoriecodes bereits intern verwendet wurden, wie Gateway-Nachweise bewertet wurden, warum einige ZuweisungsbehördenTBDblieben und ob bestimmte Umnummerierungen von Netzwerken oder von Administratoren vorgeschlagen wurden. Bis die zugrunde liegenden Aufzeichnungen diese Fragen beantworten, unterstützt das Textdelta mehrere Erklärungen.

Kontakte legten Verantwortung offen, ohne die Entscheidungskette zu definieren

Beide RFCs widmen den verantwortlichen Personen beträchtlichen 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 betrieblich nutzbar. Ein Entwickler konnte jemanden fragen, was ein undokumentiertes Protokoll bedeutete oder wen man zu einem benannten Netzwerk kontaktieren sollte.

Das Wort „responsible“ ist dennoch dehnbar. Die Person könnte ein Protokollautor, Implementierer, Standortkontakt, Ingenieur, Dokumentationsquelle oder Registry-Betreuer sein. Die Spalte sagt nicht, ob diese Person die Nummer beantragt, genehmigt, das Netzwerk kontrolliert hat oder ob sie genug wusste, um technische Fragen zu beantworten.

Die Mehrdeutigkeit ist in der Verwendung vonJBP, Postels Code, sichtbar. Er erscheint neben reservierten und nicht zugewiesenen Bereichen sowie zugewiesenen Protokollwerten. In diesen Positionen kann er keinen Begünstigten bezeichnen. Er markiert die Verantwortung für den Registry-Zustand oder die technische Definition. Andere Codes verweisen auf Personen, die mit benannten Netzwerken verbunden sind. Eine Notation repräsentiert daher mehrere Beziehungen.

Der Kontaktapparat unterstützt eine begrenzte institutionelle Behauptung: Die frühe Koordination hing von identifizierbaren Experten und erreichbaren Mailboxen ab. Er unterstützt nicht die Behauptung, dass persönliches Ansehen ein Zuweisungskriterium war. Er zeigt auch nicht, ob vorläufige Diskussionen per E-Mail, Telefon, Papierkorrespondenz oder Treffen stattfanden.

Die Veröffentlichung in der gemeinsamen Liste gab einer Zuweisung operative Sichtbarkeit. Implementierer, die sich auf die Referenz verließen, konnten Duplikate vermeiden und den relevanten Kontakt identifizieren. Diese praktische Bedeutung belegt nicht, dass die Liste die technische Existenz jedes Netzwerks schuf oder einen Eigentumsanspruch verlieh. Das vorgeschlagene Multi-Zuweiser-Modell in Anhang A deutet stattdessen darauf hin, dass Zuweisungsentscheidungen in mehreren Institutionen entstehen und zur Nachverfolgung konsolidiert werden konnten.

Ein umfassenderes Hauptbuch war machbar, aber nicht kostenlos

Stellen Sie sich vor, der Netzwerknummernteil von RFC 820 hätte fünf zusätzliche Informationsarten bewahrt: die geltenden Zulassungskriterien, einen kurzen Begründungscode, die Herkunft jeder Überarbeitung, aggregierte Antragsdispositionen und die zur Entscheidung von Ausnahmen befugte Stelle.

Dies hätte kein modernes öffentliches Antragssystem erfordert. Ein periodenplausibles Design hätte einen separaten Anhang mit fester Breite, Papierformulare, E-Mail-Vorlagen und aggregierte monatliche Summen verwenden können. Begründungscodes hätten Gateway-Bereitschaft, Experiment, Übergang, Kategoriewechsel und Korrektur unterscheiden können. Eine Revisionsspalte hätte den vorherigen Identifikator und das Wirksamkeitsdatum aufzeichnen können. Sensitive Details wären in eingeschränkten Dateien geblieben, während die öffentliche Liste einen minimalen Code trug.

Solche Aufzeichnungen würden mehrere historische Fragen testbar machen. Forscher könnten abgeschlossene Zuweisungen mit Rücknahmen oder Ablehnungen vergleichen, von Antragstellern gewünschte Umnummerierungen von administrativen Initiativen unterscheiden und feststellen, ob das Gateway-Kriterium konsistent angewendet wurde. Eine benannte Ausnahmebehörde würde zeigen, wo die vorgeschlagene Aufteilung der Verantwortlichkeiten endete.

Die zusätzliche Aufzeichnung würde auch Belastungen mit sich bringen. Die Mitarbeiter müssten Eingabedaten konsequent bewahren, Begründungsvokabulare pflegen und Überarbeitungen über aufeinanderfolgende Veröffentlichungen hinweg abgleichen. Experimentelle oder verteidigungsbezogene Anfragen könnten Details enthalten, die für die öffentliche Freigabe ungeeignet sind. Schwärzungsregeln würden weitere Entscheidungen schaffen. DieTBD-Einträge in RFC 820 zeigen, dass die Identifizierung einer Ausnahmebehörde selbst unvollendet war.

Das SRI NIC-Findmittel beschreibt Medieninkompatibilitäten, Druckerstellungsprobleme und schnell veraltende Referenzpublikationen im weiteren Zeitraum. Da die Assigned Numbers-Verwaltung bis 1987 bei USC-ISI blieb, kann dieser Nachweis nicht den genauen Produktionsprozess oder die Kosten von RFC 790 und RFC 820 belegen. Es ist Periodenkontext, der zeigt, dass eine reichhaltigere Dokumentation mit realen technischen und verlegerischen Zwängen interagiert hätte.

Das Kontrafaktische verändert daher die überlebenden Beweise, nicht unbedingt die Legitimität der Institution. Kriterien können schlecht gestaltet sein, Begründungen können formelhaft sein, und aggregierte Zahlen können Menschen weglassen, die nie gelernt haben, sich zu bewerben. Dennoch hätte der Unterschied zwischen einer Liste erfolgreicher Einträge und einem begründeten Entscheidungsprotokoll spätere Behauptungen über die Behandlung wesentlich einfacher testbar gemacht.

Kehren wir nun das Design um. Hätte die Einzigartigkeit ohne eine zentrale Stelle, die jede Zuweisung entscheidet, koordiniert werden können?

RFC 820s eigene Empfehlung antwortet im Prinzip mit Ja. Forschungs-, Verteidigungs- und kommerzielle Identifikatoren könnten von verschiedenen Stellen zugewiesen werden, während ein benannter Koordinator die gemeinsame Aufzeichnung führte. Der Zeitraum unterstützte bereits E-Mail, Telefonkoordination und regelmäßig aktualisierte Dokumente. Mehrere praktikable Arrangements waren denkbar.

Eine Option war die Meldung spezifischer Zuweisungen an einen gemeinsamen Tracker, was Anhang A bevorzugte, weil Identifikatoren die Kategorie wechseln konnten. Eine andere waren partitionierte Pools, in denen jeder Zuweiser einen definierten Bereich kontrollierte und regelmäßig Aktualisierungen veröffentlichte. Eine dritte war eine verteilte Menge abgestimmter Listen, die nach einem Zeitplan abgeglichen wurden, mit temporären Reservierungsnachrichten, um Kollisionen zwischen Ausgaben zu verhindern.

Jede Alternative hatte Kosten. Einfache Partitionen erschwerten Kategoriewechsel und konnten ungenutzte Identifikatoren in einem Pool stranden lassen. Periodischer Abgleich führte Verzögerung ein. Verteilte Listen riskierten widersprüchliche Zustände. Spezifische Zuweisung über einen gemeinsamen Tracker reduzierte einiges Kollisionsrisiko, machte den Tracker aber betrieblich wichtig.

Es geht nicht darum, dass Dezentralisierung notwendigerweise überlegen gewesen wäre. Es geht darum, dass Kollisionskontrolle, materielle Berechtigung und Veröffentlichung aufgeteilt werden konnten. Gemeinsame Nachverfolgung war betrieblich wertvoll und in der Architektur von RFC 820 ausdrücklich empfohlen, aber ein einziges universelles Inventar war nicht das einzig logisch mögliche Design.

Diese Unterscheidung ist wichtig bei der Interpretation der Rolle des Koordinators. Wenn die benannten Kategoriezuweiser ungeklärt oder nicht verfügbar waren, konnte die Person, die die gemeinsame Aufzeichnung führte, in der Praxis weiterhin Anfragen bearbeiten. Diese Ausdehnung konnte 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 noch alle Zuweisungen bearbeitet.

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

Das Regierungsumfeld kann erst hinzugefügt werden, nachdem die beiden Dokumente ihre eigenen Begriffe festgelegt haben.

EinRechtsgutachten des Government Accountability Office von 2016stellt fest, dass die später unter dem Namen IANA zusammengefassten Funktionen in Arbeiten begannen, die Postel an der UCLA leitete, und mit ihm 1977 zum USC-ISI wechselten. Das GAO beschreibt die Arbeit als unter vom US-Verteidigungsministerium finanzierten Forschungsprojekten durchgeführt und später durch DARPA-Verträge fortgesetzt.

Diese spätere Darstellung ist konsistent mit den direkten Verweisen von RFC 820 auf DARPA/IPTO, DDN/PMO und das Treffen im September 1982. Sie hilft zu erklären, warum ein globales technisches Inventar ein US-amerikanisches Verwaltungszentrum hatte und warum die vorgeschlagene Politik zwischen Forschungs-, Verteidigungs- und kommerziellen Nutzungen unterschied.

Das GAO sagt auch, dass es die relevanten DARPA-Verträge aus den 1970er bis 1990er Jahren nicht beschaffen konnte. Seine detaillierteren vertraglichen Nachweise betreffen spätere Perioden, und seine Rechtsfrage entstand Jahrzehnte nach RFC 790 und RFC 820.

Das Gutachten kann daher nicht die Klausel eines fehlenden Vertrags von 1981, die auf einen bestimmten Antrag angewandten Kriterien oder den Autoritätsumfang, den jeder Teilnehmer verstand, belegen. Bundesförderung erklärt institutionelle Kapazität und Kontext. Sie beweist nicht von selbst das Eigentum an Identifikatoren, universelle Zustimmung oder die Legitimität jeder administrativen Entscheidung.

Der Primärbeweis bleibt enger. RFC 790 nennt einen Koordinator für Zuweisungen. RFC 820 fügt eine Agenturvereinbarung, eine empfohlene Aufteilung des Nummernraums, voraussichtliche institutionelle Verantwortlichkeiten, eine vorgeschlagene Forschungsberechtigungsbedingung und einen Hinweis auf unvollständige Implementierung hinzu. Die spätere Regierungsgeschichte bestätigt das Umfeld, macht diese Aussagen jedoch nicht zu einer umfassenden Charta.

Was die Spalten letztlich stützen

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 der Abhängigkeit von einer gepflegten gemeinsamen Aufzeichnung zeigt.

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

RFC 820 fügt eine stärker artikulierte Verwaltungsschicht hinzu. Es klassifiziert Netzwerkidentifikatoren nach Nutzung, behält alte Nummern während Übergängen bei, druckt Zuweisungssummen und legt empfohlene Kategoriezuteilungen fest. Es schlägt Gateway-bezogene Nachweise für Forschungsbewerber vor, erlaubt einem Netzwerk, die Kategorie ohne Umnummerierung zu wechseln, wenn dies eine Härte verursachen würde, und stellt sich Zuweisungen durch mehrere Institutionen unter einer gemeinsamen Nachverfolgungsregelung vor.

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 letzte Implementierungshinweis sagt, dass Postel immer noch alle Zuweisungen koordiniert.

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

Die Dokumente stützen daher folgende Schlussfolgerung: Die Koordinierung von Netzwerknummern beinhaltete mehr als passive Transkription. Technische Einzigartigkeit musste geschützt werden, aber die Kategoriezuweisung, die Übergangsbehandlung und die vorgeschlagene Bereitschaftsbedingung erforderten administratives Urteilsvermögen. Dieses Urteilsvermögen operierte innerhalb eines bundesgeförderten institutionellen Rahmens und lief im untersuchten RFC-820-Text immer noch über einen arbeitenden Koordinator.

Sie stützen auch eine weniger zentralisierende Schlussfolgerung. RFC 820 setzte gemeinsame Nachverfolgung nicht mit ausschließlicher materieller Zuteilungsbefugnis gleich. Seine empfohlene Architektur erlaubte Entscheidungen, die in mehreren Institutionen entstanden, während eine Stelle die kombinierte Zuteilung überwachte. Das Design war unvollständig, aber die konzeptionelle Unterscheidung ist vorhanden.

Die verbleibende Unsicherheit ist keine geringfügige Einschränkung. Die öffentlichen Listen enthalten keine Antragspopulation, Ablehnungszahlen, Rückzugsgeschichte, Nutzungsreihen oder Gründe für jede Zuweisung. Das verfügbare Findmittel identifiziert potenziell relevante Korrespondenz, offenbart aber nicht deren Inhalt. Die Dokumente können nicht zeigen, ob das kompakte Format aus Bequemlichkeit, Veröffentlichungsgrenzen, vererbter Konvention, bewusstem Minimalismus oder einer anderen Ursache resultierte.

Die Tabellen belegen auch keine ausgereifte Knappheitsdoktrin. Sie zeigen endliche Klassenräume, 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 Adressverknappung erhöhte die Konsequenzen früherer Verteilungen, ohne deren ursprüngliche Motive zu rekonstruieren.

Was überlebt, ist eine dokumentierte administrative Kapazität mit realen betrieblichen Auswirkungen. Die Listen koordinierten Werte, machten bestimmte Zuweisungen sichtbar, klassifizierten Netzwerke und halfen, Kontinuität während des Wandels zu bewahren. Die Abhängigkeit von dieser Aufzeichnung konnte ihre Wartung folgenreich machen, selbst wenn der Protokollführer nicht beanspruchte, die Legitimität jedes Netzwerks zu begründen.

Unter der Leselampe ist der bedeutende Unterschied zwischen den beiden Dokumenten daher nicht, dass Politik 1983 plötzlich in die Tabelle eintrat. Es ist, dass RFC 820 mehr von der administrativen Maschinerie lesbar machte: eine Vereinbarung, Nutzungskategorien, voraussichtliche Zuweiser, eine Berechtigungsempfehlung, Übergangsregeln und ein Eingeständnis, dass die Implementierung hinter dem Design hinterherhinkte.

Diese Maschinerie kann beschrieben werden, ohne ihren Betreibern versteckte 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 ist. Die dauerhafteste Lehre der Zwei-Dokumente-Archäologie ist, dass ein technisches Inventar ein unverzichtbarer Beweis dafür sein kann, was ein koordinierendes System erkannte, während es unvollständiger Beweis dafür bleibt, wie, warum und von wem die Anerkennung entschieden wurde.