Zusammenfassung

  • RFC 1302 verlangte vier NIC-Grundfunktionen: Informationsressourcen, direkte Nutzerhilfe, Weiterleitungswissen und Unterstützung der gemeinsamen NIC-Infrastruktur.
  • Verantwortung bis zur Lösung bedeutete nicht, dass Antwort, Verweis und Koordination mit einem NOC dasselbe Ergebnis belegten.
  • Zeitstempel, Revision und produzierendes NIC ermöglichten Herkunftsprüfung, garantierten aber weder Richtigkeit noch Aktualität oder Problemlösung.

Herkunftsfelder waren eine Einladung zur Prüfung

Ein NIC konnte Material von einem anderen Standort lokal speichern, auf eine entfernte Quelle verweisen oder eigene Informationen erstellen. Nur im dritten Fall erklärte RFC 1302 das erstellende NIC allein für Inhalt und Richtigkeit verantwortlich. Der sichtbare Ablageort war somit nicht automatisch der Urheber.

Jede angebotene Ressource sollte Zeitstempel, Revisionsnummer und Name des produzierenden NIC tragen. Zusätzlich sollte der Kontakt zur Quelle erhalten bleiben. Diese Angaben machten vergleichbar, welche Fassung vorlag und wen man fragen konnte. Sie bestätigten die Aussage nicht selbst. Eine neue Datumsangabe kann an einem Fehler stehen; eine getreue Kopie kann nach einer entfernten Revision veralten.

RFC 1290 behandelte die benachbarte Grenze zwischen einem Wegweiser und der endgültigen Information. RFC 1309 zeigte eine einheitliche Verzeichnisansicht über verteilte Verwalter, Kopien und Verweise. RFC 1302 widmete sich der Verantwortung dafür, dass der fragende Mensch zwischen solchen Oberflächen nicht verloren ging.

Eine einheitliche Mailadresse standardisierte nur den Anfang

Mit NIC@domain sollte ein Nutzer eine erkennbare Eingangstür erhalten. Darauf sollte entweder ein Mensch antworten oder eine aktuelle automatische Nachricht die Anfrage nach Problemklassen vorsortieren.

Erreichbarkeit des Postfachs bewies den Eingang. Die automatische Antwort bewies eine Klassifikation. Ob die Zielstelle annahm, ob das Dokument passte, ob eine Betriebsänderung erfolgte und ob der Nutzer sein Ziel erreichte, blieb offen.

Der RFC forderte best effort und Verantwortung bis zu einer Lösung „auf irgendeine Weise“. Als Möglichkeiten nannte er Antwort, Verweis an die passende Informationsquelle oder Koordination mit einem NOC bei einem Verbindungsproblem. Diese Abschlüsse erfüllten verschiedene Pflichten. Ein ausgestellter Verweis war keine angenommene Übergabe; begonnene Koordination war keine Reparatur.

Informationszentrum und Betriebszentrum

Das NIC bot informationelle, administrative und prozedurale Unterstützung. Das NOC überwachte und unterhielt den täglichen Netzbetrieb. Eine Organisation konnte beide Rollen tragen, und enge Zusammenarbeit war nötig, doch ihre Aussagen blieben verschieden.

Eine Störungsmeldung gab dem NIC keine technische Änderungsbefugnis. Eine NOC-Aktion belegte nicht die Wiederherstellung des vom Nutzer gesuchten Dienstes. Eingang, Diagnose, Autorisierung, Handlung, Messung und Nutzerergebnis brauchten eigene Nachweise.

Auch für Sicherheitsfragen verlangte RFC 1302 bekannte Zuständigkeiten und klare Verfahren zur Zusammenarbeit mit Reaktionszentren, NOCs und Nutzern. Den Eskalationsweg zu kennen hieß nicht, einen Vorfall zu führen oder seine Behandlung zu belegen.

Das Wissen blieb föderiert

Kein einzelnes NIC konnte vollständige, aktuelle Informationen über sämtliche Internetdienste und Ressourcen halten. Darum sollten NICs andere Zentren und deren Fachgebiete kennen. Die gemeinsame Datenbank nic-profiles sollte dieses Weiterleitungswissen verfügbar machen.

Ein Profil war eine Route, keine Annahmebestätigung. Ohne korrespondierenden Empfang konnte der Absender schließen, während die Anfrage zwischen Systemen lag. Die vier Grundfunktionen schufen deshalb ein Kooperationsminimum. Personal, Finanzierung, Serviceniveau und Umsetzung blieben lokal; Standardisierung der Tür bedeutete keine Gleichheit der Kapazitäten.

Ein jährlicher Aufruf war keine Dauergarantie

Bei Datenerhebung sollten Zweck, Verwendung, Folgen von Ablehnung oder Widerruf, Pflicht- und Wahlfelder, öffentliche Angaben, Änderungsbefugnis und Aktualisierungsrhythmus offengelegt werden. Betroffene sollten öffentliche Personendaten kennen und ändern oder widerrufen können.

NICs sollten mindestens jährlich aktiv Aktualisierungen anfordern und das Datum der letzten Änderung veröffentlichen. Das war eine Wartungshandlung, keine Wahrheitsgarantie für die Zwischenzeit. Das Datum machte Unsicherheit messbar.

RFC 1261 hatte die Schichten zuvor praktisch getrennt: Während des Übergangs von SRI zu GSI sollten vertraute NIC-Oberflächen weiterwirken, doch die WHOIS-Masterdatenbank und alle Registrierungsaktionen blieben fünf Tage unverändert. Erreichbarkeit, Schreibautorität und tatsächliche Änderung waren eigene Zustände.

Quellen

RFC 1302 beschreibt ein Modell von 1992 und belegt kein heutiges NIC, keinen realen Fall, keine angenommene Weiterleitung, Reparatur, Datenrichtigkeit, Reaktion oder Nutzerwirkung.