Résumé

  • L’IESG consulte la communauté sur un mécanisme qui permettrait à l’IANA de créer un registre complet avant que le texte fondateur ne soit approuvé comme RFC. Le registre serait marqué temporaire pendant deux ans, puis renouvelé, fermé ou rendu permanent.
  • Le statut du registre et celui de ses entrées peuvent suivre des calendriers différents. Un journal public des transitions doit rattacher chaque état au brouillon exact, à la chaîne d’approbation, à la procédure provisoire et à la décision qui l’a modifié.

Une date d’expiration dit quand une horloge sonne. Elle ne dit pas toujours ce qui expire.

C’est la difficulté centrale du projet Early IANA Registry Creation, placé en dernier appel par l’IESG le 27 août. Les commentaires sont attendus jusqu’au 10 septembre. Le texte vise la filière des normes, mais il reste un Internet-Draft : ni l’IESG ni l’éditeur des RFC n’en ont fait une règle définitive.

Le besoin opérationnel est compréhensible. Un groupe de travail peut concevoir un nouveau registre dans un document tandis que d’autres textes ont déjà besoin de valeurs coordonnées. Une organisation extérieure à l’IETF peut également attendre des attributions pour achever sa propre norme. Une liste informelle évite parfois le blocage, mais elle crée un registre parallèle qui risque de survivre à son remplacement. Attendre le RFC fondateur élimine cette ambiguïté au prix d’un retard dans les essais.

Le projet propose donc d’officialiser l’étape intermédiaire. L’IANA tiendrait le registre avant l’approbation du texte qui en fixera durablement l’existence. Cette solution est plus ambitieuse que l’allocation anticipée d’une seule valeur : elle installe le guichet, une règle d’admission provisoire et une responsabilité de suivi.

Une création distribuée entre quatre rôles

Les auteurs commencent par saisir les présidents du groupe de travail. Ceux-ci vérifient les conditions et évaluent l’existence d’un consensus en faveur de la création anticipée. Le directeur de zone doit ensuite approuver la demande et peut tenir compte du risque que le registre ne devienne jamais permanent. Ce n’est qu’après cette séquence que les présidents demandent l’exécution à l’IANA.

L’opérateur publierait le registre à l’emplacement prévu, avec la mention temporaire, la date de création et une échéance deux ans plus tard. Avant cette échéance, il solliciterait les présidents et le directeur de zone au sujet d’une prolongation de deux ans. Après une première prolongation, les suivantes exigeraient aussi l’accord de l’IESG, une justification et un plan pour le texte fondateur. Sans prolongation, le registre serait fermé et étiqueté comme tel. Les présidents pourraient demander une fermeture avant terme.

Le projet prévoit encore une suspension particulière de l’horloge : si le registre est valide lorsque le document est soumis à l’IESG, il ne doit pas expirer pendant cet examen. Il permet enfin à l’IANA de demander à l’IESG de suspendre le mécanisme si des problèmes de sécurité ou d’une autre nature apparaissent.

Chaque étape est bornée. Pourtant, l’interface publique décrite explicitement reste minimale : une mention, une création, une échéance. Or la légitimité se déplace par décisions successives, pas seulement par le passage du temps.

Le contenant et les lignes n’ont pas le même cycle de vie

Le projet distingue la politique envisagée pour le registre définitif de la procédure applicable pendant la période temporaire. La première est écrite dans le brouillon, mais elle ne prend effet qu’au moment de la pérennisation. Entre-temps, l’IANA applique une voie de transition choisie selon cette politique future.

Pour un registre destiné à fonctionner en « First Come First Served » ou en « Expert Review », les attributions provisoires passent par l’approbation d’un président du groupe. Le texte précise que ces attributions n’ont pas à être renouvelées. Dans un document directement parrainé, le directeur de zone joue le même rôle.

Si le registre final doit exiger un RFC — « IETF Review » ou « Standards Action », par exemple — l’entrée emprunte la procédure d’allocation anticipée du projet qui révise le RFC 7120. Une fois le registre pérennisé, l’entrée demeure temporaire tant que son propre document n’est pas approuvé. « Specification Required » introduit d’autres branches selon que les Internet-Drafts seront ou non acceptés comme spécifications permanentes.

On peut donc rencontrer un registre temporaire avec une ligne approuvée sans renouvellement, une ligne limitée dans le temps et une ligne initiale issue du texte fondateur. Puis le registre devient permanent tandis qu’une ligne continue à porter la mention temporaire. Réduire cet ensemble à un seul champ expires rendrait la lecture trompeuse.

Ce point marque aussi la différence avec le RFC 7120 actuellement en vigueur. Ce BCP organise une allocation anticipée dans un registre qui existe déjà. Le nouveau texte ouvre la possibilité de faire exister le registre lui-même avant son RFC fondateur. L’objet de la décision change.

La règle provisoire peut changer avant la fin

Le brouillon peut évoluer. Si la politique définitive projetée passe, par exemple, d’Expert Review à IETF Review, la procédure temporaire correspondante doit elle aussi changer. Le projet oblige à avertir l’IANA, tout en affirmant que l’IANA ne suivra pas elle-même les modifications des documents créateurs.

Cette répartition protège la fonction d’opérateur. L’IANA n’a pas à devenir le secrétariat éditorial de chaque groupe. Les auteurs et les présidents doivent examiner les modifications du contenu et de la structure. Mais la séparation ne fonctionne que si la notification produit une preuve consultable : version du brouillon, décision, heure d’effet, ancienne règle, nouvelle règle et entrées concernées.

Sans cette liaison, le registre public peut être à jour tout en restant inexplicable. Une valeur y figure, mais le lecteur ignore si elle a franchi un contrôle de président, une allocation anticipée, une expertise ou une règle prévue uniquement pour l’état final.

Publier les transitions, pas seulement l’état courant

Un journal à deux niveaux résoudrait ce problème sans élargir les pouvoirs de l’IANA.

Pour le registre, il conserverait un identifiant stable, le nom et l’empreinte du brouillon créateur, la trace du consensus évalué par les présidents, l’accord du directeur de zone, la demande à l’IANA, les dates de création et d’expiration, la politique finale projetée et la procédure provisoire en vigueur. Toute modification de politique ou de structure deviendrait un événement daté. Renouvellement, gel pendant l’examen IESG, demande de suspension, fermeture et pérennisation resteraient visibles au lieu d’écraser l’état précédent.

Pour chaque entrée, le journal indiquerait la valeur, le sens, la référence, le contrôleur du changement, la voie d’approbation, la version de politique et le statut temporel. Lors d’une fermeture ou d’une pérennisation du registre, la ligne dirait explicitement ce qui a changé pour elle.

Il n’est pas nécessaire de publier des échanges privés. Le rôle de l’acteur, la référence de décision, l’empreinte du document, la date et le résultat suffisent à rendre le passage vérifiable.

Ce que le registre ne transforme pas en autorité

La publication anticipée coordonne un espace de valeurs. Elle n’approuve pas à l’avance chaque technologie. Un accord de président n’est pas l’approbation finale du document créateur. Le dernier appel n’est pas une décision de l’IESG. Une ligne IANA ne certifie ni un produit ni un déploiement.

La fermeture appelle la même prudence. Le texte dit que l’IANA fermera le registre et l’étiquettera si une prolongation n’est pas approuvée. Il ne dit pas que toutes les entrées sont immédiatement supprimées ou réutilisables. Leur sort doit être lu dans la procédure applicable et, idéalement, consigné ligne par ligne.

Aucun élément examiné ne montre qu’un registre a déjà été créé avec ce mécanisme, qu’un déploiement en dépend ou qu’un acteur en a abusé. Le journal proposé est une mesure de prévoyance. Les valeurs techniques se copient facilement ; la preuve de leur caractère provisoire doit être conçue pour voyager aussi loin qu’elles.

Sources