Résumé

  • Par sa résolution 2026-14, adoptée à l’unanimité par consentement écrit le 10 juillet 2026, le conseil de l’Internet Society a réaffirmé sans révision ses consignes pour la liaison auprès du NomCom de l’IETF.
  • Le texte renvoie encore au RFC 3777 pour le processus, la confidentialité et le rôle de liaison. Or le RFC 7437 a remplacé le RFC 3777, puis le RFC 8713 a remplacé le RFC 7437.
  • La consigne exige de transmettre les faits et positions considérés comme le consensus du conseil, sans laisser paraître une opinion personnelle, tout en agissant dans l’intérêt de l’IETF. Elle donne priorité au premier devoir en cas de conflit.
  • Le RFC 8713 conserve les deux fonctions, mais précise que les responsabilités supplémentaires confiées par une organisation ne peuvent contredire ses dispositions. La liaison ne vote pas sur le choix des candidats.
  • Aucun élément public ne montre qu’un conflit s’est produit, qu’une candidature a été influencée indûment ou qu’une préférence personnelle a été révélée. Le déficit porte sur la règle publique, pas sur une faute supposée.
  • L’Internet Society devrait publier une table de concordance avec le RFC 8713 et une fiche de résolution limitée aux questions d’interprétation, sans ouvrir les délibérations confidentielles du NomCom.

Ne rien changer était bien une décision

La résolution 2026-14 réunissait quatre politiques de gouvernance. Le comité de gouvernance proposait des retouches pour trois d’entre elles. Pour les consignes relatives à la liaison auprès du NomCom, il a présenté le texte existant et n’a proposé aucune révision. Le conseil l’a réaffirmé avec effet immédiat. La résolution a été approuvée par consentement écrit unanime le 10 juillet.

Cette séquence ôte une échappatoire commode. Il ne s’agit pas d’une page de 2012 oubliée au fond du site. Le texte a été remis devant l’organe compétent, puis conservé. Le bandeau de la page publique enregistre désormais cette décision de 2026.

Réaffirmer n’équivaut pas nécessairement à valider chaque numéro de section comme s’il avait été écrit hier. Inversement, la présence d’une référence ancienne ne rend pas automatiquement la politique nulle. Mais le conseil a transformé une ambiguïté historique en question présente : quel corpus normatif entend-il incorporer lorsqu’il écrit encore « RFC 3777 » ?

La mention apparaît à trois endroits substantiels. La mission principale consiste à vérifier le respect du processus défini dans le RFC 3777. Les rapports périodiques au conseil doivent respecter ses règles de confidentialité. Enfin, la deuxième consigne numérotée commande de suivre ses règles de liaison.

Le RFC Editor apporte une chronologie sans ambiguïté. Le RFC 3777, publié en 2004, est obsolète. Le RFC 7437 l’a remplacé en 2015. Le RFC 8713 a ensuite remplacé le RFC 7437 en 2020 et constitue aujourd’hui le BCP 10 applicable au fonctionnement des comités de nomination et de révocation de l’IETF.

Les anciens textes restent accessibles, donc aucun lien ne disparaît. Le problème est plus fin : l’incorporation. Le numéro de 2004 désigne-t-il le texte figé de l’époque, son successeur actuel ou seulement certains principes réputés continus ? La pratique peut fournir une réponse raisonnable aux habitués. Une instruction formellement reconduite devrait la fournir à tous.

Une présence sans voix dans le choix des noms

Le mot NomCom peut donner l’impression que toute personne présente participe à la sélection. Le RFC 8713 fixe une frontière nette. Le conseil de l’Internet Society peut désigner une liaison à sa discrétion. Cette liaison ne vote pas sur les candidats. Le président, les autres liaisons et les conseillers sont soumis à la même exclusion, même s’ils peuvent voter sur d’autres questions lorsque le RFC ne l’interdit pas.

La consigne de l’Internet Society sépare également deux canaux. La personne peut transmettre une opinion personnelle par les moyens ouverts à tout participant de l’IETF, par exemple le formulaire général. Dans le canal de liaison, elle doit s’en tenir aux faits et aux positions qu’elle estime correspondre au consensus du conseil. Son avis sur une personne ou sur le processus ne devrait pas pouvoir être déduit.

Le mandat est donc institutionnel et étroit. La liaison représente un organe identifié. Elle ne parle pas au nom de tous les membres de l’Internet Society, des internautes ou d’une « communauté » indéfinie. La distinction proposée par Lu Heng entre partie prenante et mandant est particulièrement utile ici : la présence ne crée pas le mandat, mais le conseil peut en créer un, limité à ses propres positions.

Ce mandat n’accorde ni suffrage ni pouvoir de transformer une position du conseil en décision du NomCom. Il organise une interface d’information et de surveillance du processus.

Le vrai sujet est la hiérarchie entre deux devoirs

À côté de la représentation du conseil, le texte demande d’agir dans l’intérêt de l’IETF. Puis il prévoit le cas où ses trois consignes ne convergent pas. La liaison exerce son jugement, mais la première consigne—transmettre le consensus du conseil sans opinion personnelle—doit primer sur la troisième—agir dans l’intérêt de l’IETF.

Cette hiérarchie n’est pas une interprétation critique ajoutée au document. Elle y figure expressément. Elle ne prouve toutefois ni qu’un conflit s’est déjà produit, ni qu’un trustee a privilégié une institution au détriment d’un candidat, ni qu’une intervention a modifié un résultat. Les sources publiques examinées ne permettent aucune de ces affirmations.

Le RFC 8713 reprend les deux obligations. Il rend les liaisons responsables du suivi de l’exécution des tâches du NomCom et de son président dans l’intérêt de la communauté IETF. Il leur demande aussi de représenter la position de leur organisation, d’apporter les informations utiles, d’expliquer le fonctionnement de leur organisme et de transmettre questions et réponses.

La coexistence est normale tant que la position institutionnelle aide le comité. Une liaison n’est pas suspecte parce qu’elle relaie le point de vue de l’organe qui l’a désignée. C’est la raison même de cette fonction.

Le RFC ajoute néanmoins une limite déterminante. Des responsabilités supplémentaires peuvent être confiées par l’organisation ou demandées par le NomCom, à condition qu’elles n’entrent pas en conflit avec les autres dispositions du RFC. Il impose également un itinéraire : signaler immédiatement au président les difficultés d’exécution, puis utiliser la procédure de règlement des différends si elles ne peuvent être résolues.

La règle de priorité de l’Internet Society et la clause de non-conflit du RFC 8713 ne sont pas forcément incompatibles. La représentation organisationnelle figure elle-même dans le RFC. L’« intérêt de l’IETF » reste une norme d’appréciation. Le conseil peut considérer que sa consigne porte sur la fidélité du message, tandis que le RFC borne les actes possibles dans le comité.

Mais cette conciliation n’est pas publiée. Après une réaffirmation sans amendement, elle demeure une reconstruction faite par le lecteur. Le document devrait dire si la priorité concerne uniquement la formulation d’une position, si le RFC 8713 limite toute action qui en découle, et vers qui la liaison se tourne lorsqu’elle juge les deux devoirs irréconciliables.

Changer le numéro ne suffirait pas

Une correction mécanique de 3777 en 8713 améliorerait déjà la lisibilité. Elle ne constituerait pas une véritable mise à jour. Le RFC 8713 a consolidé plusieurs évolutions institutionnelles, réorganisé des règles et intégré les rôles de l’IETF Trust et de l’IETF LLC. Il a lui-même été mis à jour depuis. Les paragraphes de 2004 ne se déplacent pas nécessairement à l’identique dans le texte courant.

La confidentialité offre un bon test. La consigne veut que le conseil reçoive des rapports périodiques compatibles avec les règles du NomCom. C’est légitime. Mais il faut distinguer un rapport sur l’état du processus d’une information sur une personne. « Le processus suit son calendrier », « une difficulté procédurale a été soumise au président » ou « une question de règle a été escaladée » ne sont pas des évaluations de candidat. Le texte courant devrait identifier cette frontière à partir du RFC actuel.

La fonction de liaison mérite le même traitement. Une table de concordance peut associer chaque consigne de 2012 aux fonctions actuelles : représenter l’organisation, fournir des informations, surveiller l’exécution, signaler un problème, recourir au mécanisme de différend et ne pas voter sur les candidatures. Le titulaire de la fonction, le président du NomCom et le conseil disposeraient alors de la même carte.

Enfin, la hiérarchie des devoirs doit être datée et motivée. Si le conseil souhaite la conserver, il peut expliquer comment elle respecte la clause de non-conflit. S’il la considère limitée à la transmission exacte d’une position, il doit l’écrire. S’il estime qu’une divergence doit désormais déclencher un renvoi plutôt qu’une priorité unilatérale, il peut le décider sans réécrire l’histoire.

Un reçu de règle, pas une fenêtre sur les candidats

La confidentialité du NomCom protège un processus humain sensible. Elle permet de solliciter des candidatures, d’obtenir des appréciations franches et d’éviter une campagne publique permanente. L’obligation de rendre la règle intelligible ne justifie pas de publier les noms, les avis, les comparaisons ou les délibérations.

Le bon objet public tient en deux étages.

Le premier est une table stable. Pour chaque clause de 2012, elle indiquerait la disposition actuelle du RFC 8713, le devoir maintenu, les changements de terminologie, le propriétaire de l’interprétation et sa date d’effet. Elle conserverait le texte historique et noterait séparément l’adoption initiale et la réaffirmation de 2026.

Le second est un reçu minimal lorsqu’une question d’interprétation se présente. Il pourrait mentionner la catégorie du problème, les rôles qui l’ont transmis, les clauses appliquées, la date et une issue—résolu, retiré ou porté au mécanisme de différend. Il ne décrirait ni la personne concernée, ni la position du conseil sur cette personne, ni le débat du comité.

Ce format ne permet pas au public de refaire le choix du NomCom. Il permet de vérifier qu’une instruction d’organisation a été comparée à la règle actuelle et que le bon canal a traité l’écart.

Une gouvernance légère consiste justement à publier l’état commun minimal. Le mandat, le conseil, la surveillance et la sélection doivent rester des catégories différentes. Le secret légitime sur les candidatures ne doit pas se transformer en secret sur la norme.

La question du mandant est ici plus précise

Le cas se distingue des dispositifs qui invoquent « la communauté » sans chaîne d’autorisation. L’Internet Society nomme le mandant représenté : son conseil. C’est un progrès conceptuel. Un trustee désigné ne tire pas son droit de parler du simple fait d’être dans la salle.

La précision doit toutefois être conservée jusqu’au bout. Le consensus du conseil autorise la transmission d’une position du conseil. Il ne devient pas le consensus du NomCom. Il n’accorde pas de vote. Il ne fait pas du conseil le mandant de l’IETF. Le devoir d’agir dans l’intérêt de l’IETF matérialise cette limite.

Le 10 juillet, le conseil a choisi de garder la formulation de 2012. Il lui reste à raccorder cette formulation au texte qui gouverne aujourd’hui le comité. Le geste demandé est modeste : une carte à jour pour une interface qu’il a lui-même décidé de maintenir.

Sources

  1. Internet Society — Consignes pour la liaison du conseil auprès du comité de nomination de l’IETF
  2. Internet Society — Résolution 2026-14 adoptée par consentement écrit
  3. RFC Editor — Fiche du RFC 3777
  4. RFC Editor — Fiche du RFC 7437
  5. RFC Editor — RFC 8713, BCP 10 actuel
  6. Lu Heng — The Multi-Stakeholder Mirage