Résumé

  • RFC 3967 a rendu visible au dernier appel de l’IETF une dépendance normative de maturité inférieure, au lieu d’en faire une exception invisible.
  • RFC 4897 et RFC 8067 ont ensuite remplacé certaines attentes par des annotations et une marge d’appréciation de l’IESG ; aucun de ces textes ne relève le statut du document cité.

Une norme peut dépendre d’un texte utile avant que celui-ci ait atteint un statut aussi mûr. Une implémentation peut avoir besoin d’un algorithme décrit dans un RFC informatif. Un document de migration peut devoir expliquer la coexistence avec un protocole ancien. Une spécification de l’IETF peut aussi s’appuyer sur un système externe ou propriétaire que l’organisation ne peut pas simplement republier à un niveau supérieur. La question délicate n’est donc pas l’existence de la référence, mais le fait qu’un texte présenté comme norme repose, au sens normatif, sur un document dont le statut signale moins de stabilité ou de révision.

La règle générale de RFC 2026 cherchait à préserver cette distinction : normalement, une spécification sur la voie des standards ne devait pas dépendre d’un autre texte de maturité inférieure ni d’un document hors de cette voie, sauf référence à une norme d’un autre organisme. RFC 3967, publié en décembre 2004 comme BCP 97, formule l’enjeu institutionnel : ne pas laisser croire qu’une norme est plus mûre qu’elle ne l’est. La maturité n’est pas une note directe de qualité technique.

Mais une référence normative peut contenir ce qui est nécessaire à une implémentation complète ; si cette dépendance est instable, indisponible ou mal comprise, le texte principal ne se suffit pas à lui-même.

RFC 3967 reconnaissait que ces références descendantes pouvaient être nécessaires. Il prévoyait une exception visible : un document Standards Track ou BCP pouvait suivre le dernier appel normal de l’IETF, à condition que l’avis signale explicitement la référence descendante. Les commentaires de la communauté devaient être pris en compte par l’IESG. Un directeur de domaine pouvait renoncer aux avis ultérieurs uniquement pour le même document et la même version, après plusieurs mentions publiques et s’il estimait que cet usage était bien admis dans le domaine technique.

Ce mécanisme de divulgation avait une limite. Le fait de signaler la référence ne la rendait pas automatiquement acceptable. RFC 3967 déconseillait cette voie quand il convenait plutôt de faire évoluer le document cité vers la catégorie appropriée. L’exception ne transformait pas non plus le statut du texte cible : il conservait sa maturité propre. L’objectif était de montrer la dépendance et de permettre une objection avant publication, non de faire passer un écart de maturité pour un consensus.

Trois ans plus tard, RFC 4897 a rendu visible un autre coût. Son introduction évoque des retards parfois très longs et les critiques selon lesquelles la règle freinait la progression des documents. Mais il faut garder la nuance : les remerciements indiquent aussi que l’auteur doutait de certaines plaintes et présentait en partie la proposition comme un test. Il s’agit de la trace d’un débat procédural, pas d’une étude mesurant le temps perdu.

RFC 4897 a changé le traitement des références normatives vers des cibles Standards Track ou BCP déjà publiées et de maturité inférieure. Au lieu d’attendre leur promotion, l’auteur pouvait ajouter une note : le texte cible pouvait être moins stable et la raison de la référence pouvait être expliquée. L’IESG gardait la possibilité de fixer des règles imposant un délai, et la communauté pouvait encore soulever des objections pendant le cycle de vie du document. Pour les cibles hors Standards Track, la procédure de RFC 3967 continuait de s’appliquer.

RFC 4897 disait aussi qu’une promotion restait préférable lorsqu’elle était appropriée : « noter et poursuivre » n’est pas devenu la règle universelle.

En 2017, RFC 8067 a assoupli une autre étape. La mention explicite d’une référence descendante dans l’avis de dernier appel est devenue fortement recommandée, mais non obligatoire. Le directeur de domaine responsable doit toujours vérifier leur présence. Si une référence est découverte pendant le dernier appel ou l’examen de l’IESG, celle-ci décide s’il faut consulter à nouveau la communauté. Ne pas répéter l’appel ne change pas la maturité du texte cité ; une utilisation future reste soumise au processus. L’omission doit être consignée dans Datatracker.

Pris ensemble, ces trois textes BCP 97 montrent comment la charge institutionnelle s’est déplacée. RFC 3967 exposait l’écart à la communauté avant la décision de l’IESG. RFC 4897 permettait à certaines références d’avancer avec une mise en garde plutôt que d’attendre systématiquement une promotion. RFC 8067 a laissé à l’IESG le choix de renouveler ou non la consultation en cas d’oubli, sans effacer le signal de maturité ni la trace de la décision. Le système est passé d’un délai surtout procédural à une répartition plus explicite de la divulgation, de l’examen, de l’annotation et du jugement.

Ces textes ne disent pas si les publications sont devenues plus rapides en pratique, si la sécurité s’est améliorée ni à quelle fréquence l’exception a été utilisée. Ils établissent des règles et des motifs, pas une série de mesures avant-après. Le constat historique est plus limité : un système de normalisation peut admettre que les dépendances et le statut des documents n’avancent pas toujours ensemble, tout en refusant qu’une référence hérite silencieusement d’une autorité qu’elle n’a pas acquise.

Sources : RFC 2026, RFC 3967, RFC 4897, RFC 8067, RFC 7841.