Résumé

  • RFC 9922 fournit un vocabulaire YANG commun pour représenter des horaires et leurs statuts. last-occurrence et upcoming-occurrence portent sur la récurrence, pas sur une preuve d’effet.
  • Le RFC ne suppose pas la nature de l’action déclenchée et laisse les conflits de calendrier hors de son périmètre. L’autorisation, l’appel, l’exécution et le résultat restent des décisions et des traces distinctes.

Le dossier de contrôle contenait une phrase séduisante : « la maintenance est planifiée et active ». La version du calendrier était connue, le compteur avait progressé et le prochain passage était calculé. À force de voir ces trois signes réunis, l’équipe avait laissé disparaître la question la plus importante : quel événement concret ce statut permettait-il d’affirmer ?

La réponse est courte : très peu, mais avec précision.

RFC 9922 normalise des types et des groupements YANG destinés aux calendriers d’événements, de politiques, de services ou de ressources. Ce travail commun est utile parce qu’un contrôleur et un équipement peuvent parler de période, de récurrence, de fuseau et de statut sans inventer des mots incompatibles. Il n’est pas un moteur d’ordonnancement universel. Le RFC dit expressément qu’il ne présume pas la nature des actions déclenchées et qu’il ne traite ni la détection ni la résolution des conflits.

Lire les champs pour ce qu’ils sont

Le groupement schedule-status peut exposer l’état, la version, le type de calendrier, l’heure locale de l’hôte, la dernière mise à jour, le compteur, la dernière occurrence, la prochaine occurrence, la dernière occurrence en échec et le compteur d’échecs. Cette liste est riche; elle ne doit pas devenir un récit fictif.

Quand une récurrence est active, upcoming-occurrence signifie qu’une occurrence à venir a été calculée dans le modèle représenté. Il ne dit pas que le composant qui consomme ce modèle aura encore une capacité disponible, qu’un principal sera autorisé, ou qu’une opération terminera sans erreur. last-occurrence distingue déjà son objet de last-failed-occurrence. Même avec les deux valeurs, il manque l’identifiant d’action, la cible, la réponse, l’éventuelle compensation et la mesure du résultat.

La borne est structurelle, pas seulement sémantique. Le module ietf-schedule définit lui-même des identités, types et groupements; seul, il n’expose ni nœud écrivable, ni état en lecture seule, ni RPC. Une autre spécification doit dire quelle action est associée au calendrier. C’est elle qui doit expliquer la sécurité, les collisions de demandes, la règle d’exception et la preuve de clôture.

Cette modestie est une protection. Un calendrier commun ne devrait pas décider silencieusement quel propriétaire de service perd face à une autre demande, ni transformer une fenêtre de temps en droit de modifier une infrastructure. La date est une condition possible; elle n’est pas une délégation de pouvoir.

Du calcul à l’effet : quatre dossiers, non un seul

Pour qu’une organisation puisse soutenir qu’un changement programmé a réellement eu lieu, elle doit relier quatre registres. Le premier conserve la définition: version, fuseau, règle de récurrence, exceptions, horloge et occurrence calculée. Le deuxième contient l’autorisation locale: identité, portée, règle en vigueur et décision. Le troisième est le reçu d’exécution: identifiant immuable, cible, début, fin, réponse et retour arrière. Le quatrième vérifie l’effet attendu hors du planificateur.

Les frontières apparaissent dans des cas ordinaires. Une horloge erronée peut déclencher au mauvais intervalle. Un exécuteur peut être indisponible alors que le calendrier reste actif. Une règle locale peut refuser une invocation pourtant arrivée à l’heure. Une cible peut accepter une requête et ne pas produire le résultat opérationnel recherché. RFC 9922 avertit également que des récurrences trop fréquentes peuvent saturer la gestion ou masquer une anomalie au milieu des événements attendus, et que l’absence de journaux détaillés de déclenchement et de résultat rend l’incident difficile à reconstruire.

RFC 8413 montre un voisinage instructif : la planification de ressources aide à anticiper une LSP, mais la disponibilité future demeure au mieux une attente et la politique de l’opérateur peut refuser la demande. L’instanciation ultérieure est encore une étape différente. Ce n’est pas une extension de RFC 9922; c’est une démonstration de la distance entre un horizon calculé et un fait réalisé.

La sécurité de gestion n’efface pas cette distance. RFC 9922 demande un transport sûr et une authentification mutuelle. RFC 8341 NACM sépare l’accès aux opérations, données, actions et notifications. Lire un calendrier ou même recevoir l’autorisation d’une opération ne donne pas une preuve universelle de son effet.

La doctrine de Heng Lu impose ici une discipline simple : le modèle, l’écran et la recommandation appartiennent à une couche de représentation; le chemin qui tourne, valide et laisse une trace appartient à la réalité opérationnelle. La couche commune reste précieuse si elle reste mince.

Sources