Résumé

  • RFC 3933 a créé une voie intermédiaire : proposition écrite, Last Call de quatre semaines, RFC Experimental, périmètre limité et échéance explicite.
  • L’échéance était obligatoire, mais l’énoncé du problème, les critères d’évaluation et le document expliquant le succès ou l’échec ne l’étaient pas.

Une fermeture documentaire trois ans après la fermeture pratique

L’histoire des IETF Operational Notes montre pourquoi une date ne suffit pas à constituer un dossier. RFC 4693 proposait une série plus stable qu’une page web et plus souple qu’un RFC. L’essai devait durer douze mois à partir du premier ION. À la fin, la communauté devait choisir entre permanence, abandon ou prolongation. L’auteur estimait que des mesures objectives n’étaient pas utiles : l’attitude de la communauté rendrait le résultat visible.

L’IESG a arrêté l’expérience en mars 2008. Pourtant, ce n’est qu’avec RFC 6393, en septembre 2011, que RFC 4693 a été formellement rendu Historic et obsolète. Cet intervalle ne prouve ni dommage ni négligence. Il établit une distinction plus étroite : la fin d’une procédure et le nettoyage du statut de son document sont deux opérations. Le lecteur qui ne possédait que le RFC Experimental pouvait ignorer que l’autorité temporaire avait déjà pris fin.

Cette séparation était contenue dans le modèle de RFC 3933. Le dossier officiel le classe BCP 93. Face à la légèreté des changements informels et à la lourdeur de la procédure complète de RFC 2026, avec ses groupes encadrés par RFC 2418, il proposait de tester d’abord. RFC 1396 conservait l’arrière-plan des réorganisations de 1992 ; RFC 3933 ajoutait la possibilité d’une règle provisoire publiée.

Le parcours comprenait un Internet-Draft, une appréciation de plausibilité par l’IESG, quatre semaines de Last Call, une réponse aux objections et la publication en Experimental. Le texte devait indiquer un sunset, normalement inférieur ou égal à un an. L’erratum 209 ne corrige qu’une virgule dans cette phrase. L’essai pouvait être limité à quelques domaines ou groupes, et les décisions restaient soumises au jugement de rough consensus et aux voies d’appel ordinaires.

L’horloge était plus ferme que l’hypothèse

Le contraste apparaît dans les verbes normatifs. L’échéance devait exister. Mais la formulation du problème et les critères spécifiques étaient seulement souhaitables. À la fin, l’IESG pouvait considérer que la communauté trouvait la situation globalement meilleure ou pire. Un texte expliquant pourquoi l’essai avait réussi ou échoué était désirable, mais explicitement irréaliste comme obligation.

Cette souplesse évitait de transformer chaque essai en programme de recherche bureaucratique. Elle affaiblissait cependant la transmission de l’expérience. Une date montre combien de temps une autorité provisoire pouvait agir. Elle ne révèle pas combien de cas ont suivi la nouvelle voie, qui a supporté le coût, quels recours ont été employés, ni si le résultat venait de la règle ou d’un changement extérieur.

Les textes ultérieurs montrent que les auteurs pouvaient renforcer ce contrat. RFC 5111 a borné l’expérience des Exploratory Groups à dix-huit mois et trois groupes, puis proposé des indicateurs : jalons atteints, décision de créer un groupe de travail et activité de liste. RFC 4633 a limité à dix-huit mois des pouvoirs élargis de suspension sur les listes, interdit leur prolongation au-delà de l’essai, exigé des annonces publiques et conservé l’appel.

Une expérience pouvait aussi laisser un pont vers une BCP

La pandémie a fourni un cas différent. Les critères de RFC 8713 utilisaient la présence aux réunions comme proxy de l’engagement nécessaire au NomCom. Après des réunions entièrement distantes, RFC 8989 a ouvert un essai d’un cycle, au plus deux. Cette fois, le texte imposait une consultation des présidents du NomCom, la publication d’un rapport et une discussion communautaire. Il demandait d’examiner la taille et la diversité du vivier, la connaissance de l’IETF et la vérifiabilité mécanique des critères.

RFC 9389 a ensuite repris ces voies d’éligibilité dans BCP 10 et rendu RFC 8989 obsolète. Cela prouve une décision normative ultérieure, non que chaque effet ait été mesuré ni que l’essai ait seul causé la réforme. La différence utile tient à la trace : RFC 8989 avait rendu le rapport et les options finales partie intégrante du mécanisme.

Les essais de RFC 3933 doivent donc être lus sur trois plans. L’autorisation dit qui pouvait essayer quoi. Le sunset dit quand la permission devait être reconsidérée. Le dossier d’observation dit ce qui s’est réellement passé. Les deux premiers peuvent exister sans le troisième.

Les notes de Heng Lu sur la spécification initiale minimale et l’adoption volontaire et la primauté du code en fonctionnement fournissent ici une discipline éditoriale : publication, autorisation, usage et effet ne doivent pas s’emprunter mutuellement leur preuve. RFC 3933 a borné l’autorité temporaire. Il n’a pas garanti que l’expérience deviendrait une mémoire vérifiable.