Frühe WHOIS-Kontaktdatensätze und die Verschiebung von Autorität

Zusammenfassung

RFC 812 definierte 1982 NICNAME/WHOIS als menschenlesbares Verzeichnis zum Auffinden von Netzwerkbenutzern. RFC 954 erweiterte 1985 die suchbare Population, doch keine der beiden Spezifikationen machte einen zurückgegebenen Namen, einen Handle, eine Organisation, einen Host oder ein Kontaktfeld zum Nachweis eines rechtlichen Anspruchs oder der aktuellen operativen Kontrolle.
Vier Datensatzfamilien entwickelten sich auf unterschiedlichen Pfaden: persönliche Verzeichniseinträge, DDN-Host- und Netzwerkkontakte, Domainregistrierungen mit ihren öffentlichen WHOIS-Anzeigen und Nummernressourcen-Registrierungsdatensätze. Ihre gemeinsame Abfrageschnittstelle machte sie nicht zu einem einzigen durchgehenden Titelsystem.
Ein Vorfall vom Dezember 1990 liefert einen direkten Nachweis operativer Abhängigkeit und eingeschränkter Verantwortungszuweisung: Ein DDN-NIC-Netzwerkdatensatz leitete betroffene Standorte und CERT/CC zu einer Institution, während Protokolle, lokale Administration und direkte Untersuchungen weiterhin erforderlich waren, um die Maschine und den Betreiber zu identifizieren.
Ein Streit vom Februar 1996 um die CLUE.COM-Registrierung bietet einen vollständigen Fall administrativer Handlungsfähigkeit im zugrunde liegenden Registrierungsverfahren von Network Solutions. Der eingetragene Inhaber erhielt eine Benachrichtigung, widersprach der angedrohten Änderung und erwirkte eine einstweilige Verfügung, die die Registrierung bewahrte. Aus dem Gerichtsprotokoll geht nicht hervor, dass eine öffentliche WHOIS-Abfrage diese Handlungsfähigkeit unabhängig begründete.
Die Kremen-Rechtsstreitigkeiten dokumentieren eine andere Kollision im Oktober 1995: Network Solutions änderte seine maßgebliche Registrierungsdatenbank nach Erhalt einer gefälschten Anweisung, was praktische Nutzungskonsequenzen nach sich zog. Die öffentliche WHOIS-Abfrage konnte den geänderten Zustand widerspiegeln, doch die Beweise zeigen nicht, dass eine öffentliche Abfrage die Änderung verursachte oder Eigentum verlieh.
Bis 1996 waren die Registrierung von Nummernressourcen und die Datenübermittlung bei Neuzuweisungen vorgeschriebene Eingaben für operative Kontakte und Entscheidungen über zusätzliche Zuteilungen. RFC 2050 verlangte dennoch unterstützende Unterlagen, schützte vom Antragsteller als sensibel gekennzeichnetes Material und sah eine Prüfung durch die Registrierungshierarchie vor. Keiner der hier untersuchten Fälle zeigt, dass eine öffentliche Nummernressourcen-Zeile allein über einen Anspruch entschied.

Das lesen, bevor man Autorität hineinliest

Die frühen Spezifikationen sind am besten als Schemaarchäologie zu begreifen. Bevor man fragt, wann WHOIS zum Beweismittel wurde, muss man fragen, was ihre Datensätze enthalten sollten, wer dort erscheinen sollte und was eine Antwort bewirken sollte.

RFC 812, verfasst von Ken Harrenstien und Vic White und datiert auf den 1. März 1982, beschrieb NICNAME/WHOIS als einen transaktionsbasierten Abfrage-und-Antwort-Server auf der SRI-NIC-Maschine. Er stellte ARPANET-Nutzern im Auftrag der Defense Communications Agency ein netzwerkweites Verzeichnis zur Verfügung. Ein Nutzer sendete eine Kommandozeile, empfing eine Antwort und trennte die Verbindung. Die Antwort war für menschliche Leser gedacht, nicht für automatisierte Interpretation.

Die erwartete Population war persönlich. Die Defense Communications Agency verlangte die Registrierung jeder Person, die ein Verzeichnis auf einem ARPANET-Host hatte und Verkehr über das Netzwerk leiten konnte. Die Registrierungsinformationen umfassten einen Namen, institutionelle oder postalische Kontaktdaten, eine Telefonnummer und eine Netzwerk-Mailbox. Diese Felder zeigen, wie viele persönliche Erreichbarkeitsinformationen der Dienst offenlegte; die Wiedergabe echter Einträge ist nicht erforderlich. Ihre ursprüngliche Funktion war die Auffindbarkeit.

RFC 954, verfasst von K. Harrenstien, M. K. Stahl und E. J. Feinler und datiert auf Oktober 1985, behielt Port 43 und die Einmal-Abfrage/Antwort-Architektur bei. Er beschrieb den Dienst als ein Verzeichnis für Internetnutzer und erklärte erneut, dass seine Ausgabe menschenlesbar sei. Die suchbare Population war breiter: registrierte Personen und Mailboxen, Netzwerkorganisationen, DDN-Knoten und zugehörige Hosts sowie registrierte MILNET-Terminalzugriffsbenutzer.

Die Felder erfüllten bereits unterschiedliche Aufgaben. Ein Name half einem Benutzer, eine Person zu finden. Ein Handle unterschied diese Person von anderen mit ähnlichen Namen und diente als wiederverwendbare Datenbankreferenz. Eine Organisation lieferte eine Zugehörigkeit. Mailbox- und Telefonfelder boten Kommunikationskanäle. Host- und Knotenzuordnungen verorteten eine Person innerhalb des Netzwerkbetriebs.

Keine dieser Aussagen besagte für sich genommen, dass die Person weiterhin bei der Organisation angestellt war, diese binden konnte, jedes zugeordnete System kontrollierte oder einen rechtlichen oder vertraglichen Anspruch auf eine Internetkennung besaß.

Der Unterschied zwischen einem Verzeichnis und einem Beweissystem liegt teilweise darin, was die angezeigten Felder umgibt. Ein Beweissystem wirft Fragen nach Herkunft, Berechtigung zur Einreichung, Authentifizierung, Gültigkeitsdaten, ersetzten Versionen, bestrittenen Korrekturen, Änderungsgründen und Prüfung auf. RFC 812 und RFC 954 spezifizierten den öffentlichen Abfragedienst. Sie spezifizierten keinen öffentlichen Prüfpfad, der diese Fragen beantwortet.

Dieses Fehlen darf nicht überbewertet werden. Ein Protokolldokument ist kein vollständiges Betriebshandbuch. Das Fehlen einer Authentifizierungsregel in der Abfragespezifikation beweist nicht, dass NIC-Mitarbeiter jede Aktualisierung ohne Korrespondenz, telefonische Überprüfungen, etablierte Standortbeziehungen oder menschliches Urteilsvermögen akzeptierten.

Es stellt etwas Engeres fest: Ein Empfänger der öffentlichen Antwort erhielt keine standardisierte Darstellung, wer jedes Feld bereitgestellt hatte, wie die Autorität dieser Person geprüft worden war, welche früheren Werte verdrängt worden waren oder ob eine andere Partei den aktuellen Datensatz bestritt.

Fünf Komponenten müssen daher getrennt bleiben:

die zugrunde liegende Registrierungs- oder Identifikationsdatenbank der Institution;
die aus dieser Datenbank generierte öffentliche WHOIS-Antwort;
das Verfahren, mit dem eine Registrierung oder ein Kontakt hinzugefügt, geändert oder gelöscht wurde;
mit der Kennung verbundene Betriebssysteme, einschließlich Host-Administration, Routing und DNS-Delegierung;
Verträge, Zuteilungskorrespondenz, organisatorische Ernennungen, Einwilligungen und rechtliche Aufzeichnungen außerhalb der Datenbank.

Diese Schichten zu vermengen, lässt die öffentliche Abfrage mächtiger erscheinen, als es die historischen Belege erlauben. Eine WHOIS-Antwort konnte eine Registrierung beschreiben. Eine Registrierungstransaktion konnte die maßgebliche Datenbank einer Registrierungsstelle ändern. Eine separate betriebliche Änderung konnte den DNS-Dienst oder die Netzwerknutzung verändern. Ein Gericht oder eine Registrierungsstelle konnte später entscheiden, ob die Transaktion gültig war. Das waren verwandte, aber nicht ein einziges Ereignis.

Die hier untersuchte Beweisleiter ist:

Verzeichnisbequemlichkeit -> operative Abhängigkeit -> Verantwortungszuweisung -> administrative Handlungsfähigkeit -> anspruchsähnliche Folgerung

Jeder Schritt nach oben erfordert mehr als eine Spezifikation, die zeigt, dass ein Feld existierte. Er erfordert einen datierten Akteur, einen bestimmten Datensatz, eine Entscheidung, eine konkurrierende Wahrheitsquelle und ein beobachtbares Ergebnis. Wenn das Archiv nur ein vorgeschriebenes Verfahren liefert, muss die Schlussfolgerung eine dokumentierte Erwartung bleiben und kein vollendeter Akt der Abhängigkeit.

Name und Handle: der persönliche Verzeichniseintrag

Die erste Datensatzfamilie war ein Verzeichnis von Personen.

Wozu die Felder dienten

Das Namensfeld beantwortete die einfachste Frage: welche Person gesucht wird? Der Handle machte diese Antwort innerhalb der Datenbank stabiler. Ein Benutzer konnte breit suchen und dann einen bestimmten Eintrag anhand seines Handles auswählen. Andere Datensätze konnten auf den Handle verweisen, ohne jedes Kontaktfeld zu reproduzieren.

Das war eine wichtige technische Errungenschaft. Namen sind nicht eindeutig, Initialen variieren und organisatorische Zugehörigkeiten ändern sich. Eine dauerhafte Kennung reduzierte die Mehrdeutigkeit innerhalb der NIC-Datensätze. Sie war ein starker Hinweis darauf, welche Datenbankzeile ein Nutzer ausgewählt hatte.

Sie war jedoch kein Identitätsnachweis. RFC 812 und RFC 954 beschrieben keinen dokumentarischen Identitätsnachweis, keine mit dem Handle verknüpfte Unterschrift und keine externe Autorität, die jede Zugehörigkeit bestätigte. Ein Handle stellte die Kontinuität in der Datenbank klarer her als die Kontinuität der Anstellung, der Zuständigkeiten oder der rechtlichen Handlungsfähigkeit der Person.

Das Organisationsfeld war ähnlich deskriptiv. Es half, Personen zu unterscheiden, und zeigte an, wo sie zu finden waren. Ein Datensatz konnte zum Zeitpunkt der Eingabe eine zutreffende institutionelle Zuordnung ausweisen und nach einem Wechsel, einer Umstrukturierung oder einem Ausscheiden veralten. Das Feld enthielt keinen Arbeitsvertrag und keine Vollmachtserteilung.

Einreichung, Aktualisierung und Authentifizierung

RFC 812 wies Personen an, Registrierungsinformationen an das NIC zu senden. RFC 954 verwendete einen Registrar-Kanal für vergleichbare Einreichungen. Die Spezifikationen identifizieren das erwartete Subjekt und das Ziel der Information, beschreiben aber kein separates authentifiziertes Aktualisierungsprotokoll.

Die erhaltenen Spezifikationen erlauben folgende begrenzte Prüfung:

Einreicher und Herkunft:Die Information stammte von einer Person, die registriert werden wollte oder musste.
Aktualisierungsberechtigung:Die RFCs nennen keine umfassende Regel, wer einen bestehenden Personeneintrag ersetzen durfte.
Authentifizierung:In den öffentlichen Protokolldokumenten ist keine einheitliche Methode zur Identitätsüberprüfung festgelegt.
Korrektur:Es gab Unterstützungs- und Registrierungskanäle, doch die RFCs beschreiben kein Verfahren zur Behandlung bestrittener Korrekturen.
Ersetzung und aktueller Zeitpunkt:Die öffentliche Antwort gab die aktuelle Antwort der Datenbank wieder; die Spezifikationen definieren keinen datensatzbezogenen Gültigkeitsverlauf.
Historische Aufbewahrung:Es wird keine öffentliche Abfolge früherer Werte festgelegt.
Konfliktprüfung:Die RFCs erläutern nicht, wie das Personal zwischen unvereinbaren Ansprüchen in Bezug auf denselben persönlichen Eintrag entscheiden würde.
Datenschutzgrenze:Persönliche Erreichbarkeitsinformationen wurden bewusst offengelegt, weil die persönliche Auffindbarkeit der ursprüngliche Zweck des Dienstes war.

Unbekannt bedeutet nicht nicht existent. Interne Korrespondenz oder Personalpraxis mögen Kontrollen bereitgestellt haben, die die RFCs nicht dokumentierten. Die vertretbare Feststellung lautet, dass diese Kontrollen nicht Teil des Nachweises waren, der einem Nutzer der öffentlichen Antwort vorgelegt wurde.

Die Stufe, die diese Familie stützt

Der persönliche Verzeichniseintrag begründet unmittelbar die Verzeichnisbequemlichkeit. In den Jahren 1982 und 1985 war der identifizierte Benutzer ein ARPANET- oder DDN-Teilnehmer, der eine Person, Mailbox, Organisation oder Host-Zuordnung suchte. Die Entscheidung bestand darin, wohin eine Nachricht oder Anfrage zu richten war. Konkurrierende Quellen waren ein Arbeitgeberverzeichnis, ein Host-Account, eine Standortliste, ein Telefonkontakt oder eine Bestätigung der Person oder Institution.

Die hier untersuchten Quellen dokumentieren keinen Fall vor 1997, in dem das Vorhandensein eines persönlichen NIC-Handles allein über rechtliche Ansprüche, organisatorische Autorität oder technische Kontrolle entschied. Die Dauerhaftigkeit des Feldes konnte solche Folgerungen nahelegen, doch seine dokumentierte Funktion blieb die Auffindbarkeit.

Host und Netzwerk: der DDN-Betriebskontaktdatensatz

Die zweite Familie verband Personen mit Maschinen, Netzwerken und definierten operativen Rollen. Hier begann der Datensatz mehr als bloße Erreichbarkeit zu transportieren.

Von der Zugehörigkeit zu einer Handlungspflicht

Ein entfernter Betreiber, der mit einer Fehlfunktion oder einem Sicherheitsvorfall konfrontiert war, benötigte nicht nur den Namen einer Person in einer Institution. Er benötigte jemanden, der einen Host untersuchen, eine Konfiguration ändern, ein System trennen oder lokales Personal dazu anweisen konnte.

Zeitgenössische Quellen definieren diese Verantwortung. DerDomain Administrators Guide, RFC 1032, vom November 1987 unterschied den Domain-Administrator von technischen und Zonenkontakten. Der Administrator sollte die Domain koordinieren, verwalten und die Befugnis besitzen, zu handeln oder zu delegieren. Technische Kontakte und Zonenkontakte warteten Nameserver-Software und -Daten und arbeiteten mit technischem Personal an anderen Standorten zusammen.

RFC 1173vom August 1990 beschrieb die Verantwortlichkeiten von Host- und Netzwerkmanagern. Es handelte sich ausdrücklich um eine informelle Zusammenfassung der „mündlichen Überlieferung“ des Internets, nicht um einen IAB-Standard. Selbst mit dieser Einschränkung ist seine inhaltliche Prüfung aufschlussreich. Er verlangte, dass verantwortliche Personen für angeschlossene Netzwerke beim zuständigen NIC registriert und aktuell gehalten werden. Von einem Netzwerkmanager wurde erwartet, dass er über Systemmanagement-Zugriff oder die Befugnis verfügte, ein fehlerhaftes System zu deaktivieren, zu trennen oder die Weiterleitung von Datenverkehr zu unterbinden. Ein Hostmanager benötigte gleichermaßen die Befugnis, den Zugriff und die Werkzeuge, die zur Kontrolle des Hosts erforderlich waren.

Der Datensatz und die äußere Realität waren daher verknüpft, aber nicht identisch. Der Datensatz benannte die Person. Tatsächliche Berechtigungen, physischer Zugang, Arbeitgeberbefugnis und lokale Zusammenarbeit bestimmten, ob diese Person die Rolle ausfüllen konnte.

DerLeitfaden zu den SRI ARC/NIC Records von 2011bietet eine retrospektive Kartierung der Sammlung und identifiziert Materialien zu Technical Liaisons, Host Administrators, Node Site Coordinators und anderen Kontaktgruppen. Er hilft, relevante Aufzeichnungen zu lokalisieren; er wird nicht als zeitgenössischer Beweis dafür behandelt, warum jede Rolle geschaffen wurde oder welche Autorität jeder Inhaber genau besaß. Diese Aussagen erfordern zeitgenössische Dokumente wie RFC 1032, RFC 1173, Dienstanweisungen, Registrierungsmaterialien und Betriebsberichte.

Ein datierter Bericht zur Pflege von Kontaktdaten

Ein genauerer Betriebsbericht ist in Mary K. StahlsDescriptions of NIC Tables and Listserhalten, einem Abschlussbericht vom 5. April 1991. Das Network Information Systems Center von SRI International erstellte den Bericht für die Defense Communications Agency unter dem Vertrag DCA200-90-C-0027, SRI Project ECU 1050, CDRL No. 027. Er befindet sich in der Sammlung des Computer History Museum mit dem TitelDefense Communication Agency materials, 9 of 13.

Der Bericht identifiziert mehrere unterschiedliche Derivate, nicht eine einzige undifferenzierte WHOIS-Datei.

Abschnitt 3.1 auf Berichtsseite 7 beschreibt MILNET-Host-Administrator-Dateien. Ihre Daten wurden aus der NIC-WHOIS-Datenbank extrahiert. Die Erstinformation stammte aus Network Change Directives, danach forderte der NIC-Hostmaster monatlich Korrekturen von den Host-Administratoren an. Die abgeleitete Datei wurde wöchentlich generiert.

Abschnitt 3.7 auf Berichtsseite 10 beschreibt eine Datei, die Host-Administratoren nach Netzwerkadresse ordnet. Auch hier heißt es, dass die Erstinformation aus Network Change Directives stammte und durch monatliche Online-Aufforderungen zur Korrektur aktuell gehalten wurde. Die Datei wurde wöchentlich erzeugt.

Der Bericht führt weiter aus, dass Dateien und Tabellen auf Dateiebene eine Versionsnummer oder ein Datum der letzten Aktualisierung trugen. Das bot nützliche zeitliche Informationen: Ein Benutzer konnte eine bestimmte veröffentlichte Generation identifizieren. Es lieferte jedoch nicht unbedingt einen öffentlichen Verlauf aller vorherigen Werte für jeden Kontakt.

Für DDN-Host- und Netzwerkdatensätze wird die Prüfung konkreter:

Einreicher und Herkunft:Erste Hostinformationen konnten aus Network Change Directives stammen; spätere Änderungen kamen von anerkannten Host-Administratoren, Node Site Coordinators oder Netzwerkpersonal.
Aktualisierungsberechtigung:Von Rolleninhabern wurde erwartet, Korrekturen einzureichen, und der Hostmaster forderte sie an. Der Bericht definiert nicht jeden Test, der angewendet wurde, wenn ein neuer Korrespondent beanspruchte, einen bestehenden Rolleninhaber zu ersetzen.
Authentifizierung:Eine etablierte Rolle und ein Korrespondenzkanal schufen prozedurales Vertrauen, doch der Bericht beschreibt kein einheitliches System zur Identitätsprüfung oder Nachrichtenauthentifizierung für alle Aktualisierungen.
Korrektur:Monatliche Aufforderungen und freiwillige Einreichungen boten wiederkehrende Korrekturwege.
Ersetzung und aktueller Zeitpunkt:Wöchentlich neu generierte Dateien und dateibezogene Versionen zeigten Veröffentlichungszyklen, nicht notwendigerweise das Wirksamkeitsdatum jeder externen organisatorischen Änderung.
Historische Aufbewahrung:Der Bericht beschreibt aktuelle Derivate und deren Generierung. Er begründet keine öffentliche, vollständige, datensatzbezogene Abfolge ersetzter Kontakte und Gründe.
Konfliktprüfung:Der Hostmaster nahm eine interpretierende Position ein, aber der Bericht beschreibt kein allgemeines Schlichtungsverfahren für konkurrierende Anspruchsteller auf dieselbe Rolle.
Datenschutzgrenze:Einige Betriebsderivate enthielten umfangreiche persönliche und rollenbezogene Kontaktdaten. Diese Details werden hier nicht wiedergegeben.

Das Pflegesystem war strukturiert. Es entsprach keiner öffentlich einsehbaren Kette authentifizierter Nachweise. Ein aktueller Datensatz konnte weiterhin einem Personalwechsel hinterherhinken, ohne dass jemand unehrlich handelte.

Operative Abhängigkeit und Verantwortungszuweisung im Dezember 1990

Ein tatsächlicher Vorfall liefert das klarste Beispiel vor 1997, das über die vorgeschriebene Nutzung hinausgeht.

In einem Beitrag, der auf dem USENIX Security Symposium 1992 vorgestellt wurde,beschrieben Alessandro Berni, Paolo Franchi und Joy Marino Internetsicherheitsvorfälle in Italien. Ihr Bericht besagt, dass zwei Standorte Eindringversuche beobachteten, die mit einem Netzwerk in Italien verbunden waren, und sich an das CERT Coordination Center wandten. Während der Reaktion verband die DDN NIC WHOIS-Datenbank das Netzwerk mit der Universität Mailand.

Die Beweiselemente können ohne Wiedergabe historischer Kontaktdetails dargestellt werden:

Datum:Dezember 1990, dokumentiert im Beitrag von 1992.
Akteure:die betroffenen Standorte und CERT/CC.
Verwendeter Datensatz:die DDN-NIC-Netzwerkzuordnung und Kontaktinformation.
Entscheidung:welche Institution die erste Vorfallmeldung erhalten und zur Untersuchung aufgefordert werden sollte, bevor die Betreiber erwogen, das Netzwerk zu isolieren.
Konkurrierende Wahrheitsquellen:System- und Paketprotokolle, Routing-Informationen, tatsächliche Administration der beteiligten Maschine, lokale institutionelle Aufzeichnungen und direkte Bestätigung.
Ergebnis:die Abfrage identifizierte eine relevante Institution und leitete den Kontakt ein, aber der verantwortliche Maschinenadministrator wurde nicht sofort festgestellt und die Kommunikation blieb schwierig.

Dieser Fall beweist operative Abhängigkeit. Der Datensatz veränderte, was die Reagierenden als Nächstes taten: Er wählte eine Institution für die Kontaktaufnahme aus.

Er stützt auch eine eingeschränkte Form der Verantwortungszuweisung. Der Netzwerkeintrag verband den beobachteten Verkehr mit einem Organisationsnetzwerk und platzierte diese Organisation im Reaktionspfad. Er identifizierte weder die Person, die die Aktivität ausführte, noch lokalisierte er abschließend die spezifische Maschine, noch bewies er, wer die Fähigkeit besaß, sie zu stoppen.

Protokolle stellten die beobachteten Ereignisse fest. WHOIS lieferte eine institutionelle Zuordnung. Die lokale Untersuchung musste den Verkehr einer Maschine zuordnen. Organisatorische Autorität und technischer Zugang bestimmten, wer handeln konnte. Der Datensatz war eine Brücke zwischen einer Kennung und einer Institution, kein vollständiges Zuschreibungssystem.

Die Belege erreichen sicher die operative Abhängigkeit und die Verantwortungszuweisung. Sie zeigen nicht, dass ein öffentlicher Netzwerkkontakteintrag in einer bestrittenen administrativen Änderung Handlungsfähigkeit verlieh oder einen Anspruch auf die Netzwerknummer begründete.

Organisation, Domain, Kontakte und Server: der Domain-Datensatz

Die dritte Familie platzierte mehrere Aussagen in einem sichtbaren Datensatz: eine Organisation, einen Domainnamen, differenzierte Kontakte und Nameserver. Ihre Nähe ermutigte spätere Nutzer, sie als eine einzige Kontrollaussage zu lesen. Historisch hatte jede eine andere beweisrechtliche Grundlage.

Organisation und Domain

RFC 1032 wies einen Domain-Administrator an, einen Registrierungsfragebogen einzureichen, und beschrieb den Administrator als verantwortlich dafür, die Daten der Domain aktuell zu halten. Sein Abschnitt zur Überprüfung besagte, dass WHOIS verwendet werden könne, um die mit einer Domain verbundene Organisation, den Domainnamen, administrative, technische und Zonenkontakte sowie die aufgeführten Nameserver zu überprüfen.

Dies war mehr als persönliche Auffindung. Es war eine vorgeschriebene Nutzung von WHOIS, um eine Registrierung mit der beabsichtigten Domainkonfiguration zu vergleichen.

Doch RFC 1032 lieferte auch zeitgenössische Gegenbeweise zu jeder Rechtstiteltheorie. Er besagte, dass das NIC bei lokalen Streitigkeiten darüber, wer das „Recht“ auf die Registrierung einer Domain habe, nicht als Schlichter auftreten werde. Solche Streitigkeiten sollten vor der Registrierung unter den Parteien geklärt werden. Das NIC könne technische Fragen beantworten, beanspruche aber nicht, das zugrunde liegende Recht zu entscheiden.

Die Felder sollten daher getrennt gelesen werden:

Organisation:die im Registrierungsantrag vertretene Entität.
Administrativer Kontakt:die Person, die für Richtlinien oder organisatorische Koordination verantwortlich ist.
Technische und Zonenkontakte:die Personen, die für den Nameserver-Betrieb und zugehörige Daten verantwortlich sind.
Nameserver:die Systeme, die autoritativ für die Domain antworten sollen.
WHOIS-Anzeige:die menschenlesbare Darstellung der erfassten Fakten durch die Registrierungsstelle.
DNS-Delegierung:die betriebliche Platzierung der Domain im hierarchischen Namenssystem.

Eine öffentliche WHOIS-Antwort konnte mit einem Antrag und dem aktiven DNS verglichen werden. Sie konnte ohne weitere Beweise nicht beweisen, dass der administrative Kontakt noch über die Unternehmensautorität verfügte oder dass die Organisation jedes mit dem Namen verbundene Recht innehatte.

RFC 1032 etabliert einen normativen Nutzer und eine Entscheidung: Im November 1987 wurde einem Domain-Administrator gesagt, er solle WHOIS einsehen, um zu prüfen, ob die Domaindaten korrekt repräsentiert seien. Die konkurrierenden Quellen waren der eingereichte Antrag, die Datensätze übergeordneter Domains, das aktive DNS und organisatorische Ernennungen. Der RFC dokumentiert keinen bestimmten Administrator, der diesen Vergleich vornahm und ein dokumentiertes Ergebnis erhielt. Er beweist die erwartete betriebliche Überprüfung, nicht ein vollendetes Abhängigkeitsereignis.

Domainkorrektur im DDN-Datensatz von 1991

Stahls April-1991-Bericht gibt der Domain-Kontaktdatei eine spezifische Herkunft. Abschnitt 3.8 auf Berichtsseite 10 besagt, dass dieDOMAIN-CONTACTS-Ableitung Informationen aus Domainregistrierungsanträgen bezog, die vom NIC-Hostmaster bearbeitet wurden, sowie aus Korrekturen, die von Domain-Administratoren eingereicht wurden. Die Rohdaten wurden in der NIC-WHOIS-Datenbank gespeichert, und die Kontaktdatei wurde wöchentlich generiert.

Der Bericht unterscheidet ferner zwischen administrativen, technischen und Zonenkontakten. Diese Rollen waren nicht allein deshalb austauschbar, weil sie zusammen erschienen.

Der Bericht stützt einen definierten Korrekturweg, lässt aber andere Fragen offen:

ein anerkannter Domain-Administrator konnte eine Korrektur einreichen;
der Hostmaster bearbeitete den ursprünglichen Antrag oder die Korrektur;
eine neue wöchentliche Ableitung konnte den geänderten aktuellen Zustand offenlegen;
der Bericht nennt keine universelle Authentifizierungsmethode für jede Korrektur;
er begründet nicht, dass jeder öffentliche Nutzer alle ersetzten Kontakte abrufen konnte;
er beschreibt kein einheitliches Verfahren zur Entscheidung über unvereinbare Korrekturanforderungen.

Das ist ein Beleg für gesteuerte Mutation. Es ist kein Beleg dafür, dass ein angezeigter administrativer Kontakt allein durch die Anzeige rechtliche Autorität erlangte.

Der InterNIC-Anfrageworkflow von 1993

RFC 1400vom März 1993 dokumentierte den Übergang der nicht-DDN Registrierungsdienste zu InterNIC. Ab dem 1. April 1993 sollte InterNIC WHOIS Informationen zu IP-Adressen, Domains, autonomen Systemnummern und individuellen Kontaktstellen enthalten, die mit aktiven Knoten verbunden sind. Die allgemeine persönliche Verzeichnisabdeckung war nicht mehr die Hauptpopulation des zentralen Registrierungsdienstes.

Das Dokument beschrieb auch einen strukturierten Anfrageprozess. Ein Antragsteller reichte eine Vorlage bei einer automatisierten Registrierungsmailbox ein. Ein Parser prüfte maschinell prüfbare Informationen, einschließlich Domainnamenskonflikten, und gab eine Verifikations- oder Ablehnungsnachricht zurück. Der Antragsteller überprüfte, wie der Parser die Einreichung interpretiert hatte. Korrekturen konnten zurückgesendet und erneut geprüft werden. Eine zufriedenstellende Verifikation gab die Anfrage zur endgültigen Bearbeitung durch das Registrierungspersonal frei. Eine unbeantwortete Verifikation verfiel nach sieben Tagen.

Eine Ticketnummer zeigte den Status der Anfrage an, und eine WHOIS-Anzeige konnte ein Datum der letzten Aktualisierung enthalten.

Diese Kontrollen verbesserten Form, zeitliche Einordnung und Nachverfolgbarkeit, doch ihre Modalität ist entscheidend.

Das Verifikationsformular ging an denursprünglichen Antragsteller. RFC 1400 besagt nicht, dass ein bestehender administrativer Kontakt es erhielt, weil ein früherer WHOIS-Eintrag Autorität verlieh. Die verfahrensrechtliche Stellung des Antragstellers ergab sich daraus, dass er die Anfrage gestellt hatte. Das zurückgesendete Formular verifizierte die Interpretation der eingereichten Daten durch den Parser; es war für sich genommen kein Beweis dafür, dass der Antragsteller die rechtliche Befugnis besaß, die Organisation zu vertreten.

RFC 1400 sagt ferner, dass Sicherheitsfragen in dem Memo nicht behandelt wurden. Dieses Fehlen beweist nicht, dass das Personal keine telefonischen Überprüfungen, Papieraufzeichnungen, frühere Korrespondenz oder institutionelles Urteilsvermögen einsetzte. Es verhindert, dass der automatisierte Workflow als Beweis für einen universellen Identitätsprüfungsstandard angeführt wird.

Für den Domainworkflow von 1993:

Herkunft:Das System verknüpfte eine Anfrage, einen Antragsteller, ein geparstes Formular und ein Ticket.
Authentifizierung:Der RFC spezifiziert keinen universellen unabhängigen Test der organisatorischen Befugnis.
Korrektur:Parserfehler und abgelehnte Einreichungen hatten einen expliziten Korrekturpfad.
Zeit:Ticket-Eröffnungsinformationen und ein Feld für die letzte Aktualisierung lieferten aktuelle zeitliche Markierungen.
Verlauf:Die öffentlichen Beispiele begründen keine vollständige Abfolge eingereichter Versionen und Personalentscheidungen.
Überprüfung:Das Registrierungspersonal führte die Endbearbeitung durch, aber der RFC definiert keine Entscheidungsfindung bei zwei konkurrierenden Ansprüchen.
Administrative Handlungsfähigkeit:Das Dokument belegt die Stellung des ursprünglichen Antragstellers in dieser Anfrage, nicht die aus einem bestehenden öffentlichen Kontaktfeld erworbene Handlungsfähigkeit.

Ein begrenzter Vergleich aus RFC 1591

RFC 1591vom März 1994 betraf DNS-Struktur und Delegierung. Er ist nur als domainspezifischer Vergleich nützlich.

Das Dokument verlangte administrative und technische Kontakte für eine delegierte Domain, doch die Verantwortung beruhte auf mehr als einem Feld. Von einem designierten Manager wurde erwartet, der relevanten Gemeinschaft zu dienen, die Domain kompetent zu betreiben, auf Anfragen zu antworten, einen genauen und ausfallsicheren Dienst aufrechtzuerhalten und die Unterstützung maßgeblich interessierter Parteien zu behalten. Ein Wechsel der Verantwortung des designierten Managers erforderte Mitteilungen sowohl der alten als auch der neuen Organisation, wobei betroffene Parteien ebenfalls relevant waren.

Bei Streitigkeiten über Rechte an einem Namen beschränkte RFC 1591 die Rolle der Registrierungsstelle auf die Bereitstellung von Kontaktinformationen und stellte fest, dass die Registrierung keinen Markenstatus begründe. Er sah ferner eine Prüfung vor, wenn die Parteien keine Einigung erzielen konnten.

Die datierten Akteure waren IANA, der übergeordnete Manager, die alte und die neue Organisation sowie betroffene Parteien. Ein Kontaktdatensatz konnte identifizieren, an wen man sich wenden sollte. Eine Delegierungsentscheidung hing von der operativen Leistung, der Einigung, den Mitteilungen und der Prüfung ab.

Dies ist ein Vergleich innerhalb des DNS. Er kann kein Eigentum an einem IP-Adressblock begründen und beweist nicht, dass jede Second-Level-Domain-Änderung demselben Prozess folgte.

Ein vollendeter Fall administrativer Handlungsfähigkeit: CLUE.COM im Jahr 1996

Die Domain-Namensstreit-Richtlinie von Network Solutions vom Juli 1995 schrieb Benachrichtigung und Verfahrensoptionen für den eingetragenen Inhaber vor, wenn ein qualifizierter Markenanspruch vorgelegt wurde. Spätere Beschreibungen dieser Richtlinie allein begründen ein Verfahren, nicht die vollendete Abhängigkeit. Ein spezifischer Fall liefert die fehlenden Beweise.

Das Urteil von 1998 inOppedahl & Larson v. Network Solutionsbeschreibt den Hintergrund der Annahme der Juli-1995-Richtlinie. Es identifiziert Zulassungen der Parteien, das Richtlinienexponat und die Reaktion der Richtlinie auf eine zertifizierte Bundesmarkenregistrierung, die mit einem registrierten Domainnamen übereinstimmte. Der Registrar konnte dem Domaininhaber schreiben und bestimmte Optionen anbieten. Diese gerichtliche Darstellung bestätigt das Verfahren, während sie auch Streitigkeiten über dessen Anwendung auf bestehende Inhaber dokumentiert.

Ein separates, zeitgenössisches Gerichtsverfahren dokumentiert die Anwendung der Richtlinie auf eine bestimmte Registrierung. InNetwork Solutions, Inc. v. Clue Computing, Inc.hielt das U.S. District Court for the District of Colorado fest, dass Clue Computing die von Network Solutions verwaltete CLUE.COM-Registrierung innehatte und Hasbro einen konkurrierenden Markenanspruch geltend machte.

Am 1. Februar 1996 informierte Network Solutions Clue Computing, dass die Nutzung der Domain möglicherweise die Marke von Hasbro verletze. Der Registrar verlangte von Clue Computing entweder eine Markenzertifizierung vorzulegen oder die Zuweisung eines neuen Domainnamens zu akzeptieren. Clue Computing blieb kein passiver Name in einer Anzeige. Es reagierte als anerkannter Inhaber, erhob Klage vor einem staatlichen Gericht gegen Network Solutions und versuchte, den Registrar daran zu hindern, die Registrierung auf „hold“ zu setzen.

Am 25. Juni 1996 untersagte das Boulder County District Court Network Solutions, die Registrierung und Nutzung von CLUE.COM zu ändern. Network Solutions hatte inzwischen eine bundesstaatliche Interpleader-Klage eingereicht und sich als Stakeholder präsentiert, der bereit war, die Registrierung und Nutzung nach gerichtlicher Anweisung zuzuweisen. Das Bundesgericht wies diese Klage ab. Es befand, dass die bestehende staatliche Verfügung Network Solutions daran hinderte, die Domain unter bundesstaatliche Kontrolle zu stellen, und dass der Streit auch die vertraglichen Pflichten von Network Solutions gegenüber Clue Computing berührte.

Die Beweiselemente sind ungewöhnlich vollständig:

Datum:Benachrichtigung am 1. Februar 1996, gefolgt von der Klage vor dem Staatsgericht, der Verfügung im Juni und der Bundesentscheidung im Jahr 1996.
Akteure:Network Solutions, Clue Computing, Hasbro, das Boulder County District Court und das Bundesbezirksgericht.
Spezifischer Datensatz:die CLUE.COM-Registrierung im maßgeblichen Registrierungssystem von Network Solutions, zusammen mit der Streitakte des Registrars und der konkurrierenden Markeneinreichung.
Entscheidung:ob der eingetragene Inhaber qualifizierende Nachweise erbringen, einen Ersatznamen akzeptieren, eine Sperrung hinnehmen oder gerichtlichen Schutz erlangen musste.
Konkurrierende Wahrheitsquellen:der Registrierungsdatensatz, Hasbros Markennachweise, die Registrierungsbeziehung, die tatsächliche Nutzung, vertragliche Pflichten und Gerichtsbeschlüsse.
Ausgang:der eingetragene Inhaber erhielt eine Benachrichtigung, trat in das Verfahrensstreitverfahren ein und erwirkte eine Verfügung, die die Registrierung während des laufenden Streits bewahrte; die Bundes-Interpleader-Klage wurde abgewiesen.

Dieser Fall demonstriert administrative Handlungsfähigkeit innerhalb des zugrunde liegenden Registrierungsverfahrens des Registrars. Die aktuelle Registrierung bestimmte, welche Partei Network Solutions als den Inhaber behandelte, dessen Nutzung bedroht war und dessen Reaktion zählte.

Er zeigt nicht, dass Network Solutions die Identität dieser Partei allein durch eine öffentliche WHOIS-Abfrage erlangte. Das Urteil spricht von der maßgeblichen, von Network Solutions verwalteten Registrierung, der Registrarpolitik, der Korrespondenz und den daraus resultierenden Rechtsstreitigkeiten. Die öffentliche WHOIS-Abfrage konnte Registrierungs- und Kontaktinformationen offenlegen, aber der Fall begründet nicht, dass die öffentliche Anzeige die verfahrensrechtliche Stellung von Clue Computing schuf.

Ebenso wenig entschied die Registrierung die letztendliche Markenfrage. Hasbros Markenregister lieferte einen konkurrierenden Anspruch. Clue Computing verließ sich auf vertragliche und gerichtliche Verfahren. Die Verfügung bewahrte den Status quo; sie war keine endgültige Feststellung, dass die öffentlichen Kontaktdaten das Eigentum bewiesen.

Die Stufe der administrativen Handlungsfähigkeit ist daher bewiesen, jedoch nur mit einer wichtigen Einschränkung: Sie ist bewiesen für die Behandlung der Partei durch den Registrar, die in seinem maßgeblichen Registrierungssystem erfasst ist, nicht als allgemeine konstitutive Macht öffentlicher WHOIS-Felder.

Die Kollision vom Oktober 1995: Datenbankmutation und praktische Kontrolle

Das spätere bundesberufungsgerichtliche Urteil inKremen v. Cohenrekonstruiert eine andere Registrierungsänderung vom Oktober 1995.

Network Solutions erhielt ein Schreiben, das angeblich die Löschung einer bestehenden Domainregistrierung und die Registrierung durch eine andere Partei autorisierte. Auf das Schreiben hin löschte Network Solutions die frühere Registrierung aus seiner Datenbank, registrierte die Domain auf eine andere Organisation und führte einen neuen administrativen Kontakt auf. Das Schreiben erwies sich später als gefälscht. Der neue Inhaber nutzte die Domain. Als die Wiederherstellung verlangt wurde, verlangte Network Solutions zunächst eine gerichtliche Anordnung. Der Rechtsstreit führte schließlich zur Wiederherstellung der Registrierung.

Das Urteil wurde Jahre nach der Transaktion verfasst. Es ist ein Nachweis für die rekonstruierte Abfolge und die gerichtlichen Feststellungen, nicht ein zeitgenössisches Betriebsprotokoll.

Fünf Realitäten müssen getrennt bleiben:

Maßgebliche Registrierungsdatenbank:Network Solutions löschte eine Registrierung und trug eine andere ein.
Öffentliche WHOIS-Ausgabe:Eine Abfrage konnte aus dem aktuellen Registrierungssystem abgeleitete Informationen anzeigen, aber das Urteil besagt nicht, dass eine öffentliche Abfrage die Änderung verursachte.
Änderungsverfahren:Network Solutions handelte auf das eingereichte Schreiben hin.
DNS und Nutzung:Auf die neue Registrierung folgte die praktische Nutzung der Domain.
Dokumentarische und rechtliche Beweise:Die scheinbare Autorisierung stand im Widerspruch zur echten Zustimmung und wurde später als Fälschung beurteilt.

Der datierte Akteur war Network Solutions. Der spezifische Datensatz war sein zugrunde liegender Domainregistrierungseintrag, nicht eine öffentliche WHOIS-Antwort. Die Entscheidung bestand darin, eine Registrierung zu beenden, eine andere anzuerkennen und später die administrative Wiederherstellung ohne gerichtliche Anordnung zu verweigern. Die konkurrierenden Quellen waren der ursprüngliche Antrag, die tatsächliche Organisationsbefugnis, das bestrittene Schreiben, Zeugenaussagen und gerichtliche Feststellungen.

Das Ergebnis war eine Änderung dessen, wer die Registrierung praktisch nutzen konnte, gefolgt von einer späteren gerichtlichen Wiederherstellung.

Dies ist das stärkste Beispiel vor 1997 in dem hier untersuchten Material für eine anspruchsähnliche Konsequenz, die durch Mutation eines maßgeblichen Registrierungssystems entstand. Die Datenbankoperation des Registrars tat mehr, als eine Nachricht fehlzuleiten; sie veränderte den operativen Registrierungsstatus und die praktische Nutzung.

Es beweist nicht, dass die öffentliche WHOIS-Abfrage selbst die Domain übertrug, Eigentum verlieh oder Network Solutions zum Handeln veranlasste. Bestenfalls hätte eine öffentliche Antwort den geänderten Zustand nach der Transaktion widergespiegelt. Die konstitutive Operation fand im maßgeblichen Registrierungs- und DNS-Administrationssystem statt.

Ebenso wenig beweist der Fall, dass jedes frühe Aktualisierungsverfahren unauthentifiziert oder unzuverlässig war. Er dokumentiert einen folgenreichen Fehler mit einer gefälschten Anweisung. Davon zu verallgemeinern, würde die Beweise überdehnen.

Netzwerknummer, ASN und Kontakt: der Nummernressourcen-Datensatz

Die vierte Familie entwickelte sich unter anderen Druckverhältnissen: Adressknappheit, Routingskalierung, Delegation an Provider und regionale Registries sowie die Notwendigkeit, Netzwerke während Betriebsvorfällen zu identifizieren.

Der DDN-Netzwerkkontakt-Vorläufer

Stahls April-1991-Bericht beschriebNETWORK-CONTACTS, eine menschenlesbare Datei für registrierte Internet-Netzwerknummern. Abschnitt 3.10 auf Berichtsseite 11 besagt, dass die Informationen aus Anträgen auf Internet-Nummernregistrierung stammten, die vom NIC-Hostmaster bearbeitet wurden, sowie aus Korrekturen, die von Netzwerkkoordinatoren eingereicht wurden. Die Rohdaten wurden in der NIC-WHOIS-Datenbank gespeichert. Die Ableitung wurde wöchentlich generiert.

Die Kontaktdatei verband eine Netzwerknummer und einen Netzwerknamen mit einem Kontakt und einem NIC-Handle. Ihr operativer Zweck war klar: von einer Nummer zu einer verantwortlichen Organisation oder Person zu gelangen. Sie enthielt nicht die vollständige Zuteilungskorrespondenz, die Provider-Vereinbarung, Nutzungsnachweise oder den Routing-Status.

Dieser Vorläufer darf nicht mit einem Datensatz verwechselt werden, der von einer späteren regionalen Registrierungsstelle erstellt wurde. Die institutionelle Linie setzte sich fort, aber der Betreiber des Datensatzes und die umgebenden Prozesse änderten sich.

Die InterNIC-Population nach April 1993

RFC 1400 platzierte IP-Adressen und autonome Systemnummern mit zugehörigen Kontaktstellen nach dem Übergang im InterNIC-Dienst. Das formalisierte eine objektzentrierte Population: Eine Person erschien zunehmend, weil die Person mit einem registrierten Infrastrukturobjekt verbunden war.

Der Übergang verbesserte die zentrale Auffindbarkeit, aber das Vorhandensein eines Adress- oder ASN-Objekts bewies für sich genommen kein Recht. Zuteilungskorrespondenz, die administrative Entscheidung der Registrierungsstelle, Provider-Beziehungen, das tatsächliche Routing und die fortlaufende Erfüllung von Auflagen blieben getrennt.

RWhois als Designvergleich

RFC 1714vom November 1994 schlug das Referral WHOIS Protocol für eine verteilte Registrierungsumgebung vor. Es unterschied zwischen autoritativen und zwischengespeicherten Antworten, definierte Autoritätsbereiche und verwendete Seriennummern, die sich bei Datenänderungen änderten. Es erlaubte auch Registrierungsoperationen und sah Authentifizierungsinformationen vor.

Diese Merkmale zeigen, dass Designer Herkunft, Autorität, Replikation und Mutation als unterschiedliche Anliegen erkannten. Sie beweisen nicht, dass jedes Produktions-Update von InterNIC oder einer regionalen Registrierungsstelle die vorgeschlagenen Mechanismen verwendete.

Die Authentifizierungsmethode blieb offen. RFC 1714 sagte, weitere Arbeit sei für unbeaufsichtigte Delegation nötig und mehr Forschung sei für die Client-Authentifizierung erforderlich. Sein formeller Sicherheitsabschnitt analysierte keine Sicherheitsfragen. Das Dokument erlaubte auch, dass gelöschte Daten von einem Primärserver verschwinden konnten, anstatt eine dauerhafte Aufbewahrung allein für die sekundäre Aktualisierung zu verlangen.

RWhois ist daher ein Designvergleich von 1994, kein Nachweis für ein universell eingesetztes Prüfsystem. Seine Seriennummern verfolgten den Zustand eines Autoritätsbereichs; sie waren nicht notwendigerweise eine öffentliche Erklärung, wer jedes Objekt änderte, unter welcher Autorität und warum.

RFC 2050 und folgenreiche Registrierungsdaten

Bis November 1996 platzierteRFC 2050die Registrierung innerhalb einer breiteren Zuteilungspolitik. Er beschrieb ein öffentliches Register, das Adressraumzuteilungen und -zuweisungen für Eindeutigkeit und Fehlersuche dokumentierte. Provider waren verpflichtet, Neuzuweisungsinformationen zeitnah einzureichen.

Das Dokument nannte drei Gründe für diese Einreichungen:

Betreiber mussten wissen, wer eine Netzwerknummer nutzte und wen man bei Betriebs- oder Sicherheitsproblemen kontaktieren konnte;
Neuzuweisungsinformationen halfen, die Nutzung einer bestehenden Zuteilung nachzuweisen, bevor zusätzlicher Adressraum gerechtfertigt wurde;
die Daten unterstützten Zuteilungsstudien.

RFC 2050 stellte fest, dass keine weiteren CIDR-Blöcke von einer regionalen Registrierungsstelle oder einem Upstream-Provider zugeteilt würden, bis ungefähr 80 Prozent der Neuzuweisungsinformationen eingereicht worden seien. Er sagte auch, dass Provider dokumentierte Begründungen für Zuweisungen aufbewahren sollten und dass nicht verfügbare Unterlagen künftige Zuteilungen beeinflussen könnten.

Dies war eine bedeutende Änderung der Konsequenzen. Die Registrierung war nicht länger nur ein Verzeichniseintrag, der nach einer Zuteilung erstellt wurde. Die Pflege von Neuzuweisungsdaten war Teil der fortlaufenden administrativen Pflichten eines Providers.

RFC 2050 reduzierte die Zuteilung dennoch nicht auf eine WHOIS-Zeile. Eine Registrierungsstelle konnte technische Pläne verlangen, vorherige Zuweisungen prüfen, die Auslastung verifizieren, organisatorische Unterlagen anfordern und einen Antrag prüfen. Er unterschied Zuteilungen an Provider von Zuweisungen an Endkunden. Er empfahl, Provider-basierte Adressen als an die Konnektivität gebundene Leihgaben zu behandeln, und warnte, dass die Zuteilung keine Routingfähigkeit garantiere. Übertragungen erforderten die Zustimmung der regionalen Registrierungsstelle gemäß den geltenden Kriterien.

Die Bedeutung des Datensatzes auf der oberen Stufe ist daher normativ und nicht fallspezifisch:

Datierte Richtlinie:RFC 2050, November 1996.
Von der Richtlinie benannte Akteure:regionale Registrierungsstellen, lokale Registrierungsstellen, Provider und antragstellende Organisationen.
Datensatz:Zuteilungs-, Zuweisungs- und Neuzuweisungsdaten.
Entscheidung:Betriebskontakt und ob die nachgewiesene Nutzung zusätzlichen Adressraum rechtfertigte.
Konkurrierende Wahrheitsquellen:Kundenzuweisungen, Nutzungsnachweise, technische Pläne, Routing-Tabellen, Provider-Verträge, organisatorische Dokumente und Registrierungskorrespondenz.
Festgelegte Konsequenz:unzureichende Neuzuweisungsinformationen oder Begründungen konnten künftige Zuteilungen beeinträchtigen.
Grenze:Die Quelle dokumentiert keine bestimmte Zuteilungsakte vor 1997, in der eine benannte Registrierungsstelle diese Entscheidung traf und vollendete.

RFC 2050 beweist die politische Beziehung zwischen Registrierung und Zuteilung. Ohne eine Fallakte beweist er nicht, wie konsequent die Regel angewendet wurde oder dass eine öffentliche WHOIS-Ausgabe allein über einen bestimmten Antrag entschied.

Prüfung und Vertraulichkeit außerhalb des Abfrageprotokolls

RFC 2050 liefert zwei wichtige Grenzen, die ein WHOIS-zentrierter Bericht übersehen kann.

Erstens gab Abschnitt 6 einer Organisation das Recht, eine Entscheidung der Registrierungsstelle bei der übergeordneten Registrierungsstelle anzufechten. Die zuweisende Registrierungsstelle musste relevante Unterlagen zur Verfügung stellen. Weitere Rechtsmittel konnten die Hierarchie hinauf verfolgt werden und, nachdem andere Wege erschöpft waren, zu IANA für eine endgültige Entscheidung. Jede Registrierungsstelle sollte ihr Beschwerdeverfahren dokumentieren.

Zweitens verlangte Abschnitt 4.6 von der zuweisenden Registrierungsstelle, Informationen, die von einer antragstellenden Organisation ausdrücklich als sensibel gekennzeichnet waren, vertraulich zu behandeln. Wenn die Vertraulichkeit nicht gewährleistet werden konnte, konnte die übergeordnete Registrierungsstelle in die Zuweisung einbezogen werden.

Keine der beiden Kontrollen war ein Merkmal des Port-43-Abfrageprotokolls. Das öffentliche Register und die vertrauliche Antragsakte waren nicht identische Datensätze. Die Beschwerdeakte und der öffentliche Kontaktdatensatz waren ebenfalls unterschiedlich. Ein Benutzer, der WHOIS einsah, würde nicht notwendigerweise die sensiblen technischen Nachweise, die Begründung der Registrierungsstelle oder die im Beschwerdeverfahren übermittelten Dokumente sehen.

Für Nummernressourcen-Datensätze ergibt sich daher folgende Prüfung:

Herkunft:Provider, lokale Registrierungsstellen oder antragstellende Organisationen lieferten Zuweisungen und unterstützende Materialien.
Aktualisierungsberechtigung:RFC 2050 erlegte zeitnahe Einreichungspflichten auf, spezifizierte aber keine einheitliche technische Authentifizierungsmethode für jede Aktualisierung.
Authentifizierung und Verifikation:Registrierungsstellen konnten prüfen und bestätigende Unterlagen verlangen; der öffentliche Datensatz legte nicht alle diese Nachweise offen.
Korrektur und Ersetzung:der umgebende Registrierungsprozess konnte Datensätze revidieren, aber RFC 2050 definierte keine allgemeine öffentliche Versionsgeschichte.
Zeit:zeitnahe Einreichung war gefordert; eine aktuelle öffentliche Zeile offenbarte nicht notwendigerweise den vollständigen Wirkungsverlauf.
Überprüfung:Beschwerden gingen durch die Registrierungshierarchie und konnten letztlich IANA erreichen.
Datenschutz:die Registrierung hatte eine öffentliche Betriebskomponente, während vom Antragsteller als sensibel gekennzeichnete Informationen vertraulich bleiben sollten.
Anspruch:die Registrierung konnte die Zuteilungsverwaltung beeinflussen, garantierte aber weder Routingfähigkeit noch diente sie als vollständiges Rechtsinstrument.

Vergleich der vier Datensatzfamilien

Die gemeinsame WHOIS-Oberfläche verbarg unterschiedliche beweisrechtliche Grenzen.

Datensatzfamilie	Primärer Gegenstand	Stärkste nachgewiesene Nutzung vor 1997	Änderungs- und Korrekturbelege	Grenzen des Verlaufs und der Prüfung
Persönliches Verzeichnis-WHOIS	Eine Person und Kontaktkanäle	Verzeichnisbequemlichkeit	An das NIC gesendete Registrierungsinformationen; keine umfassende öffentliche Aktualisierungs-Authentifizierungsregel in RFC 812 oder RFC 954	Keine spezifizierte öffentliche datensatzbezogene Versionsgeschichte oder Prüfung bestrittener Identitäten
DDN-Host- und Netzwerkkontakte	Hosts, Netzwerke und verantwortliche operative Rollen	Operative Abhängigkeit und eingeschränkte Verantwortungszuweisung	Netzwerkanweisungen, monatliche Korrekturaufforderungen, freiwillige Aktualisierungen und wöchentlich generierte Derivate, dokumentiert im Bericht vom April 1991	Dateibasierte Versionen legten nicht notwendigerweise jedes ersetzte Feld oder jede Konfliktentscheidung offen
Domainregistrierung und WHOIS	Organisation, Domain, Kontakte und Nameserver	Vorgeschriebene Verifikation; vollendete administrative Handlungsfähigkeit im zugrunde liegenden Registrierungsverfahren eines Registrars von 1996; praktische Konsequenzen aus einer autoritativen Datenbankmutation von 1995	Domainanträge und Korrekturen; Parser-Verifikation von 1993 durch den ursprünglichen Antragsteller; Registrarpolitik und Korrespondenz	Kein Beweis, dass öffentliches WHOIS allein Änderungen autorisierte, Handlungsfähigkeit schuf oder Ansprüche entschied; Streitigkeiten hingen von Vereinbarungen, Markennachweisen, DNS, Korrespondenz und Gerichten ab
Numernressourcen-Registrierung	Netzwerknummern, ASNs, Zuteilungen, Zuweisungen und Kontakte	Operativer Kontakt und richtlinienbasierter Einfluss auf zusätzliche Zuteilungen	Registrierungsanträge, Koordinatorenkorrekturen, zeitnahe Neuzuweisungspflichten, Prüfungen und unterstützende Dokumente	Kein identifizierter Fall vor 1997, der zeigt, dass eine öffentliche Zeile eine Zuteilung entschied; vertrauliche Nachweise, Begründungen, frühere Versionen und Beschwerdeunterlagen konnten außerhalb der Abfrage bleiben

Dieser Vergleich verhindert zwei falsche Geschichtsbilder.

Das erste würde mit dem persönlichen Verzeichnis von 1982 beginnen und jedes spätere Registrierungsobjekt als vergrößerte Version derselben Telefonbucheintragszeile behandeln. Das ignoriert die unterschiedlichen Pflichten, die Hostmanager, Domain-Administratoren, Inhaber, Provider und Ressourcenkontakte trugen.

Das zweite würde mit einer folgenreichen Domainregistrierungsmutation beginnen und deren Macht rückwärts auf jede frühere WHOIS-Antwort projizieren. Das ignoriert den Unterschied zwischen einer öffentlichen Anzeige und dem maßgeblichen System, das in der Lage ist, eine Registrierung oder Delegierung zu ändern.

Die Leiter, mit ihren freigelegten Grenzen

Die Beweisleiter kann jetzt anhand datierten Verhaltens geprüft werden, nicht nur anhand von Feldnamen.

Stufe	Datierter Akteur und Datensatz	Entscheidung	Konkurrierende Wahrheitsquelle	Ergebnis und Grenze
Verzeichnisbequemlichkeit	ARPANET- und DDN-Benutzer, beschrieben in RFC 812 (1982) und RFC 954 (1985), die persönliche und organisatorische Einträge abfragten	An wen man sich wendet oder welcher Eintrag zu einem Namen passt	Arbeitgeberverzeichnisse, Host-Accounts, Standortlisten, direkte Bestätigung	Der Dienst bot einen menschenlesbaren Ausgangspunkt; keine Anspruchskonsequenz wird gezeigt
Operative Abhängigkeit	Betroffene Standorte und CERT/CC im italienischen Vorfall vom Dezember 1990, unter Verwendung eines DDN-NIC-Netzwerkdatensatzes	Welche Institution wegen des beobachteten Verkehrs kontaktiert werden sollte	Protokolle, Routing-Informationen, lokale Administration, direkte Untersuchung	Die Abfrage lenkte die Reaktion auf eine Institution
Verantwortungszuweisung	Dieselben Reagierenden, unter Nutzung der Netzwerk-zu-Organisation-Zuordnung	Welche Organisation untersuchen und handeln sollte	Kontrolle der tatsächlichen Maschine und institutionelle Autorität	Verantwortung wurde auf Netzwerk- oder Institutionsebene zugewiesen, nicht abschließend einem Maschinenadministrator oder Benutzer
Administrative Handlungsfähigkeit	Network Solutions am 1. Februar 1996, unter Verwendung der CLUE.COM-Registrierung und Streitakte, um Clue Computing zu benachrichtigen	Welcher eingetragene Inhaber auf den Markenanspruch antworten musste und eine drohende Sperrung oder Änderung anfechten konnte	Markennachweise, Registrierungsbeziehung, tatsächliche Nutzung, vertragliche Pflichten, Gerichtsbeschlüsse	Der eingetragene Inhaber erhielt Benachrichtigung, prozessierte und erwirkte eine Verfügung; öffentliches WHOIS allein schuf diese Handlungsfähigkeit nachweislich nicht
Anspruchsähnliche Folgerung	Network Solutions im Oktober 1995, als es seine maßgebliche Domainregistrierungsdatenbank nach einer angeblichen Autorisierung änderte	Ob eine Registrierung beendet, eine andere erstellt und später der ursprüngliche Zustand wiederhergestellt werden sollte	Tatsächliche Autorität, ursprüngliche Korrespondenz, bestrittenes Schreiben, Zeugenaussagen, gerichtliche Feststellungen	Die Datenbankmutation zog praktische Nutzungskonsequenzen nach sich; der Fall zeigt nicht, dass eine öffentliche WHOIS-Abfrage die Änderung verursachte

Die Nummernressourcen-Administration erreichte eine verwandte, aber weniger vollständig dokumentierte obere Stufe in RFC 2050. Registrierungs- und Neuzuweisungsdaten waren vorgeschriebene Eingaben für künftige Zuteilungsentscheidungen. Ohne eine vollendete Fallakte bleibt dies ein Richtliniennachweis erwarteter administrativer Konsequenz und kein Beweis dafür, dass eine öffentliche Zeile einen bestimmten Antrag entschied.

Das Ergebnis ist asymmetrisch. Verzeichnisbequemlichkeit, operative Abhängigkeit und Verantwortungszuweisung sind durch Spezifikationen und einen datierten Vorfall gut gestützt. Administrative Handlungsfähigkeit wird in einem spezifischen Registrarverfahren mit einem maßgeblichen Domainregistrierungsdatensatz demonstriert. Anspruchsähnliche Konsequenz wird durch die Mutation dieses maßgeblichen Systems demonstriert. Die verfügbaren Beweise zeigen nicht, dass öffentliches WHOIS vor 1997 zu einer universellen Quelle von Handlungsfähigkeit oder Rechtsansprüchen wurde.

Woher die Autorität kam

WHOIS erlangte seine Kraft nicht allein durch technisches Protokoll.

RFC 812 stellte fest, dass das NIC von SRI den Dienst im Auftrag der Defense Communications Agency betrieb. Stahls April-1991-Bericht identifiziert einen Regierungsauftrag, den verantwortlichen Auftragnehmer, das Lieferobjekt, die Quelldatenbank und abgeleitete Dateien. RFC 1400 dokumentiert den Übergang der nicht-DDN Dienste zu InterNIC.

DieRechtsgeschichte des Government Accountability Officehält fest, dass die National Science Foundation 1993 eine Kooperationsvereinbarung mit Network Solutions einging, um erweiterte und koordinierte Informationsdienste für das nicht-militärische Internet bereitzustellen. Diese Dienste umfassten die Second-Level-Domain-Registrierung, während Network Solutions auch mit USC beim Root-Zonen-Management zusammenarbeitete.

Die praktische Autorität der Datenbank stammte aus diesen institutionellen Zuweisungen, den darunter erbrachten Registrierungsdiensten und der Bereitschaft anderer Akteure, den gepflegten Datensatz als aktuell zu behandeln. Die Autorität lag in der anerkannten Funktion einer Organisation und ihrer Fähigkeit, auf ihre Datenbank zu reagieren, nicht in der Syntax einer Port-43-Antwort.

Die GAO-Geschichte enthält auch eine beweisrechtliche Warnung. Sie beschreibt ihre Schlussfolgerungen als durch eine unvollständige Aktenlage begrenzt und vermerkt, dass wichtige Vertragsdokumente aus den 1970er bis 1990er Jahren nicht beschafft werden konnten. Die erhaltenen Vereinbarungen und Berichte verorten die Dienste innerhalb bundesstaatlicher Förderung und Auftragnehmerleistung. Sie stützen nicht die weitreichende Behauptung, dass ein Vertrag jedes Kontaktfeld in einen Rechtstitel umwandelte.

SRI-NIC, DDN-NIC, InterNIC, Network Solutions, IANA und die regionalen Registrierungsstellen waren verwandte, aber nicht austauschbare Institutionen. Ihre Gemeinschaften, zugewiesenen Funktionen, Quellenmaterialien und Datensätze änderten sich. Die Kontinuität der Daten garantierte nicht, dass jeder übernommene Eintrag nach den Verfahren eines Nachfolgers erneut authentifiziert worden war.

Historisch begrenzte Datenschutz- und Korrekturkosten

Datenschutz tritt in diese Geschichte ein, weil die ursprünglichen Felder für Erreichbarkeit gewählt wurden.

Der persönliche Verzeichnisdienst legte bewusst genug Informationen offen, um Personen zu finden und zu kontaktieren. DDN-Betriebsdateien konnten Rolleninhaber und umfangreiche Kontaktkanäle offenlegen, weil entfernte Administratoren jemanden erreichen mussten, der handlungsfähig war. Domaindatensätze verbanden identifizierbare Kontakte mit administrativen und technischen Funktionen. Nummernressourcen-Datensätze verbanden Netzwerkkennungen mit Betriebskontakten.

Der historische Wandel bestand nicht einfach von privater zu öffentlicher Information. Er bestand von einem persönlichen Verzeichnis, das einer relativ begrenzten Gemeinschaft diente, zu Infrastrukturaufzeichnungen, die bei Vorfällen, Registrierungsänderungen, Streitigkeiten und Zuteilungsentscheidungen konsultiert wurden.

Dieser Wandel erhöhte die Konsequenz einer veralteten Rolle. Ein früherer Kontakt konnte nach einem Organisationswechsel sichtbar bleiben. Ein aktueller technischer Betreiber mochte keine Richtlinienkompetenz besitzen. Ein administrativer Vertreter mochte autorisiert sein, aber eine Maschine nicht reparieren können. Monatliche Korrekturaufforderungen und wöchentliche Veröffentlichung reduzierten Verzögerungen in Teilen des DDN-Systems, garantierten aber nicht, dass sich die äußere Realität und jedes Derivat gleichzeitig änderten.

Die Aufzeichnung zeigt auch eine Verengung der Population. RFC 1400 sagte, dass die individuellen Datensätze von InterNIC hauptsächlich Kontaktstellen abdecken würden, die mit aktiven Knoten verbunden sind, während allgemeine persönliche Verzeichnisprojekte anderweitig verteilt werden könnten. Bis 1996 unterschied RFC 2050 zwischen öffentlichen Registrierungsinformationen und sensiblem Antragsmaterial, das die Registrierungsstellen vertraulich behandeln mussten, wenn der Antragsteller es als solches kennzeichnete.

Dies waren periodenspezifische Grenzen. Sie sollten nicht so umgeschrieben werden, als ob eine spätere Registrierungsdatenarchitektur bereits 1982 galt. Die historische Frage ist enger: ob Umfang und Form der Kontaktinformationen verhältnismäßig blieben, nachdem die Felder begannen, Entscheidungen jenseits der Auffindung zu beeinflussen.

Die Verringerung öffentlicher Informationen konnte auch betriebliche Kosten verursachen. Der Vorfall vom Dezember 1990 zeigt, warum eine zentrale Abfrage wichtig war: Sie gab entfernten Reagierenden einen institutionellen Ausgangspunkt. Die Schwäche des Datensatzes bestand nicht einfach darin, dass er einen Kontakt offenlegte. Sie bestand darin, dass eine Zuordnung auf Organisationsebene weniger präzise sein konnte, als ein Vorfall erforderte.

Das politische Problem war daher kein einfacher Gegensatz zwischen Offenheit und Datenschutz. Es ging darum, rollenspezifische Erreichbarkeit zu bewahren, ohne die benannte Person in jedem Kontext als Akteur, Kontrolleur, Vertragspartei oder Rechtsinhaber zu behandeln.

Gegenfaktum A: authentifizierte, versionierte und ausdrücklich nicht-konstitutive Datensätze

Man nehme an, dieselben Verzeichniseinträge wären von stärkerer verfahrenstechnischer Authentifizierung begleitet gewesen, hätten vorherige Versionen, Gültigkeitszeitstempel, dokumentierte Änderungsgründe und eine ausdrückliche Aussage bewahrt, dass die Felder Kontakte beschrieben und keine Rechte schufen.

Dies ist ein begrenzter Designvergleich. Kontrollierte Papierformulare, aufbewahrte Korrespondenz, Rückrufverfahren, datierte Protokolle und institutionelle Gegenzeichnungen waren in diesem Zeitraum konzeptionell verfügbar. Ein universelles kryptografisches Identitätssystem, das jeden Netzwerkkontakt mit einer Organisation verknüpfte, war keine etablierte Anforderung von RFC 812. Spätere Annahmen über föderierte Identität, automatisierte Zertifikate oder strukturierte Registrierungsdatendienste dürfen nicht als Pflichten rückprojiziert werden, die die Designer von 1982 ignorierten.

Innerhalb dieser Grenze hätten stärkere Kontrollen mehrere Entscheidungen verbessert.

Ein Benutzer könnte unterscheiden, wann ein Kontakt aktuell wurde und ob der Eintrag einer Fusion, einem Rücktritt, einem Providerwechsel oder einem Delegierungsstreit vorausging. Das Personal könnte die Person identifizieren, die eine Mutation beantragte, die beanspruchte Autorität und den verdrängten früheren Datensatz. Eine bestreitende Partei könnte die genaue Transaktion angreifen, anstatt sich lediglich der letzten öffentlichen Antwort zu stellen.

Die Registrierungskollision vom Oktober 1995 veranschaulicht den Wert. Hätte der Registrar eine Bestätigung über einen unabhängig etablierten Kanal verlangt, die behauptete Autorität des Einreichers dokumentiert, die ersetzte Registrierung als sichtbaren historischen Zustand aufbewahrt und die beantragte Registrierungsänderung von der resultierenden DNS-Aktion getrennt, wäre die fehlerhafte Anweisung möglicherweise früher erkannt oder effizienter rückgängig gemacht worden.

Die Sicherung hätte das Verzeichnis nicht in ein Titelsystem umgewandelt. Authentifizierung beweist, dass eine identifizierte Partei eine Aussage machte. Sie beweist nicht notwendigerweise, dass die Partei über Unternehmensautorität verfügte, dass eine Vereinbarung weiterhin gültig war, dass eine Providerbeziehung fortbestand oder dass ein Gericht den beanspruchten Anspruch anerkennen würde.

Versionierung hat eine ähnliche Grenze. Sie kann zeigen, dass sich ein Feld änderte, und bewahren, was ihm vorausging. Sie kann nicht entscheiden, welcher Zustand rechtlich korrekt war. Ein Grundcode kann erklären, warum das Personal handelte, aber der Grund kann immer noch von einem gefälschten Dokument oder einer bestrittenen Auslegung abhängen.

Eine ausdrückliche Nichtrechtserklärung hätte die institutionelle Absicht klargestellt. RFC 1032 und RFC 1591 lieferten bereits verwandte materielle Grenzen, indem sie sich weigerten, lokale Rechte zu schlichten, oder die Registrierung vom Markenstatus trennten. Die Wiederholung solcher Grenzen in der öffentlichen Antwort hätte sorglose Folgerungen verringern können.

Autoritätsdrift wäre wahrscheinlich dennoch eingetreten. Institutionen bevorzugen Aufzeichnungen, die verfügbar, lesbar und von der für den Dienst verantwortlichen Stelle gepflegt sind. Ein gut authentifiziertes Verzeichnis könnte sogar noch mehr Vertrauen anziehen. Der Unterschied besteht darin, dass spätere Benutzer besser zwischen einer Kontaktbehauptung und einer Zuteilung, einer Registrierung und einem Vertrag sowie einer aktuellen Anzeige und den eine Änderung stützenden Beweisen unterscheiden könnten.

Gegenfaktum B: kein Verzeichnis, während die zugrunde liegenden Beziehungen überleben

Man entferne nun das öffentliche Verzeichnis, während Verträge, Zuteilungskorrespondenz, Registrierungsanträge, Routing-Operationen, DNS-Delegierungen, organisatorische Aufzeichnungen, Protokolle und Telefonnetze intakt bleiben.

Viele Entscheidungen bleiben möglich.

Eine Registrierungsstelle kann anhand ihrer Korrespondenz- und Entscheidungsakte bestimmen, wer eine Zuteilung erhielt. Ein Provider kann seinen Kunden anhand eines Dienstleistungsvertrags identifizieren. Ein Registrar kann einen Antrag und nachfolgende Anweisungen einsehen. Ein Domain-Administrator kann die aktive Delegierung und die autoritativen Nameserver prüfen. Ein Betreiber kann Routing-Informationen einsehen und über benachbarte Netzwerke eskalieren. Ein Gericht kann Zustimmung, Organisationsbefugnis, Vereinbarungen, Markenaufzeichnungen und Zeugenaussagen bewerten.

Die fehlende Funktion ist die schnelle Auffindung über institutionelle Grenzen hinweg.

Im Vorfall vom Dezember 1990 würden die betroffenen Standorte weiterhin über Protokolle verfügen, aber der Weg von einer Netzwerknummer zu einer relevanten Institution wäre langsamer. Reagierende müssten möglicherweise über Routing-Beziehungen, Provider oder manuelle Anfragen arbeiten. Das Verzeichnis schuf weder die Protokolle noch die Verantwortung der Institution. Es senkte die Kosten, die Institution zu finden, die handeln könnte.

In der Domainadministration könnte das DNS die betreibenden Nameserver zeigen, und die Registrierungskorrespondenz könnte den ursprünglichen Antrag zeigen. Ohne ein gemeinsames Verzeichnis wäre es schwieriger, den administrativen Vertreter zu finden. Der DNS-Betrieb würde weiterhin nicht die organisatorische Zustimmung beweisen.

Im CLUE.COM-Streit könnte Network Solutions seinen Inhaber anhand der maßgeblichen Registrierungsdatei und Korrespondenz identifizieren, selbst wenn kein öffentlicher WHOIS-Dienst existierte. Der Registrar könnte weiterhin benachrichtigen, und der Inhaber könnte weiterhin vertragliche oder gerichtliche Rechtsmittel einlegen. Dies zeigt, dass die administrative Handlungsfähigkeit in diesem Fall nicht eindeutig von der Bequemlichkeit einer öffentlichen Abfrage abhing.

In der Nummernressourcen-Administration könnte eine Registrierungsstelle eine zusätzliche Zuteilung anhand der Antragsakte und Nutzungsnachweise bewerten. Ohne standardisierte Registrierungs- und Neuzuweisungsdatensätze wäre die Rekonstruktion früherer Zuweisungen und die Lokalisierung nachgelagerter Kontakte langsamer und weniger konsistent.

Dieses Gegenfaktum identifiziert den besonderen Wert von WHOIS: Es machte heterogene Beziehungen von einer Kennung aus durchsuchbar. Es brachte die erste relevante Person oder Organisation in den Blick.

Es zeigt auch, warum Bequemlichkeit nicht mit konstitutiver Autorität verwechselt werden sollte. Die zugrunde liegende Beziehung konnte das Fehlen des Verzeichnisses überleben. Das Verzeichnis machte diese Beziehung lesbar und handlungsfähig; je nach System blieben die maßgebliche Registrierungstransaktion, die Zuteilungsentscheidung, der Vertrag oder der Betriebszustand anderswo.

Die Schwelle von 1997

Die institutionelle Geschichte von ARINbesagt, dass es im Dezember 1997 als unabhängige gemeinnützige Organisation gegründet wurde, die IP-Registrierungsdienste in ihrer Region anbietet. IhrJahresbericht 1999datiert die Betriebsaufnahme auf den 22. Dezember 1997.

Vor diesem Datum hatten sich mehrere Aussagen gut gestützt:

eine zentrale Abfrage konnte Personen und Organisationen mit Internet-Kennungen verknüpfen;
von rollenspezifischen Kontakten wurde erwartet, dass sie erreichbar und handlungsfähig sind;
Hostmasters verwendeten Anträge, Anweisungen, anerkannte Administratoren und Korrektureinreichungen zur Pflege der Datensätze;
einige DDN-Derivate wurden wöchentlich neu generiert und durch monatliche Korrekturaufforderungen gestützt;
Betreiber verwendeten Netzwerkkontaktdatensätze, um zu entscheiden, wohin Vorfallmeldungen zu richten sind;
Domain-Administratoren wurden angewiesen, WHOIS-Daten mit den beabsichtigten Registrierungs- und Serverinformationen zu vergleichen;
ein eingetragener Domaininhaber konnte Benachrichtigung erhalten und eine folgenreiche Verfahrensstellung in einem abgeschlossenen Registrarstreit einnehmen;
die Mutation eines maßgeblichen Domainregistrierungsdatensatzes konnte praktische Nutzungskonsequenzen nach sich ziehen;
Numernressourcen-Neuzuweisungsdaten waren vorgeschriebene Eingaben für operative Kontakte und die nachfolgende Zuteilungsverwaltung;
Zuteilungsentscheidungen konnten geprüft, angefochten und durch vertrauliches Material außerhalb des öffentlichen Registers gestützt werden.

Mehrere stärkere Aussagen bleiben durch die hier untersuchten Beweise unbewiesen:

dass jede persönliche, Host-, Domain- oder Nummernressourcen-Aktualisierung eine einheitliche Methode zur Identitätsprüfung verwendete;
dass jeder öffentliche Datensatz eine vollständige Historie früherer Werte und Änderungsgründe offenlegte;
dass ein bestehender öffentlicher Kontakt automatisch die Befugnis besaß, eine Registrierung zu bestätigen oder zu ersetzen;
dass der ursprüngliche Antragsteller von RFC 1400 aufgrund eines früheren öffentlichen Kontaktdatensatzes anerkannt wurde;
dass öffentliches WHOIS allein die administrative Handlungsfähigkeit von Clue Computing im Streit von 1996 schuf;
dass die Kremen-Registrierungsänderung durch Vertrauen auf eine öffentliche WHOIS-Abfrage verursacht wurde und nicht durch das Änderungsverfahren des Registrars und die Datenbankmutation;
dass eine öffentliche Nummernressourcen-Zeile allein über einen dokumentierten Zuteilungsantrag vor 1997 entschied;
dass ein aufgeführter Kontakt abschließend gegenwärtige technische Kontrolle, rechtliches Eigentum oder vertraglichen Anspruch feststellte;
dass DNS-Delegierung ein Recht auf einen IP-Adressblock begründete;
dass eine spätere regionale Registrierungsstelle Datensätze pflegte oder erstellte, bevor sie ihren Betrieb aufnahm.

Der Übergang von der Bequemlichkeit zur Autorität hatte daher kein einziges Datum. Seine stärksten Stufen traten in verschiedenen Datensatzfamilien auf.

Das persönliche WHOIS-Verzeichnis begründete eine bequeme Auffindung. DDN-Host- und Netzwerkkontakte bewegten sich in operative Abhängigkeit und Verantwortungszuweisung. Ein abgeschlossener Domainstreit von 1996 zeigt, dass administrative Handlungsfähigkeit an der maßgeblichen Registrierungsbeziehung des Registrars hing, während die Kremen-Sequenz von 1995 praktische Konsequenzen aus der Mutation dieses maßgeblichen Systems zeigt.

Die Nummernressourcen-Politik machte Registrierungsdaten für künftige Zuteilungsentscheidungen relevant, während sie unterstützende Dokumente, Vertraulichkeit und Beschwerden außerhalb der öffentlichen Abfrage beibehielt.

Die oberen Sprossen der Leiter sind real, aber eng verortet. Vor 1997 zeigt die verfügbare Aufzeichnung nicht, dass öffentliches WHOIS zu einem universellen Rechtsinstrument wurde. Sie zeigt etwas Fragileres und institutionell Aufschlussreicheres: eine bequeme Kontaktschicht, die zum ersten konsultierten Beweis, zum ersten um ein Problem gelegten Rahmen und zum sichtbaren Reflex folgenreicher Entscheidungen wurde, deren Autorität weiterhin aus Datenbanken, Verfahren, Verträgen, Betriebssystemen und Prüfungen jenseits der Abfrage stammte.