Résumé

  • Le Datatracker indiquait zéro erreur ou avertissement YANG pour la révision 44 ; la file du RFC Editor affichait encore deux approbations absentes et un possible traitement du cluster.
  • La validation du modèle, l’approbation des auteurs, le traitement du cluster et la publication sont des preuves distinctes ; la file n’explique pas les « N » et ne prédit pas de date.

Analyse

La page fait apparaître deux états distincts. Le 16 octobre, le Datatracker affichait zéro erreur et zéro avertissement de validation YANG pour la révision 44. Le RFC Editor, le même jour, conservait le RFC-to-be 10057 au statut « In Final Review ». Son tableau comptait trois approbations d’auteurs marquées « Y » et deux encore marquées « N ». Le document appartenait aussi au cluster 517, qui pouvait comporter d’autres blocages avant publication.

Ces champs ne décrivent pas la même étape. Le résultat YANG atteste que le modèle soumis a passé les outils de validation indiqués sur la page du Datatracker, avec les dépendances mentionnées. Il ne dit pas que la procédure de publication est terminée. Selon la définition du RFC Editor, « In Final Review » signifie que le document attend une ou plusieurs approbations finales des auteurs ou des responsables. Un modèle peut donc être valide pour ces outils alors que son dossier de publication reste ouvert.

Le projet est un document technique substantiel. La révision 44 propose un modèle pour les tunnels d’ingénierie du trafic point à point, les chemins LSP et les interfaces. Elle sépare les données génériques indépendantes des équipements dans ietf-te des données propres aux équipements dans ietf-te-device. Les modèles propres aux protocoles de signalisation, comme RSVP-TE ou Segment Routing, doivent être définis à part puis compléter le modèle TE. Le numéro 10057 sert au suivi provisoire dans la file du RFC Editor ; le Datatracker le décrit toujours comme un Internet-Draft, sans numéro RFC publié.

La révision finale n’est pas un nouveau vote technique sur chaque choix d’architecture. Le RFC Editor la décrit comme une relecture par les auteurs du document édité et comme une étape d’approbation avant publication. Trois « Y » et deux « N » indiquent l’état visible du tableau ; ils n’expliquent pas pourquoi une approbation manque. La file a consigné des rappels les 7 et 14 octobre. Une note précédente indiquait que des fichiers mis à jour avaient été déposés et qu’aucune question ne restait ouverte. Cette chronologie ne prouve ni désaccord, ni problème technique, ni cause précise du délai.

La nuance est utile aux opérateurs et aux fournisseurs qui préparent leurs travaux sur la base d’un projet. Une validation réussie peut appuyer une revue de schéma. Elle ne tient pas lieu de texte normatif final, de RFC publiée, d’implémentation interopérable ou de tunnel effectivement déployé. L’état du processus constitue une preuve distincte. Si un achat, une version de contrôleur ou un profil de laboratoire dépend d’une base stable, il faut conserver la révision exacte évaluée et mettre à jour le dossier lorsque la file évolue.

Cet instantané est daté. Au 16 octobre, le tableau des approbations restait incomplet et le cluster 517 pouvait ajouter une étape. Le Datatracker affichait encore la révision 44 comme Internet-Draft, et la page d’information RFC 10057 n’existait pas au moment de la capture. Ces éléments ne prédisent aucune date de publication. La conclusion étayée est limitée : les contrôles YANG indiqués ont réussi, tandis que le processus de publication attendait encore des approbations et pouvait dépendre du traitement du cluster.