Résumé

  • OPSAWG a adopté VELOCE et publié la révision 00 comme document de groupe le 25 août 2026. Ce statut n’est ni un RFC, ni un BCP, ni une règle définitive de l’IETF.
  • Un résumé attribué de la réunion du même jour affirme que le modèle de pointeur IANA a été confirmé. La révision 00 indique pourtant explicitement qu’elle n’a aucune action IANA; la pull request 49, qui propose des états, des empreintes et des chemins d’approbation, était encore ouverte et non fusionnée.
  • Une conclusion de réunion de projet ne vaut pas confirmation du consensus du groupe sur la liste de diffusion. Une fusion dans GitHub ne vaut pas approbation du groupe, d’un Area Director ou de l’IESG. Une ligne IANA peut consigner un artefact approuvé sans décider de sa signification normative.
  • Le projet évite déjà de désigner une branche mobile : la référence d’un RFC doit viser une version étiquetée. Il reste à définir comment une nouvelle version autorisée devient le pointeur pertinent et contre quelle version un implémenteur peut déclarer sa conformité.

Quatre événements, quatre portées

La décision d’adoption clôt l’appel de juin en constatant un soutien suffisant et en demandant la republication du texte individuel sous le nom du groupe, sans autre modification. Le Datatracker affiche bien la révision 00 comme document OPSAWG depuis le 25 août. Cette adoption confie le texte au groupe; elle n’autorise pas par avance toutes les modalités techniques qu’une révision suivante pourra proposer.

Le projet choisit une séparation matérielle importante. Un module YANG ne serait pas reproduit dans le RFC; le RFC viserait une version précise et étiquetée du dépôt. Une branche principale peut changer après publication. Un commit ou une étiquette nommée permet au contraire de retrouver les octets auxquels le RFC se rapportait. La révision envisage aussi qu’un module adopté soit mis à jour dans un dépôt IETF et que seule la référence du RFC soit modifiée. Cette voie peut réduire le coût de corrections limitées, à condition que la rapidité ne rende pas illisible l’autorité qui a validé la correction.

Les auteurs ont exposé la difficulté avant IETF 126. Une discussion publique demande si la cible doit être une étiquette Git, une entrée IANA ou autre chose; elle demande aussi ce que signifierait « la dernière version », quelle version les implémenteurs doivent suivre et comment conserver une conformité vérifiable. Les minutes d’OPSAWG montrent des positions concurrentes sur GitHub, un environnement contrôlé par l’IETF, l’IANA, l’archivage et la récupération. Le temps prévu a manqué. Voilà une question encore ouverte, non un grief contre les personnes qui y travaillent.

Le résumé du 25 août apporte un élément supplémentaire : le dépôt GitHub serait conservé pour l’expérience, les contributions passeraient par issues ou pull requests, les avis recueillis lors de réunions bimensuelles seraient résumés sur la liste, et une objection devrait conduire à une discussion avant fusion. Il ajoute que l’indirection IANA a été confirmée. Il faut pourtant garder la nature de la source visible. C’est le récit attribué d’une réunion de projet. Or RFC 8874 précise que le travail effectué dans GitHub n’a pas de statut spécial et que les décisions de consensus du groupe doivent être confirmées sur la liste de diffusion. Une réunion peut préparer une décision; elle ne se substitue pas à cette confirmation.

Enfin, la révision 00 dit que le document n’a aucune action IANA. Selon RFC 8126, une section explicite sans action signifie qu’une détermination consciente a été faite pour ce texte. Elle n’interdit pas une instruction IANA dans une révision future. Elle empêche seulement de présenter l’indirection évoquée lors de la réunion comme si elle était déjà une demande IANA exécutable.

PR 49 est une proposition, pas une ligne de registre

La pull request 49, ouverte et non fusionnée à la date d’arrêt, remplace cette absence d’action par l’idée d’un registre de références de fichiers et modules YANG. Elle propose des états permanent et proposé, une URL exacte, une valeur SHA-256, des contacts responsables et des voies d’approbation par l’IESG ou autrement définies. C’est une bonne esquisse de séparation : l’empreinte identifie les octets, l’état évite de confondre candidat et référence courante, le contact établit une responsabilité et le champ d’approbation désigne une source de décision.

Mais l’esquisse n’est pas encore une politique publique. Le registre actuel IANA des noms de modules YANG, sous politique RFC Required, montre le nom, le fichier, l’espace de noms, le préfixe, la référence et des notes. Il ne contient pas aujourd’hui les champs VELOCE proposés pour l’empreinte, l’état de décision, le responsable ou le reçu de décision. Il n’est donc pas justifié d’affirmer que l’IANA a créé ce nouveau registre, accepté sa politique ou récupéré une version VELOCE.

Les actes restent différents. Un auteur soumet une modification. Des réviseurs et un mainteneur peuvent la traiter dans un dépôt. Le groupe peut former un consensus. Un Area Director ou l’IESG peut exercer le rôle d’approbation que le texte prévoit. L’IANA exécute une inscription définie. Une ligne de registre préserve alors l’identité d’une version. Aucune de ces étapes ne prouve automatiquement les autres. Les fusionner donnerait au mainteneur le pouvoir du groupe, à l’IANA un pouvoir de fond, ou à une étiquette la preuve d’un déploiement qu’elle ne peut fournir.

La lecture prudente reconnaît aussi ce qui est déjà bien conçu. La révision 00 refuse une branche flottante. Elle conserve les procédures de consensus. La PR 49 cherche à encadrer l’IANA par des empreintes et des approbations nommées, non à lui transférer une liberté sans limite. Le document en est à sa première révision de groupe : il est normal qu’un mécanisme disputé ne soit pas encore figé.

Un reçu décision-vers-pointeur

VELOCE n’a pas besoin d’un second appareil de normalisation. Il a besoin, pour chaque changement ultérieur, d’un reçu public et relié qui indique :

  1. l’effet normatif revendiqué et le groupe qui le contrôle;
  2. l’appel de consensus sur la liste, ses dates, objections et conclusion;
  3. le texte précis demandant l’inscription et l’acteur qui approuve;
  4. l’URL du dépôt, le commit, l’étiquette et l’empreinte SHA-256;
  5. les rôles distincts de l’auteur, des réviseurs, du fusionneur et de l’approbateur;
  6. la demande IANA, les octets récupérés, le résultat de vérification et la transition entre anciennes et nouvelles lignes;
  7. la version publiée, la dernière version approuvée et la version contre laquelle la conformité est testée;
  8. la compatibilité, les essais, la réplication, les sauvegardes et une procédure de retrait ou de retour arrière; et
  9. séparément, des indices de mise en œuvre ou d’adoption opérationnelle.

Ce reçu ne créerait aucun veto. Il empêcherait seulement qu’un mot tel que « latest » masque une succession d’actes institutionnels. L’IANA vérifierait et consignerait l’artefact désigné par l’autorité compétente; elle ne déciderait pas qu’un candidat est suffisamment consensuel. La note 63 de Heng Lu offre ici un cadre de lecture, non une source sur VELOCE : un dépositaire peut rendre une décision vérifiable sans s’emparer du droit de la prendre.

Cette séparation est aussi nécessaire pour la conformité. RFC 9907 reste le BCP publié : les énoncés YANG normatifs y sont traités comme la prose normative d’un RFC et les modules nouveaux ou mis à jour sont enregistrés dans les registres IETF XML et YANG Module Names. VELOCE peut proposer un arrangement différent, mais ne l’a pas encore remplacé. « Version du RFC », « dernière version approuvée », « ligne IANA » et « version testée » peuvent coïncider; elles ne doivent jamais être confondues sans le dire.

Sources

  1. Charte OPSAWG
  2. Fiche Datatracker VELOCE
  3. Minutes OPSAWG d’IETF 126
  4. Pull request 49
  5. Note 63 de Heng Lu
  6. Paramètres YANG de l’IANA
  7. Résultat de l’adoption VELOCE
  8. Discussion sur le pointeur VELOCE
  9. Résumé de la réunion VELOCE du 25 août
  10. draft-ietf-opsawg-veloce-yang-00
  11. RFC 8126
  12. RFC 8874
  13. RFC 8875
  14. RFC 9907