Résumé

  • L’arbre X.500 définissait un contexte racine, mais pas une procédure de gouvernance extensible. NameFLOW-Paradise remplaça le réseau d’accords entre tous les DSA de premier niveau par un accord entre chacun d’eux et un DSA racine non standard, Giant Tortoise.
  • Le passage de la réplication propriétaire Quipu aux protocoles ISO ne pouvait être instantané. Le faible support de DOP et des défauts des éditions 1993 et 1997 imposèrent une voie rapide, une voie plus complète et une solution de long terme.
  • Une copie de la racine, une opération List réussie ou une recherche à un niveau ne prouvaient ni fraîcheur universelle, ni exhaustivité, ni autorité globale. Le DSA racine proposé ne devait d’ailleurs répondre à aucune opération utilisateur LDAP, DAP ou DSP.

Le problème n’était pas la forme de l’arbre, mais la géométrie des accords qui le faisaient fonctionner. X.500 plaçait les DSA de premier niveau juste sous la racine du DIT. Leurs administrateurs devaient gérer collectivement le contexte racine, mais par des accords bilatéraux ou des moyens privés situés hors de la norme. Quand un nouveau DSA arrivait, il devait traiter avec chacun de ceux qui existaient déjà. Un arbre logique élégant reposait donc sur un maillage administratif de plus en plus lourd.

NameFLOW-Paradise avait introduit un raccourci. Un DSA racine unique, Giant Tortoise, détenait les entrées de pays, puis la réplication Quipu les diffusait vers les DSA nationaux et d’autres serveurs. RFC 2120 indique qu’en juin 1996, 770 DSA répliquaient ces informations. Chaque administrateur de premier niveau n’avait plus à négocier avec tous les autres : un accord avec la racine suffisait pour fournir ses propres informations et recevoir le contexte complet assemblé.

Cette architecture rendait aussi possible une recherche locale plus utile. Le contexte racine prévu par les éditions antérieures de X.500 contenait surtout des informations de connaissance et un indicateur d’alias. Cela permettait une opération List non sécurisée, mais pas une recherche à un niveau portant sur les attributs des entrées. Quipu diffusait davantage d’informations sur les pays. Un DSA de premier niveau pouvait alors filtrer sa copie locale au lieu de chaîner ou de renvoyer l’opération vers tous les maîtres.

Mais Giant Tortoise ne devenait pas pour autant l’auteur de chaque entrée. Une copie distribuée n’était pas automatiquement à jour. Une recherche réussie ne disait pas quel maître avait fourni l’attribut, à quel moment la réplication avait réussi ou si les mêmes règles d’accès s’appliquaient partout. Le centre réduisait le coût de coordination ; il n’absorbait pas toutes les autorités du système.

Trois chemins parce que le standard et les produits n’étaient pas au même endroit

La cible paraissait nette. Le DSA racine et chaque DSA maître de premier niveau devaient établir une liaison opérationnelle hiérarchique avec DOP. Ils concluraient ensuite un accord de shadowing DISP pour distribuer un contexte racine enrichi. Chaque DSA de premier niveau pourrait ainsi effectuer List, Search à un niveau et la résolution de noms sans interroger tous les autres.

Cette cible n’était pas immédiatement exécutable. Peu de fournisseurs avaient implémenté DOP. Des défauts normatifs bloquaient en outre le résultat recherché. Les informations de contrôle d’accès nécessaires à une opération List sûre n’étaient pas toutes transmises avec les références subordonnées. La réplication de références ne suffisait pas non plus à une Search locale : il fallait copier les entrées subordonnées et leurs attributs. Enfin, l’ASN.1 permettait la liaison hiérarchique envisagée, mais le texte de X.500 ne reconnaissait pas précisément cet usage du DSA racine.

La voie rapide acceptait donc une fonction plus étroite. L’administrateur d’un DSA maître fournissait au responsable de la racine son point d’accès et les RDN des entrées qu’il maîtrisait—éventuellement par téléphone—puis le DSA de premier niveau consommait une copie du contexte racine via DISP. Il obtenait les références de connaissance nécessaires à List, mais pas encore toutes les données d’accès et d’entrée requises pour une recherche sûre.

La voie plus lente imitait temporairement une liaison hiérarchique à l’aide de shadowing. Chaque DSA maître devenait fournisseur de son entrée de premier niveau vers la racine. L’administrateur ou le logiciel de la racine ajoutait ensuite la référence subordonnée correspondant au maître, avant de redistribuer l’ensemble. Cette solution pouvait fournir List et Search sûres, à condition de corriger les deux défauts des textes 1993 et 1997. Les fournisseurs réunis par DANTE en 1996 ne l’attendaient pas dans leurs produits bien avant le milieu de 1998.

La voie de long terme utilisait enfin DOP. Les liaisons opérationnelles hiérarchiques maintenaient les références de catégories maître et copie, les attributs servant au filtrage, les attributs collectifs et les informations de contrôle d’accès. Chaque DSA de premier niveau demeurait maître de ses entrées ; la racine entretenait et redistribuait la vue coordonnée.

Ces voies n’offraient pas le même type de preuve. La voie rapide pouvait montrer qu’une référence était listable. La voie lente pouvait montrer qu’un DSA particulier possédait les entrées et contrôles nécessaires à une recherche locale. Une liaison DOP pouvait prouver qu’une relation standardisée était active. Aucune de ces observations ne démontrait à elle seule que tous les DSA participaient, que chaque copie était fraîche ou que le contenu formait une vérité mondiale.

Une racine sans guichet utilisateur

Le détail le plus révélateur de RFC 2120 est peut-être négatif : le DSA racine maître ne devait offrir aucune opération d’annuaire aux utilisateurs par LDAP, DAP ou DSP. Les utilisateurs devaient interroger les DSA de premier niveau qui détenaient les copies. La racine servait à assembler, relier et répliquer, pas à devenir un moteur mondial de recherche.

C’est aussi ce qui sépare cette histoire de RFC 2148. Le BCP sur les pages blanches s’intéressait à l’organisme qui maintient la fiche d’une personne, à sa qualité, à sa mise à jour, à la vie privée et à l’accès des clients. RFC 2120 traite de la couche située en dessous : comment rendre le sommet de l’espace de noms découvrable sans obliger tous les administrateurs à se lier directement, puis comment remplacer la réplication propriétaire sans perdre le service utile.

RFC 1276 avait présenté Quipu comme une solution intérimaire, déjà éprouvée dans des pilotes, mais dotée de limites connues de gestion et de passage à l’échelle. RFC 2120 ne nie pas cette expérience. Il la transforme en exigences de migration. Le code en fonctionnement prouvait qu’une coordination centrale et des copies locales pouvaient être utiles ; il ne prouvait ni que le mécanisme devait rester propriétaire, ni que son centre détenait une souveraineté sur l’annuaire.

La conclusion historique tient dans cinq distinctions. Une syntaxe standard n’est pas encore une procédure complète. Un accord bilatéral n’est pas un mandat universel. Une copie n’est pas nécessairement fraîche. Une recherche réussie n’est pas l’autorité sur les données. Et un point central de coordination peut rester précieux précisément parce qu’on limite ce qu’il prétend être.

Sources