Résumé

  • Le 29 août, deux liens sans extension vers les procès-verbaux AVTCORE et MMUSIC de l’IETF 84 ne donnaient pas accès aux documents, alors que les fichiers figuraient dans une copie obtenue par rsync.
  • L’IETF a élargi la liste d’extensions testées par le serveur aux variantes PDF, HTM et à d’autres formats présents dans les données historiques ; le 6 septembre, les deux adresses répondaient de nouveau.
  • L’existence d’un fichier, son accessibilité publique, l’identité exacte de l’objet renvoyé et l’intégrité de ses octets constituent quatre garanties différentes.
  • Un manifeste lisible par machine devrait associer chaque pièce à un identifiant stable, un chemin concret, un format, une taille, une empreinte, un état de version et la date du dernier contrôle.
  • Le manifeste n’accorderait aucune autorité supplémentaire au contenu : il documenterait seulement ce que l’archive sert et comment une correction ou un remplacement s’inscrit dans son histoire.

Le navigateur ne voyait plus ce que le miroir conservait

Jörg Ott a décrit le 29 août une anomalie très concrète : depuis les actes de l’IETF 84, les pointeurs vers les procès-verbaux d’AVTCORE et de MMUSIC ne ramenaient pas les documents. D’autres groupes choisis au hasard fonctionnaient. Dans son signalement, il proposait de vérifier automatiquement les liens et mentionnait aussi une réponse Cloudflare 1015 rencontrée depuis une connexion mobile distante et médiocre.

Le constat portait sur l’expérience du lecteur. Il n’établissait ni suppression ni altération. Carsten Bormann a regardé l’autre côté du problème : sa copie rsync des actes contenait des fichiers pour les deux séances, au sein d’un ensemble local annoncé à 68 Go. Pour ces deux cas et cette copie, la conservation et l’accès web avaient donc divergé. Rien ne permet pour autant d’extrapoler à tous les fichiers historiques ou d’affirmer une continuité parfaite des octets.

Dans un message complémentaire, Ott a rapproché le défaut des suffixes PDF et HTM. Le 2 septembre, le personnel de l’IETF a expliqué le mécanisme : les anciennes pages renvoyaient vers des noms de procès-verbaux dépourvus d’extension, et le serveur n’essayait qu’un jeu limité de suffixes. La configuration a été étendue aux variantes observées dans les données, dont .pdf et .htm. Les deux cas signalés, ainsi que plusieurs autres, devaient alors fonctionner.

La même réponse précisait que la limite de débit était jugée assez haute pour être rarement atteinte par une navigation normale et demandait le Ray ID Cloudflare en cas de récidive. Cette précision ne dément pas l’erreur 1015 observée. Elle interdit surtout d’en tirer le récit d’une panne générale : défaut de résolution et limitation d’accès sont deux diagnostics distincts.

Une réponse 200 ne dit pas encore quel objet a répondu

Lors d’un contrôle volontairement limité le 6 septembre, l’adresse sans extension des minutes AVTCORE a renvoyé un PDF de 242 140 octets, avec une date Last-Modified de 2012. Son empreinte SHA-256 observée était 937e224285a7eae6bf1cbeb9106e5eb0bf4df7b34bf02a10587f6da9ef4e49e1. Celle des minutes MMUSIC a renvoyé du HTML, également daté de 2012, avec l’empreinte 88a6f5fd2d5459bfa1c66dc7d24b54e441a4e05507e009adf99409486c19a214.

Ces valeurs sont des observations datées, pas des certificats éternels. Des chemins directs terminés par avtcore.html ou mmusic.html répondaient eux aussi, mais leur contenu et leur date différaient : il s’agissait de pages de groupe, pas des procès-verbaux. Deviner une extension à partir d’un nom logique peut donc conduire vers le mauvais objet tout en produisant une page parfaitement lisible.

L’index des actes de l’IETF 84 reste une interface humaine. La recherche de suffixe lui permet de conserver les anciens liens sans retoucher chaque page. Elle ne suffit pas à répondre à quatre questions : le fichier existe-t-il quelque part ? est-il accessible publiquement maintenant ? la réponse correspond-elle au bon procès-verbal ? les octets correspondent-ils à la version déclarée ?

La réparation a amélioré la deuxième réponse. La copie de Bormann éclaire la première. Le type de média, la taille et les empreintes relevées donnent des éléments pour les deux dernières. Aucun de ces indicateurs ne juge la fidélité du procès-verbal à la réunion ni sa validation par la procédure de l’IETF.

La mémoire procédurale a elle aussi un cycle de vie

Selon le RFC 2418, chaque séance d’un groupe de travail doit faire l’objet d’un compte rendu, le président doit veiller à sa production et les archives publiques des listes participent à la trace du travail. Le texte recommande également de résumer et d’archiver les décisions importantes et leur historique. Une pièce introuvable par son lien ordinaire affaiblit donc l’accès à la mémoire de la procédure, même si elle survit sur un miroir.

Les consignes actuelles aux présidents rendent obligatoire le dépôt des procès-verbaux, indiquent les formats acceptés et distinguent la période de dépôt de celle des corrections. Un rappel du Secrétariat pour l’IETF 126 recensait, avant la date limite du 14 août, des séances encore dépourvues de minutes et fixait une échéance de correction au 8 septembre. Ce relevé intermédiaire ne permet pas de conclure à l’état final. Il montre que « pas encore déposé », « reçu », « publié », « corrigé », « remplacé » et « accessible aujourd’hui » ne sont pas des synonymes.

Un manifeste minimal, versionné et public

Pour chaque pièce, le manifeste proposé indiquerait le numéro de réunion, le groupe ou la séance, la nature du document et un identifiant logique stable. Il associerait cette identité à un chemin d’objet précis, un type MIME, une taille et une empreinte cryptographique. Il enregistrerait aussi les dates de réception et de publication, la version, l’état courant ou remplacé, le lien vers la version suivante, la date du dernier contrôle réussi et l’événement de réparation ayant modifié le routage.

Une correction créerait une nouvelle version et une relation explicite de succession. Elle ne ferait pas porter silencieusement de nouveaux octets à une ancienne empreinte. Le lien destiné aux humains pourrait continuer à mener à la version courante, tandis que chercheurs et outils conserveraient la possibilité de citer et de vérifier l’objet exact.

Le manifeste ne doit contenir ni correspondance privée, ni identifiant réseau personnel, ni détail facilitant le contournement des protections. Il peut désigner un rôle de provenance lorsque cela est publiable. Surtout, il n’est ni un second procès-verbal ni un sceau de vérité. Il rend falsifiables des affirmations opérationnelles limitées.

Un audit public, lent et cadencé, pourrait alors classer les échecs : pièce absente, objet présent mais lien non résolu, mauvaise règle de résolution, format inattendu, contrôle d’accès ou limitation, empreinte différente, version remplacée, cause inconnue. Un résultat vert signifierait seulement que l’objet déclaré a été reçu avec le bon format, la bonne taille et la bonne empreinte à un moment donné.

Sources

  1. Signalement initial de Jörg Ott
  2. Carsten Bormann sur la copie rsync
  3. Précision sur les suffixes PDF et HTM
  4. Explication et réparation par le personnel de l’IETF
  5. Rappel sur les minutes de l’IETF 126
  6. Consignes IETF sur les documents de réunion
  7. RFC 2418
  8. Actes de l’IETF 84
  9. Procès-verbal AVTCORE
  10. Procès-verbal MMUSIC
  11. Lu Heng sur la primauté du code opérationnel