Résumé

  • draft-ietf-opsawg-veloce-yang-00 veut que le document publié pointe vers un module YANG identifié par un tag ou un commit, jamais vers la tête mouvante d’une branche. C’est une preuve forte d’identité du contenu, pas une preuve automatique de consensus.
  • Après la publication, il faut encore préserver la décision et la chaîne de garde, vérifier le module-set réellement annoncé par le serveur, exercer des opérations représentatives et observer l’effet sur le service.

Le conflit le plus dangereux n’oppose pas forcément deux versions différentes d’un module. Il peut opposer deux interprétations parfaitement sincères du même événement.

Pour l’éditeur, la fusion d’une pull request signifie que la modification est entrée dans le dépôt. Pour l’intégrateur, le tag signifie qu’un objet est prêt à être consommé. Pour un participant pressé, les contrôles verts et le bouton « merged » peuvent sembler signifier que le groupe a décidé. Pour l’opérateur, aucun de ces signaux ne dit encore ce que le routeur a chargé.

VELOCE place cette ambiguïté au cœur d’une expérience utile. Le projet draft-ietf-opsawg-veloce-yang-00 propose de séparer deux artefacts que les RFC contenant des modèles YANG ont longtemps réunis : la prose normative et opérationnelle d’un côté, le module source de l’autre. Le premier resterait dans le document. Le second serait développé et maintenu dans un dépôt de gestion de code source.

L’objectif est raisonnable. Un module YANG se relit mieux sous forme de diff, se soumet à des parseurs et à des validateurs, importe d’autres modules et peut nécessiter des fichiers SID. Republier un long texte pour corriger une petite portion de code ajoute de la friction sans garantir une meilleure révision.

Le texte gelé est un Internet-Draft actif du groupe OPSAWG, daté du 25 août 2026. Son en-tête indique un statut visé Experimental, tandis que le résumé Datatracker ne renseigne aucun statut RFC visé. Seule la révision 00 figure dans l’historique. Il ne s’agit ni d’un RFC, ni d’une expérience terminée, ni d’une preuve de déploiement. Les délais proposés—deux ans pour un nouveau module, un an pour un -bis incrémental—sont des critères à éprouver.

La proposition la plus structurante exige que le module ne soit pas inséré dans le document. Le lien doit désigner une version taguée ou un commit précis, et non HEAD. Ainsi, l’objet correspondant au moment de la publication reste récupérable et vérifiable.

Cette règle réduit une vraie incertitude. Une branche bouge; un commit identifie un état. Le YANG Doctor, l’auteur d’une implémentation et l’auditeur peuvent comparer le même contenu. Mais la force de ce reçu est précisément sa limite : il identifie des octets.

Il ne dit pas qui leur a donné autorité.

Le RFC 8874 rappelle que le travail effectué sur GitHub n’a aucun statut particulier. Le groupe de travail peut l’accepter, le rejeter ou le modifier. La copie présente dans le dépôt n’a pas à refléter parfaitement le consensus à chaque instant, car les éditeurs ont besoin d’une marge de gestion.

Cette distinction résiste mal à l’ergonomie des plateformes. Une issue est ouverte ou fermée. Une pull request est fusionnée ou non. Une étiquette peut afficher has-consensus. Ces états sont nets et interrogeables. Le consensus approximatif, lui, demande au président d’apprécier les arguments dans plusieurs espaces, y compris les absents de la conversation la plus active.

Le RFC 8874 demande donc que les décisions de consensus soient confirmées sur la liste de diffusion. Le RFC 2418 précise que le consensus approximatif n’est pas un vote à 51 % et que le président détermine s’il existe. Une décision prise en réunion doit également être soumise à la liste.

Une fusion peut ainsi être conforme au processus sans constituer le reçu final d’une décision. Les éditeurs peuvent traiter de nombreuses modifications; le président peut demander d’attendre l’évaluation du consensus pour une modification sensible. Une question de design susceptible d’affecter l’implémentation ou l’interopérabilité exige un lien plus explicite.

Ce lien devrait réunir quatre éléments : la question technique, la résolution retenue, la détermination bornée du président et le commit qui matérialise cette résolution. Sans cette jointure, le dépôt prouve qu’un changement a eu lieu et les archives prouvent qu’une discussion s’est conclue, mais rien ne prouve qu’il s’agit exactement du même choix.

La CI ne remplit pas ce vide institutionnel. Elle fournit un autre reçu, tout aussi utile et tout aussi borné. Le RFC 8874 décrit la compilation des documents, la validation des langages formels et l’exécution de tests. VELOCE recommande une validation YANG et un environnement conteneurisé reproductible.

Un contrôle vert signifie que des tests nommés ont réussi sur des entrées nommées. Sa portée dépend du commit, de la version du validateur, des imports, des features, des exceptions, de l’image de construction et du corpus de tests. Il ne couvre pas les tests qui n’existent pas. Il ne démontre pas que deux implémentations interpréteront toutes les contraintes de la même façon.

La bonne réponse n’est pas de se méfier de l’automatisation. Elle consiste à conserver son dénominateur. Un manifeste de validation doit permettre de reproduire le verdict et de voir ce qu’il ne mesure pas.

La publication constitue ensuite un reçu différent. Un RFC pourrait relier sa prose au tag exact examiné. Cela renforce considérablement l’identité normative. Mais cette publication ne fabrique pas le paquet d’un fournisseur et ne modifie aucun appareil.

Entre les deux se trouvent la garde du dépôt, la production d’une version, la signature des artefacts, la résolution des dépendances, l’intégration fournisseur, l’image logicielle, le déploiement et l’activation locale. Un standard impeccable peut cohabiter pendant des années avec une ancienne révision installée.

La conservation du contexte est elle aussi distincte de la conservation du code. Le RFC 8874 note que la réplication Git protège relativement bien les objets du dépôt, mais que les discussions d’issues, de pull requests, de revues et les wikis sont plus vulnérables. Il évoque aussi la panne du service externe et la compromission des comptes privilégiés. Le RFC 8875 complète cette discipline administrative et de sauvegarde.

Si l’on conserve le commit mais que l’on perd la raison pour laquelle il a été accepté, on préserve le résultat sans préserver l’autorité.

Le premier reçu d’exécution crédible provient du serveur. Le RFC 8525 permet à YANG Library d’annoncer les module-sets associés aux datastores, avec révisions, features et deviations. Cette lecture répond à une question que le tag ne peut pas trancher : quel environnement de schéma le serveur affirme-t-il réellement mettre en œuvre ?

Ce n’est toujours pas la preuve du résultat. YANG Library reste une déclaration du serveur. Des opérations NETCONF ou RESTCONF représentatives, une relecture de l’état et une observation indépendante du service sont nécessaires pour passer du schéma à la réalité du réseau.

La grille de lecture de Heng Lu aide à ne pas écraser ces niveaux. La primauté du code en fonctionnement ne nie pas l’utilité d’une norme; elle interdit de faire passer une preuve symbolique pour un fait d’exécution. Le tag appartient au dépôt. Le consensus appartient au processus de décision. Le RFC appartient au système de publication. Le comportement appartient à l’implémentation en service.

Le principe de spécification initiale minimale indique comment préserver la vitesse recherchée par VELOCE. Le socle commun doit imposer les jonctions nécessaires : identité exacte, validation reproductible, décision retrouvable, référence de publication immuable. Les outils de dépôt et de livraison peuvent rester locaux. L’adoption volontaire et l’interopérabilité des implémentations feront ensuite le reste.

Enfin, une interface très active ne constitue pas un mandat. Les personnes qui suivent chaque issue forment un groupe auto-sélectionné; d’autres experts restent sur la liste. Le RFC 8874 reconnaît ce biais. Relier explicitement le dépôt à la liste et au président est donc une protection du processus, pas une nostalgie du courrier électronique.

VELOCE réussira s’il accélère la maintenance sans confier par inadvertance l’autorité à la surface la plus facile à mesurer. Le tag doit figer le module. Le consensus, la garde et le déploiement doivent garder leurs propres reçus.

Sources