Résumé

  • La révision 10 du projet OPSAWG sur les tests OAM planifiés précise qu’une modification ultérieure du modèle d’un test unitaire ne devrait pas changer silencieusement une séquence déjà configurée. Elle remplace notamment une liste de références par une liste contenant les tests unitaires et renomme plusieurs éléments YANG.
  • Le document affirme également que l’opérateur doit maîtriser l’ordre des tests, car cet ordre influence les résultats. Pourtant la nouvelle liste ne contient plus la déclaration ordered-by user présente dans la version 09. Selon la RFC 7950, une liste sans cette déclaration est ordonnée par le système. Il s’agit d’une incohérence dans un projet, non d’une panne observée.

Un contrôleur peut lancer plusieurs mesures à intervalles réguliers sans que leur succession soit un détail. Vérifier d’abord une liaison, puis mesurer un délai et enfin effectuer une recherche de chemin ne produit pas le même dossier qu’un assemblage de résultats dont l’ordre n’est pas garanti. Le projet draft-ietf-opsawg-scheduling-oam-tests propose des modèles YANG pour les systèmes de gestion et d’orchestration qui organisent ces diagnostics. Sa révision 10 est encore un Internet-Draft de groupe de travail, destiné à une éventuelle norme proposée : elle n’est pas une RFC approuvée.

La nouveauté la plus claire concerne la stabilité d’une configuration. Le texte ajouté à la section 4.2 demande qu’un changement du modèle de test unitaire ne modifie pas discrètement une séquence préexistante. Dans le schéma, la séquence rassemble désormais des entrées de test unitaire là où la version 09 plaçait des références. Cette distinction compte pour comparer deux exécutions : le dossier devrait permettre de savoir si la procédure a changé entre elles. Le document ne prouve toutefois ni qu’un logiciel applique déjà cette règle ni que chaque état historique est conservé.

Une autre pièce de cette traçabilité est moins aboutie. La prose insiste sur le contrôle de l’ordre par l’utilisateur et explique qu’une permutation peut changer le compte rendu. Elle dit même qu’il faut spécifier ordered-by user. Or cette instruction figurait sur la liste de la version 09 et manque sur la nouvelle liste unitary-test. La description de celle-ci évoque à la fois un ordre utilisateur et un ordre système, sans trancher par une instruction YANG. La règle de base de la RFC 7950 tranche pour le langage : à défaut de déclaration, l’ordre relève du système. Le commentaire éditorial d’un projet ne confère pas au client une capacité que le modèle ne décrit pas.

La question pour les auteurs est donc précise. Souhaitent-ils garantir une séquence choisie par l’opérateur, auquel cas le schéma et l’exemple de lecture doivent la conserver ? Ou s’agit-il d’un ensemble de tests dont l’ordre n’est pas contractuel, auquel cas les promesses de la section 4.2 demandent une autre formulation ? La nouvelle identité d’erreur liée à un conflit de priorité et l’élargissement de l’identifiant de nœud sont des changements distincts ; ils ne répondent pas à cette question.

La RFC 9922 fournit au projet les éléments communs de calendrier. Une analyse antérieure de BTW demandait si un calendrier toujours valide autorise encore l’action programmée. Ici, le problème n’est pas l’autorisation d’exécuter, mais l’identité de la procédure exécutée pendant une occurrence donnée. Confondre temps, permission et ordre fabriquerait une preuve plus forte que les textes ne la justifient.

Sources