Résumé

  • RFC 5226 délègue à l’expert désigné une question circonscrite : faut-il recommander cette attribution à l’IANA ? Il ne fait ni de l’expert le propriétaire de l’espace de noms, ni de l’IANA l’auteur de la politique.
  • La mention Expert Review n’est pas un règlement complet. Les pièces demandées, les critères d’évaluation et les motifs défendables de refus doivent être publiés ; RFC 8126 ajoute notamment le contrôleur de changement, la récusation, le remplacement et la vigilance sur les versions.
  • Une décision durable devrait lier la version de la demande, les preuves, la version des critères, la recommandation motivée et l’historique ultérieur. Une attribution prouve alors le passage d’une procédure déterminée, pas une certification de sécurité ni un déploiement réussi.

Le dossier n’était pas le règlement

Plaçons-nous dans un cas construit. Un nouveau registre indique seulement : « Expert Review ». Le spécialiste nommé reçoit une demande et réclame deux implémentations, un modèle de menace et une analyse de raréfaction des valeurs. La demande suivante, traitée un an plus tard par un remplaçant, se voit imposer d’autres pièces.

Il est possible que les deux experts aient posé de bonnes questions. Le problème se trouve en amont : le document fondateur n’a pas dit lesquelles relevaient du pouvoir délégué. Il a choisi une personne sans terminer la règle de décision.

Cette distinction est plus importante que le prestige de l’expert. Une compétence technique permet de juger des faits difficiles. Elle ne crée pas, à elle seule, le droit de fixer rétroactivement la charge de la preuve, d’étendre le but du registre ou de transformer une préférence d’architecture en condition d’accès.

RFC 5226 donne une architecture institutionnelle sobre. L’IANA n’invente pas la politique d’attribution ; elle applique une politique définie ailleurs. La version texte décrit cette délégation avec précision. La version Datatracker, la fiche RFC Editor, l’historique et la page d’errata fixent aussi sa place dans le temps : RFC 5226 a été remplacé par RFC 8126.

Il faut donc lire le texte de 2008 comme l’origine d’un mécanisme, puis son successeur comme le contrat actuel qui l’a rendu plus explicite.

Le guichet ne rédige pas la loi du registre

Plusieurs actes se rejoignent dans la même ligne d’un tableau IANA, ce qui encourage à les confondre.

Le RFC fondateur choisit l’espace, les champs de la demande, la procédure de revue, le format des entrées et les réservations. L’IANA reçoit la demande et tient le registre. L’IESG nomme les experts relevant du flux IETF et peut les remplacer. L’expert organise l’examen et formule une recommandation. La procédure normale fournit le recours.

La documentation IANA destinée aux auteurs demande le nom exact du registre et les informations nécessaires à chaque champ. La page des formulaires rappelle qu’il faut d’abord consulter la procédure applicable. L’état IANA review du Datatracker expose un moment du chemin éditorial. Ces interfaces administrent la règle ; elles ne sont pas censées la réécrire en silence.

Dire « l’IANA a approuvé » efface donc trois objets : le texte qui autorise, l’expert qui recommande et l’opérateur qui enregistre. Cette formule peut faire porter au teneur du registre une décision qu’il n’a pas conçue, ou conférer au conseiller technique une souveraineté que le mécanisme n’a jamais créée.

Une piste d’audit sérieuse conserve séparément l’auteur de la règle, l’administrateur du dossier et l’auteur du jugement technique.

La liste discute ; quelqu’un doit conclure

RFC 5226 ne crée pas l’expert par goût de la personnalisation. Il constate une faiblesse pratique. Une liste publique peut recueillir des objections et des connaissances, mais ne produit pas toujours une conclusion nette. L’IANA ne peut pas suivre toutes les listes ni décider à quel instant leur conversation devient consensus. Enfin, les groupes de travail ferment.

RFC 2418 décrit cette vie des groupes. RFC 7282 présente le rough consensus comme une discipline d’ingénierie qui recherche et traite les objections, non comme un simple scrutin. RFC 3935 rattache la mission de l’IETF à un Internet qui fonctionne mieux. Aucun de ces textes ne transforme une assemblée ouverte en mandant universel et permanent.

L’expert apporte une sortie opérationnelle. Il peut consulter une liste, des spécialistes, un groupe actif ou la communauté d’un groupe dissous, puis renvoyer une recommandation claire à l’IANA. Il agit comme coordinateur de l’examen ; il n’a pas à réaliser seul chaque analyse.

Mais la portée reste étroite : recommander l’attribution selon la politique de ce registre. Elle ne comprend pas une homologation du produit, une autorisation commerciale ou une promesse sur la réalité du déploiement.

Sans critères, l’expertise devient une variable cachée

RFC 5226 attend de l’expert qu’il défende ses décisions devant la communauté. L’examen ne doit être ni secret ni source d’un pouvoir incontestable. Le texte préfère des critères propres au protocole. En leur absence, la présomption va vers l’attribution, sauf raison impérieuse.

RFC 8126 renforce cette mécanique. Sa version texte demande au registre d’indiquer les pièces nécessaires, les éléments à considérer et les raisons de rejeter. La copie Datatracker, la fiche de statut, l’historique documentaire et les errata permettent de rattacher cette exigence au BCP actuel.

Les motifs proposés sont concrets : rareté du code, documentation trop floue pour évaluer l’interopérabilité, incompatibilité grave avec l’architecture ou le modèle de sécurité du protocole de base, dommage aux systèmes déployés, collision avec un travail IETF actif qui nuirait à l’interopérabilité.

Une préférence personnelle n’est pas de même nature. L’expert n’est pas censé devenir un gardien restrictif, sauf si le document fondateur l’ordonne et explique pourquoi. L’ambiguïté ne constitue pas une délégation plus large ; elle rend le refus plus difficile à justifier.

Motiver protège le demandeur et l’expert

Une réponse binaire suffit à avancer dans la file. Elle ne suffit pas à maintenir un espace de noms pendant vingt ans.

Le compte rendu doit associer une version précise de la demande, les éléments examinés, les critères en vigueur, les consultations, les éventuels conflits et les raisons de la recommandation. RFC 8126 souligne que l’avis porte sur une version à un instant donné. Une modification substantielle ultérieure peut rendre nécessaire un nouvel examen.

L’analogie avec une revue de code est directe : approuver un commit n’équivaut pas à approuver toutes les versions futures. Sans empreinte de version, une institution attribue au jugement initial une continuité qu’il n’a jamais eue.

Daniel Kade/BTW propose un reçu en cinq parties, sans prétendre qu’il soit prescrit par un RFC :

  1. version de la demande ;
  2. preuves fournies ;
  3. version des critères ;
  4. recommandation motivée et état des conflits ;
  5. action du registre et historique des changements.

Ce reçu permet de distinguer un dossier incomplet, une vraie objection d’interopérabilité, une contrainte de rareté et un choix stylistique. Il rend également les décisions comparables sans nier la part de jugement.

La récusation n’est pas un détail personnel

Le meilleur spécialiste peut être auteur du texte examiné, défenseur d’une proposition concurrente ou conseiller d’un acteur concerné. RFC 8126 demande à l’expert en conflit de se récuser. Si tout le groupe est en conflit, un expert temporaire doit être recherché ; le directeur de domaine responsable peut le nommer ou prendre le dossier.

L’indisponibilité est un autre risque. L’IESG peut nommer un remplaçant et retirer un expert qu’il a nommé. Des délais répétés sans réponse doivent être remontés, car un numéro attendu peut bloquer un produit ou pousser les développeurs vers des valeurs provisoires incompatibles.

Plusieurs experts ne suppriment pas la responsabilité. Ils doivent produire une recommandation unique. L’IANA ne tranche pas leur débat technique. Un blocage extrême remonte à l’autorité de désignation.

Le recours complète la structure. RFC 5226 et RFC 8126 renvoient à RFC 2026 : IESG d’abord, IAB si nécessaire. Contester une décision ne nie pas la compétence du réviseur ; cela vérifie qu’elle est restée dans le mandat.

L’attribution ouvre une histoire de changements

Une entrée ne disparaît pas avec le courrier qui l’a créée. Une référence sera corrigée, un contact changera, un usage deviendra obsolète ou déconseillé. RFC 8126 recommande donc un champ de contrôleur de changement pour plusieurs politiques.

Le contrôleur de changement ne répond pas à la question initiale « faut-il attribuer ? ». Il répond à « qui peut modifier ensuite, et jusqu’où ? ». L’auteur de la demande n’a pas nécessairement le droit de réaffecter une valeur à une sémantique incompatible. L’expert initial n’est pas automatiquement propriétaire de tous les amendements.

L’allocation anticipée révèle encore mieux la dimension temporelle. RFC 7120 organise une attribution temporaire pour des travaux en cours. Elle facilite l’implémentation sans feindre que la publication finale est acquise. Temporaire, permanent, deprecated et obsolete sont des états de cycle de vie.

Le registre doit garder l’histoire. Supprimer une ancienne ligne détruirait précisément la mémoire qui empêche une réutilisation dangereuse.

Chaque politique remet un reçu différent

La taxonomie vient de RFC 2434, que RFC 5226 a remplacé avant d’être lui-même remplacé.

First Come First Served vérifie principalement que la demande est complète et non dupliquée ; il n’effectue pas d’examen technique substantiel. Expert Review ajoute un jugement selon le contrat du registre. Specification Required exige aussi une spécification publique, stable et assez détaillée pour des implémentations indépendantes. RFC Required impose un RFC, mais pas nécessairement un RFC du flux IETF ni un statut Standards Track. IETF Review requiert le chemin du flux IETF.

Une attribution ne devient donc pas un label universel de qualité. Elle prouve qu’une procédure particulière a accepté un objet particulier. Elle ne démontre pas que le produit est sûr, que deux implémentations interopèrent réellement, que le mécanisme est déployé ou que son résultat opérationnel est bon.

La doctrine de Lu Heng empêche ce glissement. The Multi-Stakeholder Mirage sépare la participation du pouvoir d’autoriser. Minimum Initial Specification défend un socle commun minimal et des décisions futures localisées. When the Bookkeeper Auditions for Olympus refuse que le teneur du livre s’élève au-dessus de sa fonction. Running-Code Primacy garde une distance entre inscription, code et réalité observée.

Le paradoxe est simple : l’expert conserve d’autant mieux sa légitimité que sa compétence reste enfermée dans une règle visible.

Sources

  1. RFC 5226
  2. RFC 5226, texte brut
  3. RFC 5226 sur Datatracker
  4. Statut de RFC 5226
  5. Historique de RFC 5226
  6. Errata de RFC 5226
  7. RFC 8126
  8. RFC 8126, texte brut
  9. RFC 8126 sur Datatracker
  10. Statut de RFC 8126
  11. Historique de RFC 8126
  12. Errata de RFC 8126
  13. Guide IANA pour les auteurs
  14. Formulaires de registre IANA
  15. État IANA review du Datatracker
  16. RFC 7120
  17. RFC 2026
  18. RFC 2418
  19. RFC 2434
  20. RFC 3935
  21. RFC 7282
  22. Lu Heng — The Multi-Stakeholder Mirage
  23. Lu Heng — Minimum Initial Specification
  24. Lu Heng — When the Bookkeeper Auditions for Olympus
  25. Lu Heng — Running-Code Primacy