Résumé

  • L’IETF distingue l’appel qui n’est pas traité à l’entrée de celui dont les arguments sont examinés puis rejetés. Les conséquences et les traces publiques diffèrent.
  • Les appels acceptés par l’IESG figurent dans Datatracker. Pour un appel non traité, les règles prévoient un accusé de réception et un motif, puis une information à compléter ou une voie de révision publiée sur une liste.
  • La liste des appels acceptés n’est donc pas nécessairement un registre complet des saisines. Un index reliant les deux parcours aiderait à lire les décisions sans modifier les critères de fond.

Un résultat vide dans le dossier public des appels de l’IESG semble facile à interpréter : aucun appel n’aurait été déposé. Les règles actuelles de l’IETF ne permettent pas cette conclusion à partir de cette seule page. Elles distinguent l’appel accepté, inscrit dans Datatracker, de la soumission qui n’est pas traitée et dont le motif doit être consigné dans un message à une liste publique. La première trace n’a pas le même périmètre que la seconde.

Cette distinction figure dans la déclaration de l’IESG sur les procédures de résolution des conflits et d’appel, publiée le 1er octobre 2025 et toujours indiquée comme active. Le texte précise les modalités de la section 6.5 de la RFC 2026, qui reste le cadre de référence. La RFC exige une description précise des faits du différend, prévoit un délai initial de deux mois à partir de la connaissance publique de la décision contestée et laisse aux décideurs la latitude de définir leur procédure. Elle demande une décision dans un délai raisonnable, sans fixer une durée maximale universelle.

La déclaration précise ensuite les limites à l’entrée. Les procédures de l’IESG, des directeurs de domaine (AD) et des présidents de groupe de travail portent sur des différends techniques ou procéduraux liés au processus de normalisation. Ces instances ne sont pas chargées de trancher des prétentions juridiques. Une soumission qui leur adresse de telles prétentions est hors champ et ne doit pas être traitée ; la personne est renvoyée vers l’IETF Administration LLC. Le texte donne aussi des exigences de contenu, de forme et de conduite. Un appel doit identifier la décision contestée, ses motifs et la réparation demandée.

Il doit s’appuyer sur des faits et un raisonnement, sans conjecture ni accusation personnelle. Les appels adressés à l’IESG ou aux AD sont rédigés en anglais et envoyés par courriel sous forme de texte.

Si l’IESG ne traite pas une soumission, la déclaration impose une trace publique. Pour un problème de contenu, de forme ou de champ, cette trace doit accuser réception et expliquer le motif. Si le dossier est incomplet, elle doit préciser les informations manquantes. Une voie de correction subsiste : les versions révisées peuvent être déposées jusqu’à la date la plus tardive entre le délai initial de deux mois prévu par la RFC 2026 et quatorze jours après la réponse de l’IESG. La décision de ne pas traiter et les instructions de nouvelle soumission sont communiquées par courriel à une liste publique.

Si aucune liste publique n’a été indiquée, l’IESG utilise la liste de discussion de l’IETF. La décision de ne pas traiter peut elle-même faire l’objet d’un appel.

Les appels acceptés empruntent un autre chemin. La déclaration indique qu’ils sont enregistrés sur la page IESG Appeals de Datatracker. Un exemple récent montre ce qu’est une décision après examen. La page mentionne un appel du 8 juillet 2026, un suivi le lendemain puis une réponse du 10 septembre. Dans sa réponse à un second appel au sujet de draft-ietf-tls-mldsa, l’IESG dit avoir évalué les commentaires de la dernière période d’examen du groupe de travail. Elle estime que le consensus approximatif a été correctement établi, avec un soutien large et des objections examinées et discutées. Elle rejette cette demande, rejette l’appel dans son ensemble et note qu’un directeur de domaine n’a pas participé au traitement. Ce sont les conclusions consignées par l’IESG ; cet article ne les présente pas comme une expertise technique indépendante.

Ce cas est utile parce qu’il expose une décision et son motif. Il ne prouve pas que chaque appel reçoit la même explication, ni qu’une autre soumission aurait été écartée à l’entrée. La déclaration décrit les obligations générales ; la réponse du 10 septembre rapporte la décision prise sur un dossier précis. Confondre ces deux niveaux reviendrait à prendre un exemple pour une règle.

La conséquence est simple : « non traité » et « rejeté après examen » ne sont pas des synonymes. Le premier décrit une décision de procédure sur l’accès à l’examen ; le second, une décision rendue après examen. Les réduire à un même statut ferait disparaître le motif et la possibilité de corriger le dossier. De même, l’absence d’une entrée dans la liste des appels acceptés ne prouve pas, à elle seule, qu’aucune soumission n’a été reçue. C’est une déduction tirée des deux circuits de publication prévus par le texte, pas la preuve qu’un dossier caché existe.

L’IETF pourrait rendre ces parcours lisibles sans créer une nouvelle procédure de fond. Un index public et sobre relierait les références existantes : reçu ; non traité, avec motif ; compléments ou révision attendus ; accepté pour examen ; décision publiée ; appel ultérieur éventuel. Il indiquerait les dates, la version de la règle applicable, le lieu où se trouve le message public et l’échéance de correction lorsqu’elle s’applique. Le message d’origine et la page Datatracker resteraient les sources faisant foi.

L’index n’aurait pas besoin de reproduire chaque courriel ni d’ajouter des données personnelles au-delà de ce qui est nécessaire au rapprochement.

L’enjeu n’est pas d’obtenir un chiffre plus élevé, mais de savoir ce que le chiffre compte. La liste des appels acceptés répond à une question ; les avis publics de non-traitement en répondent à une autre. Avec un point d’accès commun, les lecteurs pourraient distinguer une liste vide d’une période sans saisine, et une décision d’entrée d’un jugement sur le fond. Sans lien entre les deux, un analyste peut prendre une trace partielle pour le processus entier.

Un registre central comporte toutefois un risque : les doublons peuvent diverger, et une copie agrégée peut révéler des détails que les sources n’avaient pas besoin de réunir. L’index devrait donc renvoyer vers les documents faisant foi, dater ses mises à jour et signaler les liens non vérifiés. En cas d’information manquante, il doit afficher l’incertitude plutôt que la combler. La commodité de recherche ne justifie pas de modifier le sens d’un dossier.

Un appel n’est pas non plus un vote sur la représentativité de son auteur. C’est une voie de recours portant sur une décision déterminée dans le processus de normalisation. La participation rend une contestation visible ; la trace motivée permet d’examiner ce que l’institution en a fait. Ni l’une ni l’autre ne prouve que l’appel était fondé ou infondé. Des statuts exacts servent précisément à éviter que des allégations soient transformées en conclusions officielles.

Les règles de l’IESG séparent déjà la décision d’entrée de l’examen au fond, et elles attribuent à chaque étape un circuit public. L’amélioration consiste à rendre les liens entre ces circuits consultables. Le lecteur doit pouvoir voir si l’appel n’a pas été traité ou s’il a été rejeté après examen, où se trouve la trace applicable et quelle étape a suivi. Un registre ainsi relié devient la preuve de ce que la procédure a fait — sans prétendre représenter ce qu’elle n’a pas enregistré.

Sources