Résumé

  • draft-ietf-netmod-yang-next-agreement-00 répartit les sujets YANG Next entre ceux à intégrer, ceux à examiner si l’intérêt suffit, ceux à reporter après la prochaine version et ceux déjà clos ou proposés à la clôture.
  • Cette répartition est une preuve de classement attachée à la révision 00. Une rubrique, une issue GitHub fermée ou l’état WG Document ne démontre pas, à elle seule, un consensus élément par élément, une inclusion finale, une sémantique normative, une compatibilité, une mise en œuvre ou une adoption.

Le problème n’est pas de savoir si une liste ordonnée vaut mieux qu’un stock de demandes. Elle vaut mieux. Le problème commence lorsque la colonne devient une promesse.

Un responsable de produit voit « à intégrer » et inscrit une date de livraison. Un éditeur de modèles voit « fermé » et suppose qu’un risque a disparu. Un acheteur voit « document du groupe de travail » et entend « standard approuvé ». Or la révision 00 ne fournit aucun de ces reçus. Elle propose une architecture du débat : choisir la taille et la direction d’une future évolution de YANG avant que l’addition des contributions ne produise, par inertie, un langage trop vaste et incohérent.

Deux surfaces de statut à ne pas fusionner

Le Datatracker présente aujourd’hui le texte comme un Internet-Draft actif du groupe NETMOD, révision 00, mis à jour le 23 juin 2026. L’état du groupe est WG Document et l’état IESG est I-D Exists. Le champ structuré « Intended RFC status » est vide. Dans l’en-tête du document, en revanche, figure « Intended status: Informational », avec une expiration au 25 décembre 2026.

Il faut publier ces deux observations telles quelles. L’une décrit les champs courants du Datatracker ; l’autre appartient au texte du brouillon. Les rapprocher en une phrase telle que « l’IETF a adopté un document Informational » créerait une conclusion absente des sources.

Le brouillon fixe lui-même la limite. Son objet est de discuter et, si possible, de trouver un accord sur le périmètre et la forme de la prochaine version de YANG. Il précise qu’il n’a pas vocation à devenir lui-même un RFC et qu’un tableau de bord GitHub pourrait finalement servir au suivi. WG Document désigne donc un lieu reconnu pour le travail collectif, non l’approbation de toutes les cases.

Le contrôle de périmètre est le véritable mécanisme

Le document compte environ 125 issues ouvertes et 35 fermées dans le dépôt netmod-wg/yang-next. Leur importance, leur complexité et leur impact sur la compatibilité sont très différents. Laisser la disponibilité des contributeurs déterminer seule le prochain langage reviendrait à confondre énergie de contribution et priorité commune.

Les quatre voies remettent une décision en amont. La première contient les changements que les auteurs estiment nécessaires à une future version. La deuxième garde les idées à examiner si l’intérêt est suffisant. La troisième protège la prochaine version contre des ajouts prématurés sans interdire un retour ultérieur. La quatrième regroupe les questions à abandonner, déjà closes ou proposées à la clôture.

Cette structure possède une qualité rare : elle rend le non-choix explicite. Reporter n’est pas oublier ; c’est localiser une décision future. Refuser une complexité ne nie pas l’existence du besoin ; cela empêche que le noyau du langage devienne le réceptacle automatique de toute difficulté.

Mais même la première voie reste un avis éditorial. La section 2 parle des questions que les auteurs « croient » devoir ajouter. Elle admet que certaines clarifications, après examen, peuvent ne nécessiter aucune modification. L’annexe Issue 152 propose d’ailleurs une autre classification. Le tableau est donc le support du consensus à construire, non son résultat.

Une clôture sans motif est un reçu mutilé

La catégorie « fermé » recouvre des opérations hétérogènes : doublon, incompréhension de YANG, proposition jugée nuisible, difficulté relevant d’un protocole, faible priorité, solution de contournement, issue déjà fermée sur GitHub ou demande que l’auteur souhaite fermer. Certaines questions jadis closes reviennent ailleurs parce qu’une hypothèse YANG 2.0 modifie la contrainte de compatibilité.

La conséquence est pratique. Un système d’audit qui ne retient que open ou closed perd la décision réelle. Pour comprendre une issue, il faut conserver son identifiant exact, son état à une date donnée, la discussion, sa place dans une révision précise du draft, le motif de classement et la trace des objections ultérieures. « Fermé » indique qu'une file de travail a changé ; il ne dit pas si une idée est fausse, déplacée, redondante, trop chère ou simplement différée.

Le consensus possède son propre dossier de preuve

Les minutes de NETMOD éclairent la genèse. À l’IETF 120, le groupe manifestait de l’intérêt mais ne savait pas encore s’il cherchait YANG 1.1, 1.2 ou 2.0. La présidence demandait d’abord motivations et objectifs, en rappelant que Git ne remplaçait pas le processus de consensus. À l’IETF 121, une équipe de scoring auto-sélectionnée avait examiné les issues. Plusieurs participants demandaient que son résultat retourne au groupe. Le draft de synthèse devait permettre de rechercher une adhésion sur la direction générale, pas attester qu’elle existait déjà.

RFC 7282 décrit le rough consensus comme la recherche et le traitement des objections techniquement fondées, non comme un comptage de voix. L’état administratif d’un document ne peut donc porter seul ce dossier. Il faut savoir quelles objections ont été formulées, comment elles ont été traitées, et sur quelle proposition précise la présidence a conclu.

Sept questions, sept reçus

La chaîne complète commence par l’inventaire : identité de l’issue, auteur, exemple, état et horodatage. Vient ensuite le classement : rubrique de la révision 00, justification et alternative. Le troisième reçu est celui du consensus : liste, réunion, objections, réponses et conclusion limitée. Le quatrième est normatif : texte exact d’une version ultérieure et dépendances.

La compatibilité forme un cinquième dossier, avec grammaires, sémantiques, modules existants, extensions, deviations, clients et serveurs. Le sixième vient des implémentations indépendantes, de leurs tests positifs et négatifs, et de l’interopérabilité. Le septième appartient aux opérateurs : migration progressive, observabilité, retour arrière et résultats réels.

La révision 00 est surtout un reçu de deuxième niveau. Elle rend le périmètre contestable et auditable. La promouvoir aux niveaux suivants affaiblirait précisément cette utilité.

Les travaux voisins ne se confondent pas

Le draft YANG 2.0 décrit une base de langage. Le module versioning traite l’identité et les branches de révision. La comparaison de schémas classe des différences sous des entrées données. Les conventions de nom de fichier concernent la découverte et les alias. YANG Packages résout des ensembles de modules et leur conformité. YANG Next Agreement ne remplace aucun de ces mécanismes, et leur existence ne prouve pas son classement.

Pour un fournisseur, « à intégrer » ouvre une étude de faisabilité. Pour un mainteneur d’outils, il ouvre une branche d’essai et un corpus. Pour un opérateur, il ouvre une veille, pas une migration. Pour le groupe, il ouvre une question de consensus suffisamment petite pour recevoir une réponse précise.

Le principe de spécification initiale minimale de Heng Lu donne ici une lecture utile : réduire d’abord le champ de décision, laisser les choix futurs au bon niveau, puis laisser l’adoption volontaire suivre des résultats reproductibles. Les catégories appartiennent au niveau symbolique qui coordonne l’attention. Le niveau réel commence lorsque le texte est normatif, que plusieurs outils convergent et que l’exploitation sait observer et annuler les effets.

Sources

Document et historique : YANG Next Agreement révision 00 ; fiche Datatracker ; historique Datatracker.

Processus et contexte : minutes NETMOD IETF 120 ; minutes NETMOD IETF 121 ; RFC 7282 ; RFC 7950, YANG 1.1 ; draft YANG 2.0 révision 00.

Cadre d’interprétation : Minimum Initial Specification ; On Reality Layers ; Running Code Primary.