Résumé

  • Le 28 août, l’IESG a annoncé la fin du groupe Security Dispatch, la fermeture prochaine de sa liste et l’intégration de sa fonction au groupe DISPATCH, désormais compétent pour ART, SEC et la partie non-transport de WIT.
  • Une fusion de guichets ne transfère pas automatiquement le sens des dossiers. Il faut relier chaque proposition à son dernier résultat, à la nature non contraignante de cet avis, à son archive et à son éventuelle destination.

La continuité du guichet ne suffit pas

Le communiqué de l’IESG ne supprime pas la possibilité de soumettre de nouvelles idées de sécurité. Il indique un autre point d’entrée. Christopher Inacio et Deb Cooley y sont désignés comme contacts de l’IESG, tandis que l’ancienne liste de discussion doit être fermée.

Ce changement avait été préparé. La nouvelle charte de DISPATCH, approuvée le 2 juillet, couvre les travaux proposés dans les domaines ART et SEC ainsi que les sujets WIT qui ne relèvent pas du transport. Une réunion intérimaire commune le 30 juin, puis une séance unique à l’IETF 126, montrent que le dispositif commun fonctionnait déjà.

Réunir les premiers échanges peut réduire une difficulté réelle. Une proposition portant sur l’identité, la messagerie ou une application web peut traverser plusieurs frontières administratives. Demander à son auteur de choisir le bon organigramme avant même la discussion ajoute un coût sans améliorer le fond.

Mais DISPATCH n’est pas un organe d’adoption des normes. Sa charte lui permet d’orienter un travail vers un groupe existant, un BoF, la préparation d’une nouvelle charte, une éventuelle voie parrainée par un directeur de domaine ou une nouvelle liste. Il peut aussi proposer d’attendre ou de ne pas poursuivre. Ses indications ne sont pas contraignantes. Si les présidents ne peuvent pas constater un consensus, aucun avis n’est garanti. Hors de documents administratifs étroits acceptés avec les directeurs concernés, le groupe ne développe pas les textes techniques.

Six propositions, six états différents

Le compte rendu envoyé après la réunion commune du 30 juin constitue un bon test. Environ cinquante personnes y ont participé. Les présidents ont publié six résultats et demandé aux deux listes de signaler tout désaccord avec leur constat de consensus approximatif.

Les libellés ne sont pas interchangeables. Pour une proposition, l’auteur a évoqué la voie de l’Independent Submission Editor ; le message précise que cette possibilité n’était pas une action de Dispatch. Deux sujets n’ont pas été présentés. Un autre n’appelait aucune action de l’IETF. Un quatrième ne justifiait pas d’action à ce stade et devait d’abord réunir davantage d’intérêt d’implémentation et un espace de discussion. Un cinquième a été dirigé vers le BoF DAWN et son effort d’organisation.

Une archive qui conserve uniquement les titres ne suffit pas. « Pas de présentation » n’est pas un rejet technique. « Pas d’action pour le moment » n’est pas une interdiction définitive. Une orientation vers un BoF n’est pas la création d’un groupe. Le changement de structure ne doit ni renforcer ni affaiblir ces qualifications.

RFC 7957 explique cette fonction : un groupe de type DISPATCH évalue et oriente, mais n’achève pas le travail proposé. Il peut documenter pourquoi une piste n’a pas été poursuivie. Pour les cas frontières, le choix du lieu appartient aux directeurs de domaine et présidents responsables. RFC 2418 situe par ailleurs la dissolution d’un groupe dans une décision du directeur de domaine, après consultation, avec une possibilité d’appel à l’IESG.

Un registre de transfert proposition par proposition

À la date de vérification, l’archive publique de SECDISPATCH restait accessible et affichait 1 699 messages. Rien dans les sources examinées ne prouve qu’un dossier ait été perdu, ni que l’archive doive disparaître. Le problème est celui du raccordement.

Pour chaque proposition substantiellement traitée, une ligne publique devrait conserver l’identifiant et la version du texte, le dernier fil pertinent, la réunion, le libellé exact du résultat, l’état du consensus, la catégorie d’autorité, la destination, le responsable de l’action suivante, les conditions d’un nouveau passage et le lien vers toute discussion ultérieure dans DISPATCH. Un résultat remplacé devrait rester visible avec sa date et son auteur institutionnel.

Ce registre ne créerait aucun droit à une nouvelle séance. Il ne transformerait pas un avis en mandat. Il éviterait simplement qu’une orientation administrative soit racontée plus tard comme une approbation technique.

Une référence à corriger

Le communiqué de fermeture renvoie à « RFC7975 ». Or RFC 7975 décrit une interface de redirection entre réseaux de diffusion de contenu. La charte approuvée cite RFC 7957, le BCP consacré aux groupes de type DISPATCH. Un chiffre erroné ne rend pas la fusion invalide et rien n’indique qu’il ait modifié une décision. Il mérite néanmoins une correction ou une annotation, car le communiqué servira probablement de panneau indicateur vers le nouveau processus.

Les sources ne démontrent ni contentieux, ni proposition bloquée, ni disparition d’archive. L’absence de procès-verbal visible pour la séance IETF 126 sur la page consultée ne prouve pas qu’aucun résultat n’existe ailleurs. Le registre proposé est une recommandation de Daniel Kade, pas un engagement annoncé par l’IETF.

Sources