Résumé

  • La révision 00-01 de la proposition de charte IETF Agent Communication Protocols a été publiée le 14 septembre. Le texte reste en examen interne Steering Group/IAB et figure à l’ordre du jour de la téléconférence IESG du 17 septembre ; le groupe n’est pas encore constitué.
  • Une phrase nouvelle prévoit une coordination avec les travaux de normalisation et les projets open source pertinents hors de l’IETF, afin de comprendre les pratiques déployées et d’éviter une divergence inutile.
  • La phrase précédente confie aux autres groupes IETF concernés les décisions sur les modifications de leurs protocoles. L’information extérieure et l’autorité de décision empruntent donc deux voies distinctes.
  • Daniel Kade propose un reçu de coordination à deux voies. Il ne figure ni dans la charte proposée ni dans le scrutin IESG.

Une petite modification qui attribue les rôles

La version 00-01 ne se présente pas comme un traité entre institutions. Elle décrit un futur travail IETF : un protocole commun de gestion des dialogues entre utilisateurs, agents et outils, une architecture de référence et un document sur les cas d’usage.

À la fin des livrables, deux phrases organisent pourtant une frontière institutionnelle. Si Agentproto a besoin de modifier ou d’étendre un protocole défini par un autre groupe IETF, la question doit être portée devant ce groupe afin qu’il décide de la meilleure manière de la traiter. La spécialisation n’efface donc pas la garde du protocole d’origine.

La phrase ajoutée en 00-01 regarde vers l’extérieur. Le groupe devra se coordonner avec les initiatives de normalisation et les projets open source pertinents pour comprendre la pratique et éviter des trajectoires inutilement incompatibles.

Ce ne sont pas deux degrés d’importance. Ce sont deux natures d’action. Un retour d’implémentation peut invalider une hypothèse, révéler une dépendance ou démontrer une interopérabilité. Il mérite d’entrer dans le dossier. Mais l’admission d’un fait n’emporte pas transfert de décision. De la même façon, un choix IETF ne modifie pas, par lui-même, le dépôt ou la feuille de route d’un projet extérieur.

Le dossier avance, sans être achevé

Le registre Datatracker classe encore le document dans l’étape de démarrage du chartering, sous examen interne du Steering Group et de l’IAB. Il annonce une téléconférence IESG le 17 septembre. Une date de réunion prouve une étape de procédure, pas son résultat.

La comparaison avec la version 00-00 fait apparaître quatre changements. L’adjectif « intelligent » disparaît de la définition initiale de l’agent. Le passage relatif à la protection des échanges inclut désormais les utilisateurs. Une correction grammaticale est apportée. Enfin, la coordination extérieure est inscrite dans le texte.

L’historique et le bulletin d’examen donnent une chronologie. Le 10 septembre, un commentaire demande si le groupe devrait collaborer avec des acteurs non-IETF. Un autre mentionne les échanges avec les utilisateurs et souhaite des jalons couvrant la suite des travaux. Un jalon de soumission à l’IESG en mars 2028 est ajouté le 13 septembre ; 00-01 paraît le lendemain.

Il serait tentant de relier chaque question à chaque correction comme une cause à son effet. Le dossier public consulté ne le permet pas. Il montre des commentaires, puis des éléments concordants dans un texte ultérieur. Il ne contient pas, pour chaque ligne, une décision attribuée et motivée.

Le même soin s’impose pour l’histoire de la BoF Agentproto à l’IETF 126. Les votes à main levée portaient sur des prédicats différents. La nouvelle révision est une étape ultérieure ; elle ne transforme pas ces nombres en mandat rétroactif et n’annonce pas à elle seule la création du groupe.

Les règles de liaison éclairent la frontière

L’IETF possède déjà des mécanismes pour les relations institutionnelles. Le RFC 4052 place les liaisons sous la responsabilité de l’IAB, recommande de les garder aussi informelles que possible et cherche à éviter les doublons sans empêcher chaque organisation de poursuivre son propre mandat.

Le RFC 4691 distingue transmission et représentation. Un responsable de liaison fait circuler l’information dans les deux sens. Il ne peut présenter une position personnelle comme celle de l’IETF : ce qu’il communique au nom de l’institution doit reposer sur le consensus pertinent.

Le RFC 4053 organise la réception, l’aiguillage et la réponse aux déclarations de liaison. Une demande visant à infléchir un groupe est examinée ; elle n’est pas acceptée automatiquement du fait de son expéditeur. Une échéance peut accroître l’urgence, pas l’autorité du contenu.

Cette architecture ne signifie pas que chaque discussion Agentproto avec un mainteneur open source doive devenir une liaison formelle. Le texte 00-01 est plus large. Une issue publique, un test d’interopérabilité, un compte rendu de déploiement ou la contribution individuelle d’un ingénieur peuvent être des canaux adaptés.

Le principe commun est la conservation de l’identité : qui parle, au nom de qui, sur quelle version, avec quel type de preuve et vers quelle décision IETF ? C’est cette chaîne qui empêche une réputation institutionnelle de remplacer l’examen technique.

Un reçu à deux voies

Dans la voie d’entrée, chaque question importante pourrait porter l’artefact extérieur exact, sa version ou son commit, son responsable, la date, le canal et l’affirmation utile. Le statut préciserait s’il s’agit d’une position d’organisation, d’une liaison formelle, d’une contribution individuelle, d’une observation d’implémentation ou d’un résultat encore non vérifié.

Dans la voie de décision, le reçu nommerait le livrable Agentproto concerné, le propriétaire IETF, la discussion publique, l’état et la justification. Un vocabulaire bref suffirait : observé, examiné, adopté, adapté, rejeté, différé ou action demandée au propriétaire extérieur.

Si un autre groupe IETF détient le protocole, son propre dossier de décision doit rester la référence. Si le changement appartient à un projet extérieur, Agentproto peut documenter une demande et sa réponse, non produire un ordre fictif. Toute communication présentée comme une position IETF doit aussi indiquer le consensus qui l’autorise.

Ce reçu protège les deux côtés. Il évite de faire d’une démonstration populaire un choix de standard, mais aussi d’effacer un signal extérieur après qu’il a réellement modifié le projet. C’est une proposition de Daniel Kade, pas une obligation contenue dans 00-01.

Sources

  1. Proposition de charte Agentproto 00-01 avec jalons
  2. Proposition de charte Agentproto 00-00 avec jalons
  3. Historique de la charte Agentproto
  4. Scrutin sur la charte Agentproto
  5. Fiche de la proposition de charte
  6. RFC 4052 — gestion des relations de liaison IETF par l’IAB
  7. RFC 4053 — traitement des déclarations de liaison
  8. RFC 4691 — lignes directrices pour les liaisons IETF
  9. RFC 2418 — procédures des groupes de travail IETF
  10. RFC 5434 — réussir une session BoF
  11. Lu Heng — The Multi-Stakeholder Mirage
  12. Lu Heng — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption