Résumé

  • draft-ietf-netmod-yang-anydata-validation-00 proposait de relier l’identité encodée d’un nœud à un schéma de la YANG Library RFC 8525 pour examiner les descendants d’un nœud anydata.
  • anydata-complete devait appliquer toutes les contraintes du schéma correspondant ; anydata-candidate n’appliquait volontairement pas les contrôles de contraintes. Aucun des deux résultats ne prouve l’origine, l’autorisation ou la réalité opérationnelle.

Une donnée arrive, passe au vert et rejoint un agrégat. Quelques mois plus tard, le même message échoue lors d’une relecture. Entre-temps, une feature a été activée, une deviation a changé et le validateur a été mis à jour. Sans l’état exact de la YANG Library au premier passage, personne ne peut dire si la donnée a changé, si le schéma a changé ou si les deux tests ne posaient simplement pas la même question.

C’est le point d’entrée utile de la révision 00 de Validating anydata in YANG Library context. En YANG 1.1, anydata accueille un ensemble de nœuds modélisables en YANG dont le modèle précis n’était pas connu lors de la conception du module parent. Ce mécanisme sert à des filtres, des résultats de datastore, des opérations d’édition, des fichiers d’instance et des notifications. Sa souplesse reporte toutefois une décision sur le consommateur : quel schéma doit juger le contenu reçu ?

Le projet proposait d’exploiter l’identité conservée par l’encodage. En XML, le nom local et le namespace du module identifient le nœud. En JSON, l’identifiant peut être qualifié par le module. En CBOR, un SID, un delta de SID, un nom qualifié ou un instance-identifier peut fournir une identité sans état. Le validateur utiliserait ensuite cette identité pour chercher le nœud correspondant dans la YANG Library.

Cette recherche n’est pas une simple consultation de catalogue. La RFC 8525 associe chaque datastore à un schéma, construit un schéma comme l’union de module-sets et qualifie les modules par leurs revisions, submodules, features et deviations. Le content-id change lorsque la Library change, mais reste un identifiant propre à l’implémentation, non un condensat universel. Sous un schema mount, le chemin et le contexte monté deviennent eux aussi déterminants.

Deux modes, deux propositions différentes

La révision 00 définissait deux options facultatives. anydata-complete devait vérifier le subtree et lui imposer toutes les règles du schéma correspondant. anydata-candidate omettait les constraint checks. Le vocabulaire se rattache à la RFC 7950 : pour running et startup, les contraintes sont appliquées à la fin d’une opération ; pour candidate, elles peuvent attendre commit ou validate.

Un succès complete signifie donc seulement que, dans le contexte nommé, l’implémentation n’a trouvé aucune violation parmi les règles exécutées. Un succès candidate signifie que le chemin candidat a accepté la structure sans achever ces contrôles. Les regrouper sous une même étiquette « YANG valide » retire au résultat sa précision la plus importante.

Un échec reste également circonscrit. Il peut signaler une plage invalide, un must ou un when non satisfait, un mauvais type, une cardinalité impossible, un nœud inconnu ou un contexte incohérent. Il ne désigne pas l’auteur du problème. Le défaut peut se trouver à la source, dans une transformation intermédiaire, dans le choix de Library ou dans le validateur. L’échec justifie la mise en quarantaine et l’enquête, pas une attribution automatique.

Le projet illustrait le risque avec un compteur d’octets négatif envoyé par un nœud défectueux dans une notification YANG-Push. L’agrégation pouvait alors fausser facturation et planification de capacité. Une validation complète peut détecter cette catégorie d’erreur. Elle ne prouve pas qu’un compteur positif est récent, exhaustif, authentique ou rattaché à l’interface attendue.

Faire du reçu un objet exploitable

Le reçu doit inclure le hash du payload, l’heure de capture, l’encodage et l’identité décodée du nœud. Il doit joindre le content-id à un instantané figé de la YANG Library, puis conserver datastore, schéma, module-sets, revisions, submodules, features, deviations et contexte de mount. Enfin, il nomme le build du validateur, ses options, le mode choisi, les diagnostics et la décision prise.

Ces champs permettent une relecture réelle. Une feature peut faire apparaître ou disparaître un nœud ; une deviation modifie une contrainte ; un mount change le point de résolution ; un nouveau parser peut interpréter autrement un encodage limite. Si le même payload change de verdict, le reçu permet d’examiner d’abord la dérive de contexte.

Le projet laissait la politique au consommateur : ignorer un message non conforme, le journaliser ou déclencher une alerte. Cette séparation est saine. Le validateur fournit un constat borné ; le propriétaire des données doit décider à l’avance quels constats bloquent l’automatisation, autorisent une nouvelle tentative ou exigent une revue humaine.

Le statut actuel interdit toute promesse de standardisation

Datatracker donne le 2 décembre 2025 comme date de la dernière revision et enregistre la mise à disposition de la version WG 00 ce jour-là. Le texte a expiré le 3 juin 2026. La page affiche désormais Expired Internet-Draft, Expired & archived, Dead WG Document et IESG Expired. Le champ structuré Intended RFC status vaut None.

Le masthead historique disait séparément Intended status: Standards Track. Ce libellé de projet ne constitue pas une approbation de l’IETF. L’analyse de sécurité restait inachevée, aucune action IANA n’était demandée et Datatracker ne nomme pas de shepherd.

La section Implementation Status citait une branche libyang pour anydata-candidate, avec instruction de supprimer la section avant une publication RFC. Une branche atteste tout au plus l’existence d’un chemin expérimental. Elle ne prouve ni fusion, ni implémentation indépendante, ni interopérabilité, ni déploiement.

Une conformité de schéma ne remplace pas les preuves voisines

La RFC 8342 sépare running, intended et operational : une valeur conforme n’établit pas qu’elle est appliquée par l’équipement. La RFC 8341 traite le contrôle d’accès : une structure valide n’est pas une autorisation NACM. Les RFC de subscription et YANG-Push encadrent sélection et livraison : un subtree conforme ne démontre ni absence de perte, ni ordre, ni non-réécriture.

Identité de l’émetteur, intégrité du transport et chaîne de garde ont leurs propres reçus. Il en va de même pour les compteurs d’équipement, la FIB, les captures de paquets, l’observation distante et le rapprochement financier. Le caractère automatisable d’un verdict ne lui donne aucune autorité sur ces autres couches.

L’apport durable de la révision 00 est ainsi plus modeste et plus utile qu’un label universel : rendre un subtree opaque testable dans un contexte nommé, et conserver la différence entre une vérification complète et une vérification candidate. Avec son contexte, le résultat réduit l’incertitude. Sans lui, le feu vert devient une promesse impossible à auditer.

Sources

Document : révision 00, statut Datatracker et historique.

Cadre technique : RFC 7950, RFC 8525, RFC 8342, RFC 8341, RFC 8528, RFC 8639 et RFC 8641.

Grille d’analyse : Minimum Initial Specification, On Reality Layers et Running Code Primary.