Résumé

  • draft-ietf-netmod-node-tags-11 proposait de réunir des tags définis avec le module, ajoutés par une implémentation ou configurés par l’utilisateur, avant de retirer les valeurs exactement présentes dans masked-tag.
  • Le tag qui subsiste atteste seulement ce qu’un serveur a exposé pour un sélecteur, un datastore et des droits donnés. Il ne prouve pas l’existence actuelle du nœud, la fraîcheur de sa valeur, la conformité de l’implémentation ni l’adoption du projet.

Une équipe d’exploitation veut isoler tous les nœuds classés comme critiques. Sa requête en retourne six. Elle en attendait sept. Cette absence peut signifier que le septième n’a jamais reçu de tag, qu’un masque l’a retiré, qu’un contrôle NACM le cache, que le sélecteur ne se résout plus dans la révision courante du schéma ou que le mauvais datastore a été interrogé. L’interface ne donne pas, à elle seule, le verdict.

C’est la tension centrale de YANG Data Model for Node Tags. Le module proposé, ietf-node-tags, associe un identifiant entier à un node-selector de type nacm:node-instance-identifier, à une liste de tag et à une liste de masked-tag. Le sélecteur peut viser un nœud de schéma ou une instance de données. Le texte évoque <get-data> sur le datastore opérationnel pour la découverte, et <get-schema> dans le cas des nœuds de schéma. Son annexe transforme ensuite un chemin découvert en argument d’establish-subscription.

Cette séquence décrit une possibilité d’usage. Elle n’établit ni livraison commerciale, ni seconde implémentation, ni test d’interopérabilité. Aucun élément de ce dossier ne documente un déploiement réel.

La provenance est moins nette que la taxonomie

Les sections consacrées aux origines distinguent trois contributeurs. L’auteur du module peut inscrire une classification au moment de la conception. Une implémentation peut compléter cette classification selon ses propriétés. L’utilisateur peut ajouter ses propres tags et masquer n’importe quelle valeur, quelle qu’en soit l’origine.

La procédure numérotée qui construit la vue opérationnelle est moins symétrique. Elle ajoute les tags d’origine système attribués lors de la définition du module, ajoute les tags configurés par l’utilisateur dans l’état intended, puis supprime toute valeur égale à un masked-tag. Elle ne réserve pas une étape distincte aux tags ajoutés par l’implémentation.

On peut raisonnablement considérer ces ajouts automatiques comme du matériau produit côté serveur et présenté avec l’origine système. Il faut toutefois signaler qu’il s’agit d’une lecture conciliatrice, non d’une quatrième étape écrite noir sur blanc. Une architecture de preuve ne devrait pas inventer une précision que le projet n’a pas fournie.

Le masque ne corrige pas l’histoire. Il retranche une chaîne exacte de la vue finale. Il n’indique ni que le tag n’a jamais existé, ni qu’il était faux. Inversement, la présence de vendor:critical ne révèle pas qui l’a introduit, à quelle date, dans quelle version logicielle, ou après quelle observation.

Les préfixes ietf:, vendor: et user: organisent les noms. Le projet précise même qu’un préfixe non enregistré reste valide et devrait être traité. L’enregistrement atteste donc une allocation de namespace, pas la véracité du jugement après les deux-points.

Le chemin n’emporte pas son contexte

Un sélecteur typé donne une impression de stabilité. Pour le résoudre, il faut pourtant le modèle effectif. RFC 7950 définit YANG ; RFC 8525 décrit l’inventaire YANG Library, avec modules, révisions, features et deviations. Le même chemin peut disparaître ou changer de sens quand cet ensemble ou un contexte de montage change.

RFC 8342 sépare intended et operational. Le projet s’en sert pour distinguer les choix de l’utilisateur de la vue composée. Mais « operational » signifie ici une vue construite et exposée par le serveur. Ce n’est pas une observation sans médiation du matériel ou du transfert de paquets.

RFC 8341 ajoute l’autorisation. NACM peut cacher l’association comme le nœud cible. RFC 6241 et RFC 8040 encadrent les échanges NETCONF et RESTCONF ; une réponse réussie reste la réponse rendue à cette identité dans cette transaction. Une absence n’est donc jamais, sans contrôle supplémentaire, une preuve d’inexistence.

RFC 7952 offre un contraste utile : ses annotations suivent les instances de données, tandis que node-tags centralise des associations autour de sélecteurs. Ni l’une ni l’autre approche ne fournit automatiquement l’auteur, l’horodatage, la chaîne de conservation ou la fraîcheur.

Une échelle de preuve avant toute automatisation

L’existence du projet prouve qu’un mécanisme a été proposé. Datatracker prouve son cycle documentaire. L’enregistrement d’un préfixe prouve une coordination du namespace. Un résultat de requête prouve qu’un serveur a montré un tag après composition dans un contexte d’accès précis.

La résolution du sélecteur contre un instantané YANG Library fige ensuite le nœud visé dans ce schéma. Une lecture autorisée établit ce que le serveur a rendu pour cette opération. Il faut encore d’autres observations pour la fraîcheur, l’exhaustivité, la conformité du logiciel, l’état du FIB, le passage des paquets et le résultat de service.

RFC 8639 et RFC 8641 permettent de passer d’un chemin à une souscription et à YANG-Push. RFC 9195 et RFC 9196 structurent des données d’instance et des capacités. Ces mécanismes ne prouvent pas qu’aucune notification n’a été perdue ni que le dispositif exécute fidèlement le sens du tag. Le traitement des identifiants de fournisseur dans RFC 9371 relève également de l’hygiène du nom, non de l’homologation d’un comportement.

Le projet signale lui-même le risque : les tags peuvent dévoiler l’usage d’un nœud et suggérer un vecteur d’attaque ; leur ajout et leur retrait doivent être protégés ; les actions déclenchées par eux restent hors périmètre. Une politique qui transforme un tag en ordre de blocage, d’accès ou de configuration est une décision locale, pas une autorité conférée par le texte.

Un projet expiré ne devient pas standard par voisinage

La révision 11 est datée du 21 octobre 2023 et annonçait son expiration au 23 avril 2024. Datatracker la classe aujourd’hui comme Expired Internet-Draft, Expired & archived, Dead WG Document, avec l’état IESG Expired. Son statut visé était Proposed Standard ; elle n’est pas devenue RFC.

Le contrôle YANG de Datatracker affiche zéro erreur et zéro avertissement. Cela prouve que les modules soumis ont passé ces vérifications. Cela ne prouve ni adoption, ni interopérabilité, ni déploiement, ni composition correcte en exploitation.

RFC 8819 est le précédent standardisé le plus proche. Il organise des tags au niveau des modules YANG, avec des apports de définition, d’implémentation et d’utilisateur, ainsi que des masques. Node-tags cherchait à porter cette idée au niveau des nœuds. Le statut Standards Track de RFC 8819 ne se transmet pas au projet expiré.

Les textes de Heng Lu sur la spécification minimale, l’autorité, le pouvoir d’implémentation, les couches de réalité et le running code servent ici de cadre éditorial seulement. Ils invitent à distinguer l’outil symbolique qui coordonne de la pratique observable qui produit un résultat. Ils n’ajoutent aucune exigence IETF. Leur application prudente est simple : garder le tag comme indice de découverte, sans lui faire emprunter l’autorité du document ou du registre.

Sources

Document principal : révision 11, statut Datatracker et historique Datatracker.

Modèle et accès : RFC 6241, RFC 7950, RFC 7952, RFC 8040, RFC 8341, RFC 8342, RFC 8407, RFC 8525 et RFC 8526.

Tags, souscriptions et modèles voisins : RFC 8639, RFC 8641, RFC 8819, RFC 9195, RFC 9196 et RFC 9371.

Cadre analytique : Minimum Initial Specification, On Authority, Implementation Power, Reality Layers et Running Code Primary.