Un planning YANG peut garder une autorité périmée

Summary

RFC 9922 normalise des types et groupements YANG réutilisables pour les dates, récurrences, garde-fous et états d’un planning. Il laisse volontairement hors périmètre la nature de l’action déclenchée et la résolution des conflits ; un état « enabled » ne nomme donc pas l’autorité encore compétente.
Daniel Kade propose un reçu d’autorité par occurrence, reliant version du planning, action exacte, parrain institutionnel, politique courante, principal d’exécution, heure et résultat. Il s’agit d’une règle opérateur, non d’une exigence de RFC 9922 ni du récit d’un incident connu.

L’automate conserve la date, pas forcément la décision

Un planning sert à dissocier le moment où l’on décide de celui où l’on agit. C’est ce qui permet de réserver une ressource à l’avance, de lancer une maintenance sans présence humaine ou de répéter une mesure à heure fixe. Le bénéfice disparaîtrait si chaque occurrence devait être recréée manuellement.

Mais cette dissociation produit deux chronologies. La première appartient au calendrier : création, mise à jour, prochaine occurrence, fin de validité. La seconde appartient à l’institution : changement d’équipe, modification des pouvoirs, nouvelle criticité d’une cible, retrait d’un service, remplacement d’une politique. Les deux peuvent diverger sans que le planning ne devienne invalide au sens temporel.

Une tâche peut ainsi être parfaitement fidèle à sa définition. Elle se réveille au bon instant, utilise la bonne règle de récurrence et n’entre en concurrence avec aucun autre créneau. Si le tableau de bord résume ces faits par « autorisé », il ajoute pourtant une conclusion que les données ne portent pas.

La question de gouvernance n’est pas de savoir si l’automate a obéi. Elle est de pouvoir dire quelle autorité rendait encore cette obéissance légitime lors de cette occurrence précise.

Ce que RFC 9922 appelle valide

RFC 9922, publié en mars 2026 sur la voie Standards Track de l’IETF, définit le module ietf-schedule. Le texte représente le consensus de la communauté IETF. Il fournit des types et des groupements communs pour planifier événements, politiques, services ou ressources, depuis une occurrence unique jusqu’à des récurrences proches d’iCalendar.

Le document trace soigneusement sa frontière. Il ne fait aucune hypothèse sur l’action déclenchée. Il ne règle pas la détection ni la résolution des conflits entre plannings. Son module ne publie, à lui seul, aucun nœud modifiable, aucun état opérationnel et aucune RPC. Ce sont les modules consommateurs qui emploient, affinent ou augmentent les groupements.

Cette généralité est une qualité : la même bibliothèque temporelle peut servir une alarme, un test OAM, une réservation ou une modification de configuration. Elle interdit en revanche d’attribuer au mot « validité » un sens qu’il n’a pas.

Dans generic-schedule-params, validity désigne l’instant après lequel un planning ne peut plus commencer. Une occurrence ultérieure n’est pas exécutée. Les bornes de début et de fin ainsi que l’action de rejet complètent cette validation temporelle. Ces paramètres permettent aussi d’écarter une demande périmée ou trop proche pour qu’un administrateur puisse la vérifier.

Ils ne disent pas qui a approuvé l’action, si cette personne représente encore le propriétaire du service, quelle version de politique est applicable ou si une modification de la cible exige un nouvel accord. « Encore dans la fenêtre » et « encore autorisé » sont deux propositions.

Une version n’est pas une provenance

Les groupements d’état de RFC 9922 rendent le planning observable. L’état peut être activé, désactivé, terminé, périmé ou en conflit. Une version, la dernière mise à jour, les dernières et prochaines occurrences, ainsi que les compteurs d’exécution et d’échec peuvent être exposés.

Ces informations répondent à des questions utiles : quelle définition est courante ? Quand le planning a-t-il changé ? A-t-il déjà échoué ? Quand se réveillera-t-il de nouveau ? Elles ne répondent pas à la question « au nom de qui ? »

La comparaison avec l’ancien DISMAN-SCHEDULE-MIB est éclairante. Plusieurs objets ont un équivalent YANG, mais schedOwner est marqué « Not Supported ». Cela ne signifie pas qu’un produit ne peut pas conserver de propriétaire. RFC 9922 invite justement les futurs modules à ajouter, selon le contexte, une source et une précédence lorsque plusieurs origines alimentent les plannings.

La limite démontrée est plus modeste : le propriétaire ou le parrain n’est pas un champ commun de l’état générique. Une organisation qui transforme cet état en preuve d’autorisation doit fournir elle-même la jonction manquante.

Une version 7 peut être la plus récente sans avoir été approuvée par le propriétaire actuel. last-update peut dater un changement sans identifier la décision. Un compteur d’échec peut rester à zéro alors que l’action ne devrait plus être permise.

NACM autorise une requête, pas une histoire implicite

RFC 8341 définit NACM, le modèle de contrôle d’accès pour NETCONF et RESTCONF. Une session authentifiée reçoit un nom d’utilisateur et des groupes ; les règles applicables décident des opérations et des nœuds accessibles. Le serveur doit utiliser les règles en vigueur lorsqu’il commence à traiter le message.

NACM peut donc protéger la création, la modification et la suppression d’un planning, ainsi que des actions exposées par un module consommateur. Ce serait une erreur d’affirmer que le contrôle d’accès cesse d’exister dès qu’un calendrier intervient.

Reste une frontière temporelle. RFC 8341 décrit les requêtes issues d’une session utilisateur et précise que certains accès initiés par le serveur ne sont pas contrôlés comme une telle requête. Il ne détermine pas le principal de toutes les occurrences futures. Selon l’implémentation, l’action pourra être exécutée au nom du créateur, d’un compte de service, du contrôleur ou d’un mandat institutionnel réévalué.

Le choix peut varier. Une sauvegarde récurrente doit survivre au départ de son premier administrateur. Une rotation de clé ou une préemption de ressource peut nécessiter une nouvelle décision si la cible ou le risque change. Ce qui importe est que la règle de continuité soit explicite.

Le mot « propriétaire » doit lui-même être décomposé. La personne qui a saisi la demande, l’équipe responsable du service, le principal technique et l’autorité qui approuve l’effet ne sont pas toujours le même acteur. Un reçu sérieux les sépare.

L’heure authentifiée ne signe pas le mandat

RFC 9922 fait de l’heure une dépendance de sécurité. Une horloge incorrecte peut déclencher un événement au mauvais moment. Des récurrences très fréquentes peuvent masquer un comportement anormal ou occuper le système. Sans journal détaillé de chaque heure de déclenchement et de chaque résultat, une enquête devient difficile.

RFC 3339 fixe le langage des horodatages. RFC 7317 expose la configuration de l’heure, du fuseau et de NTP dans un système géré par YANG. RFC 8915 protège la synchronisation NTP avec l’identité du serveur, l’authentification, la prévention du rejeu et la cohérence requête-réponse.

Ces standards peuvent rendre crédible la phrase « il était bien 2 heures ». Ils ne prouvent pas « l’action était encore autorisée ». Une horloge authentifiée peut déclencher exactement à l’heure un acte qui n’a plus de mandat. Inversement, un acte légitime peut partir au mauvais moment à cause d’une dérive temporelle.

Le tableau de contrôle doit donc garder deux colonnes : preuve du temps et preuve de l’autorité. Leur fusion sous un voyant vert empêche de savoir laquelle a cédé.

La réservation future révèle l’écart

RFC 8413 présente l’usage programmé de ressources d’ingénierie de trafic. Une demande future peut être calculée aujourd’hui et réserver de la capacité, alors que le LSP ne sera établi qu’au début de sa fenêtre. Le cadre demande de corréler le futur LSP et la réservation afin d’expliquer pourquoi la ressource est bloquée, de gérer la préemption et de libérer après annulation. La politique opérateur reste déterminante.

RFC 8934 fournit les extensions PCEP pour la création, la modification, l’activation et la suppression programmées d’un LSP. Une base conserve le LSP prévu ; au début, le PCC lance l’établissement, puis peut retirer le LSP à l’expiration. La demande, le calcul, la synchronisation et l’acte réel se produisent à des instants distincts.

Ces textes ne décrivent pas une panne d’autorisation. Ils montrent un endroit où elle doit être définie. La capacité peut encore être disponible et le chemin satisfaire ses contraintes alors qu’une commande client a été annulée ou que le service a changé de responsable. La disponibilité n’est pas un mandat.

Le reçu d’autorité d’occurrence

La réponse proportionnée n’est pas de charger le module générique d’une politique universelle. Elle consiste à créer, là où un planning est relié à une action importante, un reçu compact pour chaque occurrence ou pour une série bornée d’occurrences équivalentes.

Ce reçu relie :

l’identifiant stable, la version et l’empreinte exacte du planning ;
l’occurrence, l’heure prévue et l’heure observée ;
la classe d’action et la cible, avec engagements cryptographiques pour les valeurs sensibles ;
le créateur et le parrain institutionnel actuel ;
la base d’autorisation initiale et la version de politique ou de délégation courante ;
le principal d’exécution et la décision actuelle d’autoriser ou de refuser ;
la source temporelle et son incertitude utile ;
la résolution de conflit, de précédence ou de préemption ;
l’état visé, l’état appliqué et le résultat observé ;
la raison d’un échec, d’une annulation ou d’une non-exécution volontaire ;
les liens de remplacement et de correction.

Il n’est pas nécessaire de demander un clic humain à chaque minute. Une décision signée peut couvrir un type d’action, un ensemble de cibles, un plafond de risque et une plage d’occurrences. Elle doit cesser d’être réutilisable lorsque changent la version, le parrain, la cible, la politique ou l’effet demandé.

Le reçu public n’a pas à exposer les identités personnelles, la topologie ou le contenu de configuration. Il peut publier une classe de parrain, un identifiant de politique, des empreintes, un gardien et une disposition, tandis que les détails restent dans une preuve protégée.

Les objections fixent la bonne granularité

La continuité est la première objection. Un service institutionnel ne doit pas s’arrêter à chaque mobilité interne. Justement : le transfert vers un rôle durable doit être déclaré, daté et borné, au lieu de dépendre du maintien silencieux d’un ancien compte.

Le coût vient ensuite. Réévaluer une politique complexe à chaque seconde serait excessif. Un bail d’autorisation mis en cache peut couvrir des occurrences homogènes. Son périmètre et ses déclencheurs d’invalidation doivent rester visibles.

La duplication est une troisième objection. NACM, l’orchestrateur et la plate-forme d’audit possèdent peut-être déjà les données. Le reçu peut les joindre au lieu de les recopier. Le test est simple : un tiers habilité peut-il relier l’occurrence, le planning, le principal courant, la politique et le résultat sans recourir à la mémoire orale ?

Enfin, RFC 9922 est volontairement générique. C’est exact. Le reçu appartient au module consommateur ou à sa couche d’assurance. Respecter ce partage vaut mieux que reprocher au calendrier de ne pas connaître toutes les actions possibles.

Limites de la preuve

Cette analyse porte sur des standards, non sur un parc réel. Elle ne démontre pas qu’un fournisseur ou un opérateur exécute des plannings dont l’autorité est périmée. Elle ne décrit ni incident, ni vulnérabilité, ni perte, ni violation. Elle n’établit pas que les implémentations existantes ignorent le propriétaire, le principal de service ou la réautorisation.

Le reçu proposé n’est pas une exigence de l’IETF. RFC 9922 résout un problème d’interopérabilité défini et renvoie avec raison les risques propres à l’action vers les modules qui réutilisent ses groupements.

La conclusion soutenable est étroite : un planning peut être valide et courant dans le vocabulaire temporel de RFC 9922 tandis que l’autorité de l’action qu’il déclenche demeure un fait distinct. Si l’organisation ne consigne pas ce fait lors de l’exécution, l’état « activé » finit par affirmer davantage que ce que le modèle démontre.

Un planning YANG valide ne prouve pas que son action reste autorisée

Pourquoi c'est important

Summary

L’automate conserve la date, pas forcément la décision

Ce que RFC 9922 appelle valide

Une version n’est pas une provenance

NACM autorise une requête, pas une histoire implicite

L’heure authentifiée ne signe pas le mandat

La réservation future révèle l’écart

Le reçu d’autorité d’occurrence

Les objections fixent la bonne granularité

Limites de la preuve

Sources

Contexte approfondi du profil

Strategic Circle

Leadership Alliance

Briefing du Strategic Circle

Briefing Leadership Alliance