Résumé

  • Au 27 août 2026, DAWN restait un groupe Proposed. Sa première charte, 00-00, était en examen interne IESG/IAB et le vote demandait seulement si le texte pouvait passer à l’examen externe.
  • NETCONF était déjà Active, mais 20-02 constituait une proposition de nouvelle charte. Datatracker précisait que la charte approuvée en vigueur restait la version 20.
  • RFC 2418 attribue des rôles différents aux futurs présidents, à l’Area Director, à l’IAB, à la communauté, à l’IESG et au Secrétariat. Un numéro de version ne remplace pas cette chaîne de décision.
  • L’approbation d’une charte ouvre un espace de travail limité ; elle n’adopte pas un Internet-Draft, ne constate pas le consensus sur son contenu, n’approuve pas un RFC et n’ordonne aucun déploiement.

La révision la plus récente ne répond pas à la bonne question

Pour un document ordinaire, afficher d’abord la dernière version est une bonne règle. Pour un mandat, deux questions doivent rester séparées : quel texte est actuellement discuté, et quel texte donne actuellement compétence au groupe ?

Dans une création, la première question peut avoir une réponse détaillée alors que la seconde doit rester vide. Une proposition de charte peut avoir des présidents pressentis, un calendrier, des livrables et plusieurs révisions sans qu’un groupe ait été constitué. Dans une nouvelle charte, le vide serait au contraire faux : le groupe continue d’exister sous le texte antérieurement approuvé tant qu’une décision n’a pas opéré le remplacement.

Un registre à pointeur unique transforme donc dernier en en vigueur. Pour DAWN, il inventerait une autorité. Pour NETCONF, il effacerait trop tôt une limite approuvée. Le remède est de conserver simultanément la proposition la plus récente et la charte actuellement approuvée, avec une valeur nulle explicite lorsque la seconde n’existe pas encore.

Cette séparation touche la réalité. Un périmètre présenté prématurément comme acquis attire des créneaux de réunion, des auteurs, des prototypes et des déclarations de produit. Les groupes voisins peuvent abandonner une question et les autres organismes de normalisation attendre une réponse IETF. Une correction ultérieure restaure l’étiquette ; elle ne rappelle ni le code ni les investissements déjà engagés.

DAWN : un vote sur l’ouverture de l’examen

La fiche de DAWN affichait « Proposed WG Discovery of Agents With Names ». L’état du groupe était Proposed, la charte charter-ietf-dawn-00-00, et l’étape Start Chartering/Rechartering (Internal Steering Group/IAB Review).

La proposition était assez précise pour être prise au sérieux. Elle décrivait la découverte d’agents et de ressources liés à l’IA, distinguait des contextes locaux, internes à une organisation et interorganisationnels, citait des mécanismes possibles, énumérait des livrables et écartait plusieurs fonctions d’identité, de confiance et d’indexation générale. Une telle précision rend la critique possible ; elle ne produit pas l’autorisation qu’elle sollicite.

La question mise au vote était étroite : « Is this charter ready for external review? » Éric Vyncke avait voté Yes. Mohamed Boucadair avait placé un Block. Les autres membres nommés n’avaient pas de position enregistrée, et le résumé indiquait que le passage serait possible une fois le Block résolu.

Le commentaire de Boucadair soutenait le travail tout en demandant de clarifier le déclenchement de la découverte, les modèles opérationnels, la différence entre usages locaux et interorganisationnels, les garanties de confiance et la possibilité qu’un seul protocole couvre l’ensemble. Il s’agissait d’une objection sur le périmètre à résoudre, non d’un rejet final du sujet ni d’un veto personnel perpétuel.

Le Yes ne portait pas davantage que la question. Le raconter comme une approbation du groupe supprimerait l’objet du vote. L’historique de la charte consignait la version 00-00, l’ouverture du vote et l’entrée en examen interne le 24 août, puis le Block le 25. Il ne consignait pas la création définitive.

Le BoF de l’IETF 126 avait déjà réuni terminologie, cas d’usage, exigences et discussion de charte. Cette activité démontrait un problème possible, des compétences et des divergences. Elle ne confiait pas aux participants la décision institutionnelle réservée par la procédure.

Une évolution ultérieure reste possible. DAWN peut être approuvé, modifié, renvoyé ou abandonné. Le constat daté ne prédit rien : il refuse seulement que l’issue future soit antidatée jusque dans la phase préparatoire.

NETCONF : la version 20 ne disparaissait pas

NETCONF se trouvait dans une autre position. Sa page de groupe le classait Active, avec un domaine de travail établi autour de NETCONF, RESTCONF, YANG et de l’administration de réseau.

La fiche de charte présentait charter-ietf-netconf-20-02, mise à jour le 12 août, comme une nouvelle charte en examen interne. Elle ajoutait une réserve impossible à ignorer : les informations affichées concernaient une proposition, tandis que la charte actuellement approuvée restait la version 20.

Il fallait donc conserver trois identités. NETCONF était l’institution active. La version 20 définissait son périmètre actuel. 20-02 proposait un périmètre futur. L’examen de la troisième n’arrêtait ni la première ni la deuxième.

Le vote NETCONF demandait lui aussi si le texte était prêt pour l’examen externe. Christopher Inacio maintenait un Block en raison de l’absence de jalons. Mahesh Jethanandani avait voté Yes, plusieurs membres No Objection, et le résumé prévoyait un passage une fois l’objection résolue. Ce vote procédural ne déplaçait pas la référence vers la charte en vigueur.

Si l’IESG demande une correction, une version ultérieure peut devenir le vrai candidat. Si le projet est retiré, la version 20 reste valable. En cas d’approbation, la décision doit désigner le texte final, l’ancienne charte remplacée et le moment d’effet. Aucune branche n’exige que 20-02 soit réputée applicable dès sa publication.

Traiter le projet comme acquis renverse en outre la charge de la preuve. Normalement, l’auteur d’une extension doit montrer pourquoi elle appartient à NETCONF. Après que réunions, appels à adoption et implémentations se sont organisés autour d’un périmètre fantôme, le réviseur doit expliquer pourquoi il « retire » une compétence jamais accordée.

La participation éclaire la décision sans la posséder

La référence publiée restait RFC 2418, composante de la BCP 25. Elle confie normalement l’élaboration de la charte au président pressenti et à l’Area Director compétent, sollicite l’avis de l’IAB et attribue l’approbation finale à l’IESG. Après l’examen interne, la proposition est exposée plus largement ; l’IESG peut approuver, modifier ou refuser. Le Secrétariat enregistre et annonce ensuite le groupe approuvé.

RFC 2418 qualifie la charte de contrat entre l’IETF et le groupe pour un ensemble de tâches. Ce contrat est une frontière institutionnelle, ni traité politique ni contrat commercial. Il autorise l’organisation ouverte d’un problème précis, avec des objectifs, un chemin et, selon le texte en vigueur, des jalons.

RFC 3710 sépare les contributions. Une initiative peut venir de participants ou d’un Area Director. Les futurs présidents rendent le plan praticable. Les participants apportent savoir, soutien et objections. L’IAB examine les conséquences architecturales. L’examen public révèle les effets opérationnels, de sécurité ou de confidentialité. L’Area Director coordonne ; l’IESG assume la décision de constituer le groupe.

La formule « participer n’est pas autoriser » ne rabaisse pas la communauté. Une objection bien fondée peut réécrire une limite, ajouter une liaison, scinder un livrable ou montrer qu’un groupe n’est pas prêt. La consultation est légitime parce qu’elle apporte des preuves et rend la décision contestable, non parce qu’elle transforme chaque présence en délégation universelle.

En cas de travail important hors charte, la procédure laisse des options : nouvelle charte, autre groupe, travail hors groupe ou création d’un nouveau groupe. Elle n’impose ni l’inaction ni l’annexion silencieuse.

Une charte autorise la question, pas la réponse

Même approuvée, une charte n’adopte aucun texte technique. Un Internet-Draft individuel peut nourrir l’exploration. Une adoption par le groupe choisit une base de travail sans constater l’accord sur chaque phrase. Le rough consensus, le Working Group Last Call, l’examen IESG et la publication RFC sont des décisions ultérieures. Le flux et la catégorie déterminent encore la portée normative du RFC.

Le déploiement appartient à une autre autorité. RFC 3935 rappelle que l’IETF produit des documents d’ingénierie utiles sans pouvoir contraindre l’ensemble d’Internet à les employer. Un opérateur doit choisir une version, désigner un responsable, tester, borner le changement, préparer le retour arrière et observer le système en fonctionnement.

Le projet draft-ietf-procon-2418bis-04 illustrait la même règle. Au 27 août, il restait un WG Document avec l’état IESG I-D Exists. Il rendrait RFC 2418 et RFC 3934 obsolètes s’il était approuvé. La condition fait partie du statut.

Son texte présente la charte comme un engagement de périmètre et précise que l’adoption d’un draft en fait une base de travail, pas un contenu déjà consensuel. La charte PROCON autorise la consolidation d’une chaîne déterminée de RFC de procédure et exige une nouvelle charte pour d’autres changements substantiels. Le mandat d’écrire un successeur n’est pas son approbation anticipée.

Le reçu de passage d’autorité

Un enregistrement robuste commence par le type d’action : INITIAL_CHARTER ou RECHARTER. Il conserve le nom du groupe, son état, l’identifiant de la proposition, sa révision et l’empreinte exacte du texte. Un champ distinct contient la charte approuvée actuelle et son empreinte, ou une valeur nulle explicite avant la formation.

Le volet de périmètre énumère ajouts, retraits, tâches maintenues, exclusions, livrables, groupes voisins et organismes externes. Le volet d’examen conserve l’Area Director, les présidents, la date d’ouverture, la question exacte, les positions, Blocks et conditions de résolution, l’avis IAB, l’annonce externe et le traitement des objections importantes.

Le volet de décision nomme le sort décidé par l’IESG, sa raison publique, la date, l’annonce du Secrétariat, le moment d’effet et l’ancienne charte remplacée. Approbation, retour pour modification, maintien de l’ancien texte, retrait, refus et dissolution sont tous des résultats complets.

Deux négations doivent accompagner toute charte approuvée : elle ne prouve pas le consensus sur un document particulier et n’ordonne pas son implémentation. Décrire les limites ne diminue pas l’autorité ; cela empêche de la gonfler lors de sa réutilisation.

Sources

  1. IETF Datatracker : groupes en cours de création ou de nouvelle charte
  2. IETF Datatracker : groupe DAWN proposé
  3. IETF Datatracker : vote sur la charte DAWN
  4. IETF Datatracker : historique de la charte DAWN
  5. IETF Datatracker : programme du BoF DAWN à l’IETF 126
  6. IETF Datatracker : proposition de nouvelle charte NETCONF
  7. IETF Datatracker : charte NETCONF approuvée, version 20
  8. IETF Datatracker : groupe NETCONF actif
  9. IETF Datatracker : vote sur la charte NETCONF
  10. RFC 2418 : directives et procédures des groupes de travail IETF
  11. RFC 3710 : charte de l’IESG
  12. RFC 6292 : exigences pour les outils de charte
  13. IETF Datatracker : état de draft-ietf-procon-2418bis
  14. IETF Datatracker : texte de draft-ietf-procon-2418bis
  15. IETF Datatracker : charte du groupe PROCON
  16. RFC 3935 : mission de l’IETF
  17. RFC 9281 : entités du processus de normalisation IETF