Résumé

  • draft-sparysh-pala-audit-00 a été annoncé le 3 septembre 2026. Datatracker le classe comme Internet-Draft individuel actif, sans approbation ni statut formel de l’IETF, sans flux RFC et sans Area Director responsable.
  • Le texte présente PALA-1 comme un format filaire existant, figé en version 1.0. Le projet Palimpsests avait effectué ce gel le 9 août, avant le dépôt à l’IETF.
  • Le draft recense cinq implémentations, tout en séparant l’implémentation de référence des auteurs des quatre reproductions fondées sur le texte et sur des vecteurs fournis par le projet.
  • Une exécution ultérieure contre le tag v1.0 a relevé des ambiguïtés et une lacune d’appariement des spans. Le draft parle d’une modification de la spécification après le gel, sans signaler de changement du wire format ou des vecteurs.
  • Un reçu de gel et de disposition devrait identifier l’objet figé, l’autorité du projet, l’état IETF, la classe du changement, son décideur et ses conséquences pour les anciens lecteurs et rédacteurs.

La date du gel n’est pas celle d’une décision IETF

L’annonce de l’IETF du 3 septembre rend public PALA-1: A Tamper-Evident Audit Record Format for Constrained and Disconnected Deployments. La fiche Datatracker empêche une première confusion : n’importe qui peut soumettre un I-D, et celui-ci n’est ni approuvé par l’IETF ni doté d’un statut formel dans son processus de normalisation. À la clôture de cette enquête, aucun flux RFC ni Area Director responsable n’était indiqué ; l’état IESG se limitait à « I-D Exists ».

L’en-tête du document vise le statut Informational, tandis que la synthèse Datatracker n’enregistrait aucun intended RFC status. Cette divergence de métadonnées ne crée aucun mandat. Le guide du RFC Editor rappelle qu’un I-D est un document de travail et que sa publication ne préjuge ni de son approbation ni de sa transformation en RFC. Même une adoption future par un Working Group ne serait qu’une étape avant de nouveaux examens et révisions.

Le gel relève d’une autre chronologie. Le 9 août, le commit 50b47edb1ed8 de Palimpsests a fait passer la spécification de Draft à « Frozen — v1.0 ». La promesse porte sur le format filaire : le modifier impose un nouveau format_version, tandis que les profils peuvent continuer à allouer des éléments dans leurs espaces propres. Le draft de septembre assume cette antériorité : il décrit un format existant et ne prétend pas le réviser.

Une équipe peut parfaitement stabiliser un format avant de le soumettre à une communauté de normalisation. La prudence consiste à ne pas convertir ce choix local en résultat institutionnel. Le projet possède sa promesse de compatibilité. L’IETF conserve, de son côté, la liberté et les procédures nécessaires à l’examen.

Le code rend le gel vérifiable, pas souverain

La section Implementation Status décrit cinq implémentations : le code de référence des auteurs, une implémentation d’un co-mainteneur sous une frontière de contamination déclarée, puis trois travaux réalisés par des personnes extérieures au projet au moment de leurs essais. L’une d’elles a rejoint ensuite la maintenance.

Le texte résiste à la tentation du chiffre publicitaire. Les quatre travaux autres que la référence ont été écrits à partir de la spécification, sans accès à une implémentation antérieure, puis comparés aux vecteurs du projet. Le draft dit expressément qu’il ne s’agit pas de vecteurs indépendants. Il documente aussi les écarts, les corrections et les limites. Le lecteur peut ainsi distinguer une reproduction du texte, une interopérabilité entre produits et un déploiement de production — trois preuves qui ne valent pas la même chose.

Cette méthode illustre utilement la primauté du code qui fonctionne. Une phrase apparemment claire devient un problème observable lorsque deux vérificateurs classent différemment la même anomalie. Le dossier de vérification ne demande pas de croire l’auteur ; il permet de confronter le texte à des sorties reproductibles.

Le RFC 7942 donne précisément cette fonction aux sections Implementation Status. Elles peuvent signaler maturité, couverture, compatibilité de versions, licence et expérience d’interopérabilité. Les groupes de travail restent libres d’apprécier ces informations. Leur présence n’implique pas l’approbation de l’IETF, et la section, dépendante du temps, doit normalement disparaître avant la publication d’un RFC.

Une découverte postérieure au gel change la question

Le cinquième run est le meilleur test de gouvernance. D’après le draft, son auteur, alors extérieur au projet, a travaillé contre le tag pala1-v1.0, réussi les essais annoncés et ajouté treize cas adverses. Il a néanmoins consigné huit ambiguïtés et une lacune : la spécification disait qu’un crash devait laisser un span visiblement ouvert, sans définir le contrôle d’appariement qui produirait cette visibilité.

La disposition a choisi un résultat consultatif. Un trail interrompu peut être incomplet sans être falsifié ; le span non apparié est donc signalé sans devenir automatiquement une violation de chaîne. Le draft présente ce run comme celui qui a changé la spécification après le gel et affirme que la conclusion et son raisonnement sont publics.

Ce passage ne démontre pas une modification des octets. Il démontre pourquoi un gel doit nommer son objet. Une clarification, un diagnostic supplémentaire, une règle sémantique, un profil et un changement de wire n’ont pas le même effet. Des vecteurs identiques peuvent coexister avec une interprétation plus précise. À l’inverse, un changement de champ peut casser un ancien parser même si son intention reste la même.

Sans registre de disposition, le débat se réduit vite à deux caricatures : « le moindre texte modifié prouve que rien n’était figé », ou « les octets n’ont pas changé, donc aucun sens n’a changé ». La question opératoire est plus étroite : quel élément a changé, qui l’a classé et quelle action attend-on d’une implémentation v1 ?

Le noyau commun peut rester mince

La spécification du projet définit notamment un header fixe de 156 octets, des extensions TLV, des types d’enregistrement et une chaîne de hachage. Lorsqu’un vérificateur rencontre une version, un type ou un TLV inconnu, il doit continuer à vérifier la chaîne, indiquer que l’élément est ininterprétable et ne pas rejeter l’ensemble pour ce seul motif.

Un squelette de parsing conserve ses offsets dans les versions futures : magic, numéro de version, longueurs, type, séquence, boot ID, hash précédent et digest du corps. Ce gel permet à un lecteur ancien de retrouver la prochaine limite et de vérifier la chaîne. Il ne fige pas toutes les significations pour toujours.

Les profils forment une couche différente. Ils fixent le sens des corps EVENT, les mesures agrégées, la source des feuilles Merkle et le vocabulaire des rôles. Une chaîne suit un profil indiqué par la documentation du déploiement. Le choix illustre une spécification initiale minimale : centraliser uniquement ce que l’interopérabilité exige, puis laisser les décisions de domaine près de leurs opérateurs.

PALA-1 applique la même retenue à ses preuves. Il distingue cohérence interne, complétude face à un ancrage et existence face à un témoin. Une chaîne cohérente ne prouve pas l’honnêteté de l’enregistreur. L’aveu renforce la frontière du format : il promet ce que ses mécanismes peuvent livrer, pas une vérité ou une autorité universelle.

Un reçu de disposition, pas une seconde bureaucratie

Le registre proposé peut rester court. Pour le gel, il conserve le commit, le tag et les hashes des vecteurs, l’auteur de la décision, sa date, le test de sortie et les questions encore ouvertes. Il qualifie l’objet : wire bytes, squelette de parsing, sémantique normative, profil, guide d’implémentation ou artefact de test.

Pour chaque remarque ultérieure, il retient un identifiant stable, la révision examinée, la section touchée et une classe : éditoriale, interprétative, sémantique, profil, extension additive, vecteur corrigé ou incompatibilité filaire. La disposition indique le rôle qui tranche, son motif et le résultat : aucune modification, clarification, avis, révision de profil, extension, note de compatibilité, nouvelle version ou report.

L’effet concret est obligatoire. Un lecteur v1 retrouve-t-il les limites ? Vérifie-t-il la chaîne ? Un writer v1 reste-t-il conforme ? Un profil doit-il changer de version ? La correction est ensuite ajoutée à l’historique au lieu d’effacer la décision initiale.

Les états institutionnels restent sur une ligne séparée : I-D individuel, discussion dans un lieu nommé, adoption WG, consensus, approbation IESG et RFC. Un mainteneur peut engager son projet sans parler au nom de l’IETF. Un Working Group peut examiner le format sans posséder la base installée du projet. Un opérateur peut adopter volontairement v1 sans prétendre appliquer une norme IETF.

Le RFC 2026 associe mise en œuvre et essais à la qualité technique, la clarté, l’ouverture, l’équité et l’examen répété. Le code n’est donc ni un décor ni un veto. Il alimente un processus dont les actes d’autorité restent distincts.

La lecture de Heng Lu complète ce partage : figer le minimum commun, éprouver les mots par le code, garder les choix futurs au niveau local quand ils ne brisent pas l’interopérabilité, et ne pas confondre adoption volontaire et mandat. PALA-1 peut ne jamais avoir besoin d’un wire v2, ou un examen futur peut en révéler la nécessité. Aucune conclusion n’est disponible aujourd’hui. En revanche, le mot frozen ne devrait jamais remplacer à lui seul l’identité de l’objet, la compatibilité et l’autorité.

Sources

  1. Annonce de l’Internet-Draft
  2. IETF Datatracker : fiche PALA-1
  3. IETF Datatracker : historique
  4. Archive IETF : draft version 00
  5. Spécification PALA-1 du projet
  6. Commit de gel 50b47edb1ed8
  7. Dossier d’independent verification
  8. Vecteurs d’essai PALA-1
  9. Archive des independent runs
  10. RFC 7942 : Improving Awareness of Running Code
  11. RFC 2026 : The Internet Standards Process
  12. RFC Editor : How RFCs Are Created
  13. Heng Lu : Running-Code Primacy
  14. Heng Lu : Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption