Résumé

  • La RFC 5249 confie aux modèles externes la partie évolutive des exigences documentaires, afin d’éviter que les auteurs recopient un précédent déjà périmé.
  • Les trois URL historiques testées renvoient aujourd’hui vers la même page générale d’aide aux auteurs ; cette redirection établit un trajet web, pas l’identité du modèle MIB XML, commenté ou nu demandé au départ.

L’audit commençait par un fichier introuvable

L’équipe affirmait avoir suivi le modèle officiel. Le document avait les bonnes rubriques, un bloc de sécurité, des considérations IANA et une MIB qui ressemblait aux textes publiés. L’auditeur posa pourtant une question élémentaire : « quel fichier exact avez-vous ouvert ? »

La réponse était une URL. Elle fonctionnait. Mais la requête vers le modèle XML MIB, celle vers la version texte accompagnée de conseils et celle vers la version sans conseils terminaient toutes sur la même page générale Templates and schemas. Aucun des trois corps récupérés ne portait le nom de l’artefact demandé.

On pouvait prouver l’accès à une ressource IETF. On ne pouvait plus, avec cette seule preuve, reconstituer le modèle utilisé. La différence paraît administrative. Elle touche pourtant l’autorité même de la revue : un modèle contient non seulement des titres, mais des avertissements et des rappels qui orientent les décisions de l’auteur.

La RFC a volontairement déplacé ce qui devait bouger

La RFC 5249, publiée comme BCP 139 en 2008, part d’un défaut concret. Les rédacteurs utilisaient souvent un ancien document MIB comme point de départ. Or le texte publié restait figé pendant que le boilerplate et d’autres obligations évoluaient. Un précédent pouvait être impeccable à sa date et faux comme modèle plusieurs années plus tard.

La réponse des MIB Doctors fut de maintenir trois modèles : une source XML2RFC annotée, une version texte avec conseils et une version texte épurée. Le BCP indique que certains MUST présents dans les conseils correspondent à des exigences de l’IESG et qu’ils seront contrôlés. Il prévoit aussi des mises à jour occasionnelles pour suivre les exigences courantes.

La norme ne contient donc pas tout le comportement de la chaîne. Elle délègue une partie de l’état présent à un artefact extérieur. C’est une bonne architecture si la délégation reste observable : propriétaire, version, historique, emplacement autoritatif et règle de migration.

Sans ces reçus, « conforme à la RFC 5249 » mélange deux faits. Le premier est stable : le BCP recommande un modèle entretenu plutôt qu’un ancien RFC. Le second est temporel : tel fichier constituait la révision autoritative au jour de la rédaction. Seul le premier est contenu dans le RFC.

Une redirection transporte une requête, pas une autorité

La page OPS actuelle énumère encore les trois variantes et mentionne des modèles mis à jour en juin 2013. Les trois liens historiques obtiennent un succès HTTP après redirection vers la page générale des ressources pour auteurs. Cette destination propose d’excellents modèles RFCXML génériques, ainsi que des chemins Markdown et Asciidoc. Elle avertit même qu’un RFC XML préparé ne doit pas servir de modèle de draft, car des données y sont durcies par l’outil.

Rien dans la réponse capturée ne la désigne toutefois comme la version MIB spécifique des trois fichiers. Il serait excessif d’en conclure à une disparition définitive ou à un retrait volontaire. Une autre route officielle peut exister. Le fait établi est plus étroit : l’ancienne adresse ne livre plus, à elle seule, l’identité annoncée.

Il faut enregistrer le point de départ, les sauts, l’URL terminale, l’heure, le type de contenu et le hash. Ensuite seulement vient la question sémantique : une source autoritative affirme-t-elle que la destination remplace le modèle nommé ? Un code 200 répond à la première question. Il est muet sur la seconde.

Le document et le module ont des chaînes de preuve distinctes

La RFC 5249 évite une autre confusion : ses modèles organisent le document autour de la MIB, mais ne sont pas le modèle de la MIB elle-même. Elle recommande de développer le module séparément, puisque les outils de validation ont généralement besoin de l’extraire, puis de l’inclure dans le texte environnant.

Une revue sérieuse conserve donc quatre résultats : la règle éditoriale courante, le modèle exact du document, la validation outillée du module séparé et la lecture humaine. Une bonne structure ne compile rien. Une compilation réussie ne garantit pas des DESCRIPTION compréhensibles. Un titre « Security Considerations » ne démontre pas que les objets lisibles sensibles et les objets inscriptibles dangereux ont été analysés.

La RFC 4181 insiste sur ce dernier point. Elle exige les versions approuvées les plus récentes du boilerplate et du modèle de sécurité, mais refuse la copie aveugle. Elle recommande les compilateurs tout en rappelant que la syntaxe n’est qu’une partie du travail : un lecteur doit décider si le module permet réellement des implémentations interopérables.

L’automatisation peut signaler une rubrique absente, un marqueur restant ou une référence mal formée. Elle ne peut pas décider à la place de l’auteur pourquoi une écriture modifie le trafic, pourquoi une lecture révèle une donnée privée ou pourquoi une hypothèse de contrôle d’accès est crédible.

L’apparence familière est une preuve faible

La RFC 7367 remercie explicitement l’auteur du modèle, et la RFC 9349 montre que les documents MIB ont continué à paraître bien après 2013. Ces éléments établissent une filiation et une pratique. Ils ne donnent pas le hash du fichier utilisé, la version de ses commentaires ni le chemin de redirection observé par un autre auteur.

La ressemblance est particulièrement trompeuse dans la maintenance. Un document ancien semble rassurant parce qu’il a déjà franchi la publication. C’est précisément le comportement que la RFC 5249 voulait corriger. Le précédent est une photographie validée dans son contexte ; il n’est pas un flux de politique courante.

Le modèle doit être traité comme une dépendance de construction. Pour une revue donnée, on le fige. Lorsqu’il change, on calcule la différence et on décide quelles parties du draft doivent être revues. L’URL lisible par l’humain peut rester mobile, mais la preuve doit pointer vers un objet immuable.

Quatre reçus valent mieux qu’un badge « conforme »

Un petit manifeste suffit : identifiants des politiques ; nom, révision, origine, date et hash du modèle ; chaîne de redirection ; hash du module extrait ; version du validateur ; sortie et exceptions ; objets couverts par l’analyse de sécurité ; identité et décision du relecteur.

Ce manifeste n’affirme pas que tout résultat sera correct. Il rend les erreurs localisables. Si une règle évolue, on ne recompile pas au hasard. Si l’outil change, on ne réécrit pas le raisonnement de sécurité. Si le module change, on ne prétend pas que la présence des mêmes titres conserve la validation.

La doctrine de réalité de Heng Lu éclaire la limite : le nom institutionnel d’une couche ne lui confère pas l’autorité de la couche suivante. Un modèle coordonne la rédaction. Un validateur observe des propriétés du module. Un expert juge le sens. L’implémentation et l’exploitation produisent encore d’autres preuves. Aucun voyant ne doit absorber les autres.

Sources