Résumé

  • Le RFC 8126 définit dix politiques d’enregistrement pour les registres de paramètres gérés par l’IANA ; pour deux d’entre elles, Private Use et Experimental Use, l’IANA n’enregistre aucune valeur.
  • La contestation obéit à une horloge fixe : l’appel doit être engagé dans les deux mois de la connaissance publique. La décision, elle, obéit à un « délai raisonnable » sans nombre universel, la prévisibilité étant définie comme l’absence d’étapes inattendues, non comme un nombre de jours promis.
  • L’IAB peut annuler une décision de l’IESG et rétablir la situation antérieure, mais ne peut pas prendre une décision réservée à l’IESG, et aucune disposition examinée ne l’autorise expressément à ordonner l’enregistrement. L’IESG est l’organe qui nomme, et peut révoquer à sa discrétion, l’expert dont le jugement est contesté.

Partons d’une demande, pas d’un principe. Quelqu’un veut faire inscrire une valeur dans un registre de paramètres de protocole géré par l’IANA. Le registre, les noms de champs et la politique applicable sont trois choses différentes, et la propre documentation de l’IANA, affichée comme révisée le 13 juillet 2026, le dit sans détour : différentes plages d’un même registre peuvent suivre des procédures d’enregistrement différentes, si bien que nommer le registre ne revient pas à nommer la règle (IANA, Guidance for RFC Authors). La même page demande au demandeur d’identifier le registre exact et de fournir les informations de champs requises, et prévient que le RFC de référence du registre peut exiger un modèle comportant des champs que l’affichage du registre ne montre jamais.

Qui décide réellement relève de l’instrument, pas de l’habitude. Le RFC 8722, document informatif de l’IAB publié en février 2020, place le travail de l’opérateur de registre dans l’enregistrement des paramètres selon les critères et procédures définis par les RFC et selon la politique de registre applicable, les ambiguïtés étant renvoyées pour clarification (RFC 8722, §2.1). Le même document retire l’appréciation technique des épaules de l’opérateur : « the Registry Operator will seek and follow technical guidance exclusively from the IESG », et l’évaluation technique n’est généralement pas de sa responsabilité (RFC 8722, §2.3). La nomination et la fin des fonctions de l’organisation opératrice du registre relèvent de l’IAB travaillant avec l’IETF LLC — un acte distinct de la nomination des experts individuels (RFC 8722, §2.2).

Le menu des politiques est un ensemble fermé de dix. Le RFC 8126, publié en juin 2017, énumère Private Use, Experimental Use, Hierarchical Allocation, First Come First Served, Expert Review, Specification Required, RFC Required, IETF Review, Standards Action et IESG Approval (RFC 8126, §§4.1–4.10). Deux de ces catégories sont muettes par construction : les valeurs Private Use et Experimental Use ne sont pas enregistrées du tout par l’IANA. Specification Required ajoute à Expert Review une exigence documentaire — une spécification permanente, publiquement accessible, claire et techniquement solide, suffisante pour permettre une interopérabilité indépendante, pas nécessairement un RFC (RFC 8126, §4.6).

Là où l’expert dispose de critères publiés, il les applique. Là où le registre n’en a aucun, le RFC 8126 lui demande d’apprécier la complétude de la documentation, l’interopérabilité et les conflits, et de présumer l’acceptation en l’absence d’objection déterminante (RFC 8126, §§5.1–5.3). Le refus a des motifs nommés — rareté de la ressource, documentation peu claire, effets architecturaux ou de déploiement préjudiciables, conflits préjudiciables avec les travaux de l’IETF — et aucun autre n’est listé (RFC 8126, §5.3).

Vient l’horloge. Le RFC 2026, publié en octobre 1996 et toujours le filet procédural, l’écrit et le pense : « All appeals must be initiated within two months of the public knowledge of the action or decision to be challenged » (RFC 2026, §6.5.4). La même section astreint les décideurs à la procédure, leur impose de décider et de communiquer dans un délai raisonnable, et ne fournit aucune échéance fixe universelle. Les principes de l’IAB pour l’exploitation des registres de l’IANA disent la même chose sur un autre registre : un traitement prévisible consiste à éviter les étapes inattendues, non à garantir que les décisions d’experts arrivent dans un nombre de jours prédéterminé (RFC 8720, §3.1). Lisez ces deux dispositions côte à côte : une asymétrie apparente apparaît. La partie qui a un grief est chronométrée ; la partie qui tient la plume ne reçoit aucun nombre. Rien ici n’établit que la rédaction soit intentionnelle.

L’échelle commence là où le refus s’est produit. Le RFC 8126 oriente une contestation d’une décision d’enregistrement vers l’IESG, puis vers l’IAB, et applique aux litiges impliquant des équipes d’experts la procédure de différend du RFC 2026 §6.5.1 (RFC 8126, §10). Cette procédure incorporée passe par les présidents de groupes de travail, puis les directeurs de domaine responsables, puis l’IESG complet, puis l’IAB, chaque organe devant examiner et tenter de résoudre, l’IAB étant final sur la conformité procédurale et le mérite technique (RFC 2026, §6.5.1). Lorsqu’une défaillance de procédure est constatée, l’IESG réexamine son action et en rend compte à l’IETF ; l’IAB peut annuler la décision de l’IESG et rétablir la situation antérieure, ou recommander une action, mais il ne peut pas prendre de décisions réservées à l’IESG (RFC 2026, §6.5.2).

Cette dernière clause pèse plus que sa longueur ne le suggère, et la conclusion qu’on en tire ici est une lecture de cet article, non une phrase écrite par l’un ou l’autre document : si l’issue la plus forte identifiée dans l’échelle examinée est une annulation rétablissant la situation antérieure, et si ce sommet ne peut pas prendre une décision réservée à l’IESG, alors les dispositions examinées ne confèrent pas expressément le pouvoir d’ordonner l’enregistrement. Cela laisse ouvertes une recommandation, une annulation suivie d’un réexamen, ou une voie propre à l’espèce menant à un enregistrement ultérieur. Annuler n’est pas ordonner.

Un demandeur peut gagner l’argument sans que l’appel lui-même inscrive la valeur.

Un dernier fait structurel, et c’est celui qu’il faut punaiser au-dessus du bureau. Le RFC 8126 §5.2.1 énonce, mot pour mot, que « The IESG may remove any designated expert that it appointed, at its discretion », et la même section décrit l’IESG nommant et remplaçant les experts des registres de l’IETF, normalement sur recommandation d’un directeur de domaine (RFC 8126, §5.2.1). La section 10 adresse la contestation à ce même organe en premier. Aucun des deux documents ne réconcilie le rôle de nomination avec le rôle d’appel, et aucune séparation entre eux n’est énoncée dans les dispositions examinées. Le premier échelon institutionnel nommé dans la chaîne est l’organe qui nomme l’expert : la voie du §10 passe par les présidents de groupes de travail et les directeurs de domaine responsables avant l’IESG complet, et savoir qui entend un appel donné, et si les mêmes personnes y siègent, n’est pas établi ici.

D’autres dispositions adoucissent les bords sans changer la forme. L’IESG peut exceptionnellement passer outre les procédures d’enregistrement au cas par cas (RFC 8126, §3.3). Des retards répétés et inexpliqués dans l’examen par l’expert obligent l’IANA à saisir l’IESG, qui doit corriger la situation ou remplacer l’expert (RFC 8126, §5.3) — un remède visant le retard, pas la valeur demandée. Et le principe de transparence est explicite : « the recommendations by designated experts must be visible to the public to the maximum extent possible and subject to challenge or appeal » (RFC 8720, §3.3). La visibilité est promise. Une date de décision ne l’est pas.

Le dossier autour de l’instrument est vivant, et il bouge. Le RFC 9907, publié en mars 2026, met à jour le RFC 8126 et rend obsolète le RFC 8407, en exigeant des instructions reliant les changements d’un registre faisant autorité à la maintenance du module YANG maintenu par l’IANA correspondant, les nouvelles valeurs devant figurer dans le registre et non être ajoutées directement au module (RFC 9907). Le fichier d’errata montre ce que la communauté a déjà tenté : l’erratum technique 6522, rejeté le 8 avril 2021, aurait expressément permis à des versions datées d’Internet-Draft de satisfaire le critère documentaire du §4.6, et le vérificateur l’a traité comme une proposition de politique exigeant discussion et consensus, non comme la correction d’une erreur ; l’erratum éditorial 5772, retenu pour mise à jour du document le 3 juillet 2019, concerne une référence de remerciements et rien d’autre (errata du RFC 8126). Ce rejet consigne le refus d’une rédaction proposée. Il n’établit pas qu’aucun Internet-Draft n’a jamais été accepté en pratique sous les règles d’un registre quelconque, et le §4.6 tel qu’écrit ne cite pas les Internet-Drafts parmi les formes acceptables.

Un texte de remplacement existe et n’est pas en vigueur. Le draft-ietf-ianabis-rfc8126bis-05 a été publié le 2 novembre 2026 ; son résumé dit qu’il rend le RFC 8126 obsolète, tandis que son propre en-tête conditionne cela à une approbation et que son statut le présente comme un Internet-Draft, un travail en cours (draft-ietf-ianabis-rfc8126bis-05). Le RFC 8126 est donc lu ici comme le texte opérant ; le remplacement est enregistré comme conditionnel, non comme une substitution accomplie.

Trois limites vont à côté des affirmations, pas à la fin du texte. Aucune demande d’enregistrement réelle, aucun refus, aucun dépôt d’appel et aucune décision n’ont été examinés : tout ce qui précède décrit le cadre publié, pas la manière dont une demande particulière a été traitée. Les politiques qui lient un registre particulier n’ont pas été établies — un même registre peut en porter plusieurs. Le traitement interne d’un appel par l’IESG, et tout historique non publié d’appels passés, n’ont pas été obtenus.

Une limite de recherche, dite une fois : trois tentatives de recherche sur la classe d’instruments de la fonction de nommage de l’IANA ont échoué chez le fournisseur avant que cette piste soit fermée, et le contrat de la fonction de nommage, la charte du Customer Standing Committee et le rapport de la Naming Function Review restent non lus dans cette revue. C’est une lacune de la recherche de ce bureau. Ce n’est pas une conclusion sur ces documents.

Qu’est-ce qui changerait la lecture ? Une décision d’appel publiée qui se termine par une valeur enregistrée sous la direction de l’IAB plutôt que de l’IESG, ou un registre qui écrit ses propres critères et convertit ainsi une acceptation présumée en test vérifiable. D’ici là, le résumé honnête pour quiconque s’appuie sur une entrée de registre de l’IANA est plus étroit qu’il n’y paraît : le cadre publie la norme, publie la promesse de transparence, et confie le calendrier et le dernier mot aux mêmes quelques personnes.