Zusammenfassung

  • X.500 definierte eine Wurzel im Namensbaum, aber kein skalierbares Verfahren für ihre Governance. Giant Tortoise ersetzte die vollständige bilaterale Vertragsmatrix durch je eine Vereinbarung zwischen Root und erststufigem DSA.
  • Der Abschied von Quipu war kein Stichtagsprojekt. Wenige DOP-Implementierungen und Fehler in den X.500-Fassungen von 1993 und 1997 führten zu schnellen, langsameren und langfristigen Wegen mit DISP-Shadowing, Zugriffskontrolldaten und hierarchischen operational bindings.
  • Eine lokale Root-Kopie und erfolgreiche List- oder Search-Operationen belegten einen bestimmten Koordinations- und Replikationszustand. Sie bewiesen weder globale Vollständigkeit noch Aktualität, Sicherheit oder allgemeine Zustimmung; der Root-DSA sollte ausdrücklich keine Nutzeroperationen über LDAP, DAP oder DSP bedienen.

RFC 2120 beginnt im Kern mit einem Skalierungsproblem. Die Administratoren der DSAs auf der ersten Ebene sollten den Root naming context gemeinsam erhalten. Wie diese gemeinsame Verantwortung praktisch funktionieren sollte, ließ X.500 offen. Bilaterale Abkommen und private Absprachen füllten die Lücke. Mit jedem neuen DSA wuchs die Zahl der Beziehungen zu allen bereits Beteiligten. Hinter der logischen Baumstruktur entstand ein operatives Netz.

NameFLOW-Paradise hatte die Topologie bereits verändert. Ein nicht standardisierter Root-DSA namens Giant Tortoise hielt die Ländereinträge. Quipu replizierte sie an Länder-DSAs und weitere Directory-Server. Im Juni 1996 waren laut RFC 2120 770 DSAs an dieser Replikation beteiligt. Aus vielen Beziehungen wurde eine Nabe mit Speichen: Jeder DSA der ersten Ebene brauchte nur eine bilaterale Vereinbarung mit dem Root.

Der zentrale Punkt verbesserte zugleich die Suche. Eine klassische Kopie des Root-Kontexts in einem Länder-DSA enthielt vor allem knowledge information. Sie reichte für ein unsicheres List, aber nicht für einen lokalen Filter über die erste Ebene. Quipu konnte die Ländereinträge umfangreicher verteilen, sodass ein Länder-DSA einen one-level Search lokal ausführte, statt ihn an alle Master weiterzuleiten oder zu verweisen.

Zentralisierung machte daraus keine universelle Autorität. Giant Tortoise kompensierte ein nicht standardisiertes Wissensmodell. Eine lokale Kopie wurde nicht zum Master, nur weil sie schnell antwortete. Masterzustand, Kopie, Aktualisierungsvereinbarung, Replikationsereignis und Suchergebnis blieben unterschiedliche Tatsachen.

Der Ersatz musste den Nutzen erhalten, nicht nur standardkonform aussehen

NameFLOW-Paradise wollte auf die ISO-X.500-Protokolle von 1993 umstellen. Das Zielbild schien geradlinig: Root und jeder erststufige Master-DSA bilden über DOP ein hierarchisches operational binding; DISP verteilt den erweiterten Root-Kontext. So bleiben List, one-level Search und die Namensauflösung zu anderen ersten Ebenen vor Ort möglich.

Zwei Hindernisse verhinderten den Sprung. Nur wenige Hersteller hatten DOP implementiert. Zudem enthielten die Standards Lücken. Beim Shadowing von subordinate references übertrug DISP nicht alle Zugriffskontrollinformationen für ein sicheres List. Kopierte Referenzen brachten auch nicht die subordinate entries mit, die ein one-level Search benötigt. Selbst das langfristig vorgesehene Binding am Root war in ASN.1 ausdrückbar, ohne dass der beschreibende Text diese Anordnung anerkannte.

Der schnelle Weg nutzte DISP ohne DOP. Der Administrator eines erststufigen DSA teilte dem Root-Administrator access point und die von ihm gemeisterten relative distinguished names mit – nötigenfalls telefonisch – und schloss eine Shadowing-Vereinbarung. Das sammelte und verteilte Root-Wissen für ein unsicheres List. Es war bewusst unvollständig: Zugriffskontrollen für den sicheren Betrieb und reichhaltigere Einträge für die lokale Suche fehlten.

Der langsamere Weg ergänzte gegenläufige „spot“-Shadowing-Vereinbarungen. Jeder DSA lieferte seinen Mastereintrag an den Root. Dort wurde die Kopie so ergänzt, als stamme sie aus einem hierarchischen Binding, einschließlich einer subordinate reference zum Master. Ein zweites Shadowing verteilte den vervollständigten Kontext wieder nach außen. Nach der Korrektur zweier Standardfehler konnte dies sicheres List und one-level Search tragen. Die beim DANTE-Treffen 1996 vertretenen Hersteller rechneten mit einer breiteren Lösung kaum vor Mitte 1998.

Erst der langfristige Weg setzte DOP-bindings ein. Der DSA der ersten Ebene blieb Master seiner Einträge. Das Binding hielt subordinate references, Filterattribute, collective attributes und Zugriffskontrolldaten mit dem Root synchron. Dieser verteilte einen Shadow des Root-Kontexts an die Teilnehmer.

Die drei Wege erzeugten keine gleichwertigen Belege. Ein sichtbarer Verweis im schnellen List sagte wenig über sicheren Zugriff. Ein erfolgreicher Search auf der langsameren Kopie belegte Attribute am antwortenden DSA, nicht deren aktuelle Übereinstimmung mit dem Master. Ein DOP-binding belegte eine standardisierte Betriebsbeziehung, nicht die fehlerfreie Implementierung aller Hersteller oder die Teilnahme aller Administratoren.

Der Root war absichtlich kein öffentliches Frontend

RFC 2120 sah einen einzigen Master-Root-DSA vor, entzog ihm aber die normale Nutzerrolle. Er sollte keine Directory-Operationen über LDAP, DAP oder DSP anbieten. Nutzer sollten DSAs der ersten Ebene mit Shadow-Kopien abfragen. Die Wurzel war damit Koordinations- und Replikationspunkt, nicht globale Suchmaschine.

Das grenzt RFC 2120 auch von RFC 2148 ab. Der spätere White-Pages-BCP fragte, wer einen Personendatensatz erhebt und pflegt, wie eine Organisation ihn aktuell hält, welche Datenschutzrechte gelten und wie Clients den Dienst erreichen. RFC 2120 behandelte die engere Abhängigkeit: Wie teilen Systeme den oberen Namensraum ohne vollständige Abkommensmatrix, und wie ersetzen sie einen proprietären Mechanismus ohne Funktionsverlust?

Ein erfolgreiches List zeigt, dass bestimmte Namen oder Referenzen unter dem Zustand und den Zugriffsregeln des antwortenden DSA sichtbar waren. Ein one-level Search zeigt, dass seine Kopie genügend Attribute zum Filtern besaß. Keines beweist globale Abdeckung, aktuelle Daten bei allen Mastern, Berechtigung für jeden Aufrufer oder eine weltweit einheitliche Politik.

RFC 1276 hatte Quipu als vorläufigen De-facto-Standard beschrieben: in Pilotnetzen bewährt, rasch einsetzbar und zugleich mit bekannten Grenzen bei Verwaltung und Skalierung. RFC 2120 dokumentiert die Brücke vom laufenden System zu standardnäheren Verfahren. Seine bleibende Forderung ist Präzision: Welcher operative Nutzen wird bewahrt, welchen Beleg liefert jede Stufe, und welche Behauptung muss weiterhin anderswo begründet werden?

Quellen