Résumé

  • Le 3 septembre 2026, l’IESG a conclu que la révision 12 de Safe-IOC n’entrait pas en conflit avec des travaux de l’IETF. Cette conclusion ne vaut ni approbation technique, ni consensus de l’IETF, ni admission dans le Standards Track.
  • Les révisions 13 et 14 ont suivi. Les différences publiques montrent que plusieurs observations du ballot se retrouvent dans le texte, tandis que l’historique retrace les interventions de l’ISE, de l’IANA et de la production RFC. Il manque toutefois une décision attribuable pour chaque commentaire.
  • Un reçu « version et disposition des commentaires » devrait relier le hash de la version examinée, la réponse RFC 5742, les identifiants des commentaires, les motifs de l’ISE, les hunks de diff, les états IANA/RPC et, le moment venu, le numéro et le boilerplate du RFC.

Une conclusion attachée à la révision 12

L’annonce de l’IESG nomme précisément draft-grimminck-safe-ioc-sharing-12. Elle indique que l’IESG ne voit pas de problème à sa publication comme RFC Informational et ne constate aucun conflit avec les travaux de l’IETF. Dans une phrase distincte, elle demande à l’Independent Submissions Editor d’examiner les commentaires présents dans le ballot et l’historique du Datatracker, puis de déterminer s’ils méritent d’être intégrés.

Ces propositions ne décrivent pas un même état. La vérification du conflit est achevée pour la révision 12. Les commentaires techniques restent à apprécier par l’ISE. La voie Independent Submission peut continuer. Aucun RFC n’est encore publié.

La fiche actuelle du Datatracker affiche désormais la révision 14. Elle conserve les mentions active individual Internet-Draft, Independent Submission et intended status Informational. L’identité documentaire demeure, mais les octets et le stade de production ont changé.

RFC 5742 sépare conflit et mérite technique

Le RFC 5742 prévoit cinq réponses possibles. Celle retenue est la première et la plus étroite : aucun conflit avec des travaux de l’IETF. Le même texte précise que les documents des streams non-IETF ne cherchent généralement ni consensus de l’IETF ni approbation de l’IESG. Après un résultat sans conflit, le RFC Editor reste chargé d’évaluer le mérite technique et un éventuel préjudice pour l’Internet.

Cette séparation protège les deux institutions. L’IESG ne transforme pas un contrôle de périmètre en revue technique exhaustive. L’ISE ne remplace pas son propre jugement par une absence de conflit. « No problem with publication » signifie que ce motif ne bloque pas le stream indépendant, non que l’IETF recommande la spécification.

La question du ballot est elle aussi limitée : la réponse proposée au conflict review est-elle correcte ? À la date d’observation, deux membres ont répondu Yes et huit No Objection. Ces positions ne sont pas dix approbations de chaque règle de transformation ou de chaque affirmation de sécurité.

Des changements visibles, une disposition incomplète

Mohamed Boucadair a soutenu la réponse au conflit tout en suggérant quatre ajustements : citer le RFC 9424 sur les IoC ; éviter que le mot « safe » n’implique l’annulation du risque ; parler de préfixes lorsque le texte traite de préfixes ; et ajouter les formes IPv4 intégrées dans IPv6 décrites par le RFC 6052. Éric Vyncke a laissé une remarque plus légère sur l’importance du contenu IPv6.

La révision 13 est arrivée après l’annonce. L’historique et la comparaison 12–14 montrent des correspondances nettes : « a safe obfuscation format » devient « an obfuscation format » ; le RFC 9424 apparaît ; la terminologie CIDR parle de préfixes ; le RFC 6052 et deux vecteurs de test sont ajoutés ; Boucadair entre dans les remerciements.

On peut donc affirmer que le texte ultérieur reflète ces suggestions. On ne peut pas en déduire une fiche de disposition formelle. Le diff ne dit pas si l’ISE a accepté chaque point tel quel, l’a combiné avec une autre revue ou a retenu la modification pour un autre motif.

La révision 14 ajoute encore le terme courant « defanging », resserre la grammaire des hosts et les références au RFC 1035, abaisse deux SHOULD en conseils ordinaires et introduit un risque de récupération ambiguë lorsque Path, Query ou Fragment contient déjà des tokens entre crochets. Aucun tableau public ne relie intégralement ces changements à un identifiant de revue et à une décision acceptée, rejetée ou partiellement acceptée.

Une file de production n’est pas une publication

Le 9 septembre, la révision 14 a été déposée et l’ISE l’a envoyée au RFC Editor. L’état IANA est passé à In Progress, puis à No IANA Actions le 16 septembre. La production RFC a été brièvement bloquée pour Author Input Required avant de reprendre. L’historique RPC indique ensuite un passage de l’attente de vérification des références et de formatage à l’attente d’attribution d’un éditeur.

Le XML officiel de la file RFC Editor contient encore la révision 14 dans le stream ISE, reçue le 9 septembre, avec l’affectation ref_checker. Datatracker et la file montrent deux projections du travail ; aucune ne doit être résumée par « approuvé ». Aucun numéro RFC final n’existe à la date de coupure.

La page sur les Independent Submissions distingue les revues et révisions répétées, la décision initiale de publier, la remise au RPC, AUTH48 et la publication. L’ISE peut encore refuser de publier jusqu’à la sortie du RFC. La file prouve donc une prise en charge, pas l’existence du texte public final.

Le reçu nécessaire

Le reçu doit d’abord lier le hash exact de la révision 12 et son horodatage à la réponse RFC 5742. Chaque commentaire reçoit un identifiant stable, un auteur, un hash de texte et une origine. La décision de l’ISE devient explicite — accepté, rejeté ou partiellement accepté — avec son motif. Toute acceptation pointe vers la première révision qui l’implémente et vers le hunk exact.

Le même registre peut suivre le résultat IANA, les causes de blocage et de reprise au RPC, l’acteur responsable, le numéro RFC final, le boilerplate de stream et les futurs errata ou remplacements. Une remarque consultative doit rester consultative ; une modification née d’une autre revue ne doit pas être attribuée après coup au ballot.

Cette discipline empêche aussi une promesse excessive sur la sécurité. Une convention textuelle réversible peut réduire l’activation accidentelle. Elle ne vérifie ni la malveillance, ni l’actualité, ni l’attribution d’un indicateur. La provenance du document et celle de l’IoC restent deux preuves différentes.

Sources