Résumé
- La révision 09 de
draft-ietf-sidrops-rtr-yang, datée du 7 septembre 2026, ajoute un intervalle de rafraîchissement distinct, des compteurs de Serial Query et Reset Query, des compteurs Router Key et ASPA ainsi que cinq catégories récentes d’Error Report. - Ces ajouts rendent la frontière entre routeur et cache plus observable. Ils n’établissent ni la partie responsable d’un échec, ni l’effet sur la politique de routage, ni la durée d’un impact sur le trafic.
- Les feuilles sont un état opérationnel en lecture seule. La RFC 8342 décrit les statistiques d’état système comme transitoires : interroger plus tard l’équipement ne remplace pas un historique conservé.
- Deux implémentations sont citées, mais chacune se réfère au draft-03 et porte la date du 30 mars 2026. Le texte ne prouve pas la prise en charge des nouvelles feuilles de la révision 09.
- Daniel Kade propose un reçu d’état du cache lié à la révision, avec date de collecte, époque de remise à zéro, contexte de session et de numéro de série, temporisations, deltas d’erreurs et action de l’opérateur. C’est une proposition éditoriale, pas une exigence du projet.
Une coupure, plusieurs consignes
Un tableau de bord extérieur peut peindre en rouge toute session interrompue entre un routeur et un cache. Le protocole RPKI-to-Router en préparation distingue pourtant l’échec de transport, le redémarrage et l’arrêt du cache.
Le cache annonce un redémarrage lorsqu’il prévoit une indisponibilité mais compte revenir avant l’expiration des données chez ses clients. Un arrêt demande au contraire aux routeurs de purger les données apprises auprès de ce cache. Un blocage prolongé du transport peut donner lieu à un rapport spécifique et à la fermeture de la session. Ces événements ont des effets différents avant même que le réseau applique sa politique locale aux données RPKI.
Les temporisations déterminent ce qui reste possible. Le Refresh Interval règle l’interrogation normale, le Retry Interval la nouvelle tentative après échec et l’Expire Interval la durée maximale d’utilisation des données déjà reçues sans nouvelle synchronisation réussie. Une connexion perdue peut donc coexister avec des données encore temporairement utilisables. Le simple état « cache indisponible » ne suffit pas.
La révision 09 du projet YANG de SIDROPS met davantage de cette frontière en données structurées. C’est l’événement à rapporter. Il ne constitue pas la preuve d’un incident réel.
La révision sépare intervalle et échéance
La comparaison entre les versions 08 et 09 introduit refresh-interval, exprimé en secondes entre deux Serial Queries périodiques. Parallèlement, refresh-time reçoit une définition plus précise : il indique le moment, en centièmes de seconde, auquel le prochain rafraîchissement doit avoir lieu.
Cette nuance évite de confondre une règle et son état courant. L’intervalle vient de la politique communiquée par le cache ; l’échéance dépend du dernier échange observé par l’équipement. Une valeur isolée, sans date, ne permet pas de savoir si le routeur a suivi la règle ou recalculé son prochain passage après une interruption.
Le modèle ajoute aussi des compteurs explicites pour Serial Query et Reset Query. Le premier demande les changements postérieurs à un numéro de série connu ; le second réclame l’ensemble actif. Une hausse des Reset Queries peut signaler un chemin de resynchronisation distinct du fonctionnement incrémental normal. Des compteurs Router Key et ASPA rendent également visibles les nouvelles classes de données du protocole Version 2.
Enfin, l’arbre des erreurs adopte le vocabulaire complet des nouveaux codes : liste de fournisseurs ASPA invalide, transport défaillant, ordre incorrect, redémarrage et arrêt du cache. Les descriptions existantes sont rattachées plus clairement aux codes des Error Report. Le modèle couvre ainsi les codes 0 à 13.
Un libellé ne devient pas pour autant un jugement. Le compteur ASPA ne dit pas qu’une liste erronée a atteint la sélection des routes. Le compteur Reset Query ne donne pas la cause de la resynchronisation. Celui du redémarrage ne prouve pas le retour du cache avant l’expiration.
Tout compteur a besoin d’un commencement
Le projet parle de rapports d’erreur « échangés » avec le cache. Il ne sépare pas, pour ces compteurs, les messages envoyés des messages reçus. Même exacte, la valeur n’attribue donc pas la faute.
Elle ne porte pas non plus sa propre origine temporelle. Quatre événements peuvent signifier quatre depuis le démarrage du châssis, depuis la relance d’un processus, depuis une carte remplacée ou depuis l’arrivée du collecteur. Le type YANG est un compteur démarrant à zéro ; il ne crée pas un journal immuable.
La distinction est cohérente avec les normes de gestion. La RFC 7950 marque par config false les sous-arbres d’état. La RFC 8342 décrit l’état système, y compris les statistiques collectées, comme transitoire et modifié par les composants internes ou les systèmes voisins. L’état opérationnel est précieux pour savoir ce que l’équipement utilise maintenant ; il ne raconte pas automatiquement ce qu’il utilisait hier.
Chaque prélèvement devrait donc conserver la version du module, l’heure, le succès ou l’échec de la collecte, l’époque de remise à zéro, l’identité bornée de la session et du cache, la version du protocole, l’identifiant de session, les numéros de série, le dernier End of Data et les échéances Refresh, Retry et Expire. Sans cela, deux valeurs ne sont pas forcément comparables.
Le code en fonctionnement garde un numéro de version
La présence d’une section consacrée aux implémentations est une bonne discipline. Elle cite Juniper Networks (HPE) et New H3C Technologies. Mais ses limites sont explicites : les deux fiches mentionnent Draft-03, ont été mises à jour le 30 mars 2026 et ne donnent aucune expérience particulière.
Elles prouvent que des équipes ont déclaré travailler sur une ancienne version du modèle. Elles ne montrent pas que les nouvelles feuilles de la révision 09 sont disponibles, interopérables, activées par défaut ou déployées. Supprimer le numéro de version d’une phrase sur le « support » ferait disparaître l’information la plus importante.
Le statut institutionnel doit rester aussi précis. Le Datatracker présente le texte comme un Internet-Draft actif du groupe SIDROPS, destiné au Standards Track. Son état IESG est I-D Exists, aucun document shepherd n’est indiqué et le consensus boilerplate reste inconnu. La prise en charge par un groupe de travail compte, mais ne transforme pas encore le projet en RFC ni en norme approuvée.
Sources
- Fiche IETF Datatracker
- Projet YANG RPKI-to-Router, révision 09
- Projet YANG RPKI-to-Router, révision 08
- Comparaison IETF des révisions 08 et 09
- Protocole RPKI-to-Router Version 2, révision 27
- RFC 8210 : protocole RPKI-to-Router Version 1
- RFC 8342 : architecture des datastores de gestion
- RFC 7950 : YANG 1.1
- Heng Lu : Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
- Heng Lu : Running Code Primary
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance

