Résumé

  • La revue de la révision 20 du modèle IVY demande de préciser que le contrôleur supérieur, lorsqu’il sert un inventaire combiné, doit assurer l’unicité des clés ne-id qu’il expose.
  • Éviter deux clés identiques ne suffit pas : il faut encore décider si deux fiches décrivent deux équipements distincts ou le même équipement observé sous deux noms, puis conserver une traduction réversible.

Dans le domaine A, le numéro 17 désigne un routeur de bordure. Dans le domaine B, le même numéro désigne un châssis optique. Les deux contrôleurs sont cohérents : chacun a attribué une clé unique dans son propre périmètre. Le problème n’apparaît qu’au-dessus, lorsque leurs listes doivent devenir une liste unique.

Cette scène hypothétique résume la remarque formulée par Linda Dunbar dans la revue téléchat du Routing Area Directorate achevée le 1er octobre. Le verdict est Has nits. Le texte est jugé globalement clair ; une précision mineure est proposée. Puisque ne-id est attribué par le serveur et sert de clé à la liste network-element, le contrôleur supérieur qui agit comme serveur de la vue combinée devrait garantir l’unicité des valeurs qu’il publie.

Il faut garder la proportion du constat. La révision 20 de draft-ietf-ivy-network-inventory-yang est un Internet-Draft actif du groupe IVY, destiné à la voie des normes et en cours d’évaluation par l’IESG. Ce n’est pas un RFC. La revue ne décrit aucun incident réel, aucune vulnérabilité ni aucun produit défectueux. Elle désigne une responsabilité d’architecture.

Le projet définit un inventaire générique et en lecture seule des éléments de réseau et de leurs composants. Il décrit ce qu’un contrôleur sait être installé. Les stocks, les achats et les métadonnées commerciales restent hors champ. Dans ce périmètre, le contrôleur qui fournit les données est la source de vérité. Cela signifie qu’il répond de sa représentation ; cela ne signifie pas que sa base devient l’équipement physique.

Le choix d’un ne-id côté serveur répond déjà à un risque de collision. Un identifiant local au dispositif n’est pas forcément unique à l’échelle du réseau. Le projet ajoute qu’un même élément devrait conserver le même identifiant lorsqu’il est déconnecté. En revanche, la méthode permettant de reconnaître ce « même » élément—fabricant, produit, adresse de gestion, emplacement physique ou autre indice—reste propre à l’implémentation.

À la frontière hiérarchique, ces règles produisent deux tâches distinctes. La première est syntaxique : deux entrées d’une même liste YANG ne peuvent partager la clé. La seconde est épistémique : le serveur doit établir si deux observations correspondent ou non au même objet. Préfixer les clés par le nom du domaine résout la première tâche. Cela ne prouve rien sur la seconde.

Une fusion trop pressée peut compter deux fois le même châssis, dupliquer une capacité ou ouvrir deux interventions. Une séparation trop pressée peut aussi être dangereuse. À l’inverse, réunir deux fiches parce que leur fabricant, leur produit et leur adresse se ressemblent peut effacer deux équipements réellement distincts. Le conflit n’est pas une saleté à cacher ; c’est une information de gouvernance.

Le champ UUID commun apporte un repère utile. La révision 20 le présente comme un identifiant globalement unique attribué par le serveur, tandis que la norme UUID en définit la représentation et les propriétés de génération. Mais unicité et identité ne sont pas synonymes. Deux serveurs peuvent créer deux UUID valides pour le même appareil. Une copie fautive peut attribuer le même UUID à deux réalités. Le UUID stabilise une référence après la décision d’identité ; il n’est pas la preuve suffisante de cette décision.

Une chaîne responsable distingue donc cinq éléments : l’actif physique ; l’observation du contrôleur inférieur ; la clé locale ; la décision de rapprochement du contrôleur supérieur ; la clé combinée consommée par les alarmes, la topologie, les ordres de travail ou les rapports. Une liste valide au quatrième niveau ne certifie pas les quatre autres.

Le contrôle proposé ici par BTW est un reçu de traduction d’identité. Pour chaque fiche importée, il conserverait l’identité du contrôleur source, son ne-id, le ne-id combiné, le UUID et les ancrages matériels disponibles. Il indiquerait la règle de rapprochement, le degré de confiance, l’état du conflit, les premières et dernières observations, les remplacements successifs et les décisions automatisées qui ont utilisé la correspondance.

Ce reçu n’est exigé ni par le projet ni par la revue. C’est une proposition éditoriale visant à rendre les changements de nom et les fusions auditables. Si B-17 devient 18 dans la vue supérieure, l’opérateur doit pouvoir refaire le trajet inverse. Si A-17 et B-42 sont plus tard reconnus comme un seul châssis, la fusion doit garder l’histoire des deux affirmations précédentes. Si la preuve reste faible, le système devrait afficher l’incertitude plutôt que fabriquer une certitude propre.

La grille de lecture vient des notes de Heng Lu. La Note 20 sépare réalité exécutable et représentation symbolique : une fiche peut commander un processus sans devenir l’objet décrit. La Note 64 limite la couche commune aux invariants vérifiables nécessaires à l’unicité et à l’interopérabilité, laissant les choix futurs aux opérateurs. La Note 19 distingue coordination utile et autorité. Appliquée ici, cette doctrine réclame une clé commune valide, mais laisse au contrôleur qui exécute la fusion la responsabilité de sa méthode et de ses preuves. Ce sont des lectures éditoriales, pas des positions attribuées à l’IETF.

Le sujet ne répète pas les articles voisins. La cartographie topologique traite des substitutions manuelles de ne-ref et port-ref. L’inventaire des droits traite de l’écart entre licence, activation et service. L’inventaire passif traite de la preuve pour des objets qui ne parlent pas. Ici, la question arrive plus tôt : avant d’utiliser une référence combinée, quel objet désigne-t-elle et comment revenir à sa source ?

Le projet permet explicitement à un contrôleur hiérarchique de collecter les inventaires de contrôleurs inférieurs puis de fournir la vue combinée à un contrôleur encore supérieur, à un OSS d’inventaire ou à une autre application. Chaque étage supplémentaire transforme plus facilement une convention locale en apparence de fait global. Une clarification utile doit donc nommer la frontière du serveur où l’unicité s’applique, sans prétendre imposer un algorithme universel de rapprochement.

Sources