Summary

  • RFC 9922 standardisiert wiederverwendbare YANG-Typen und Gruppierungen für Zeitpunkte, Wiederholungen, Prüfgrenzen und Status. Welche Aktion ausgelöst wird und wie Zeitplankonflikte gelöst werden, bleibt ausdrücklich außerhalb des Geltungsbereichs; „enabled“ benennt daher keine fortbestehende Entscheidungsbefugnis.
  • Daniel Kade schlägt einen Autoritätsbeleg pro Ausführung vor, der Zeitplanversion und -hash, Aktion, Ziel, institutionellen Träger, aktuelle Richtlinie, Ausführungsprinzipal, Zeit und Ergebnis verbindet. Das ist ein Betriebsvorschlag, keine Forderung von RFC 9922 und kein Bericht über einen bekannten Vorfall.

Der Kalender bleibt stehen, während die Zuständigkeit wandert

Planung trennt Entscheidung und Wirkung. Eine Ressource lässt sich heute für morgen reservieren, eine Wartung wartet auf ein ruhiges Fenster, eine Messung wiederholt sich ohne neuen manuellen Befehl. Genau diese zeitliche Entkopplung macht Automatisierung nützlich.

Eine Organisation bewegt sich währenddessen weiter. Mitarbeitende wechseln, Dienste werden übertragen, Richtlinien verschärft, Konten für eine Übergangszeit erhalten und Ziele neu eingestuft. Keine dieser Veränderungen muss die Wiederholungsregel syntaktisch ungültig machen.

So können alle Anzeigen grün bleiben: die nächste Ausführung liegt innerhalb der Grenze, die Version ist aktuell, es gibt keinen Konflikt und die Zeitquelle ist vertrauenswürdig. Diese Aussagen belegen, dass der Scheduler seine gespeicherte Regel versteht. Sie belegen nicht, dass die Institution die Wirkung unter heutigen Bedingungen noch will.

Das Szenario braucht weder Angreifer noch Softwarefehler. Ein pflichtbewusstes System und eine legitime Reorganisation genügen. Die Governance-Frage lautet nicht nur, ob die Regel befolgt wurde, sondern wessen heutige Befugnis diese Befolgung zur zulässigen Handlung machte.

RFC 9922 meint zeitliche Gültigkeit

RFC 9922 erschien im März 2026 als Standards-Track-Dokument der IETF. Nach öffentlicher Prüfung und IESG-Freigabe repräsentiert es IETF-Konsens. Das Modul ietf-schedule definiert gemeinsame Typen und Gruppierungen, um Ereignisse, Richtlinien, Dienste oder Ressourcen nach Datum und Uhrzeit zu planen. Es reicht von einmaligen Perioden bis zu einfachen und iCalendar-ähnlichen Wiederholungen.

Der Text zieht eine bewusste Grenze. Er nimmt nicht an, welche Aktion ein Zeitplan auslöst, und lässt Erkennung und Auflösung von Konflikten außerhalb seines Umfangs. Das gemeinsame Modul stellt allein weder schreibbare Knoten noch Betriebszustand oder RPCs bereit. Verbrauchende Module übernehmen, verfeinern und erweitern die Gruppierungen.

Diese Allgemeinheit ist sinnvoll. Ein Alarm, ein OAM-Test, eine Reservierung und eine irreversible Konfigurationsänderung dürfen unterschiedliche Genehmigungsregeln haben. Die anwendungsspezifische Verantwortung beginnt dort, wo Zeit und Wirkung verbunden werden.

Im generic-schedule-params-Grouping bezeichnet validity den Zeitpunkt, nach dem ein Zeitplan nicht mehr starten darf. Spätere Vorkommnisse werden nicht ausgeführt. Früheste und späteste Starts, maximales Ende und Verwerfungsaktion ergänzen die zeitlichen Leitplanken.

Diese Felder sagen, wann der Ablauf noch stattfinden kann. Sie nennen keine genehmigende Stelle, beweisen nicht die heutige Rolle des Erstellers, binden keine aktuelle Richtlinienfassung und entscheiden nicht, ob ein geändertes Ziel neu genehmigt werden muss. Zeitliche Gültigkeit ist keine institutionelle Autorität.

Eine aktuelle Version enthält noch keine Herkunft

Die Statusgruppierungen von RFC 9922 zeigen enabled, disabled, finished, out-of-date oder conflicted. Sie können Version, letzte Aktualisierung, Zähler, vorheriges und nächstes Vorkommnis, letzten Fehler und Fehlerzahl tragen.

Damit lässt sich betreiben: Welche Definition gilt? Wann änderte sie sich? Wann läuft sie wieder? Wie oft scheiterte sie? Doch eine Versionsnummer ist kein Genehmigungsnachweis. last-update ist keine letzte Zustimmung. Null Fehler schließen nicht aus, dass eine inzwischen unzulässige Aktion technisch erfolgreich war.

Die Zuordnung zum älteren DISMAN-SCHEDULE-MIB macht die Grenze sichtbar. RFC 9922 findet für viele Objekte Entsprechungen, führt schedOwner jedoch als „Not Supported“. Zugleich erklärt der RFC, dass künftige Module bei mehreren Quellen etwa source und precedence ergänzen können.

Daraus folgt nicht, dass Implementierungen keinen Eigentümer speichern dürfen. Ein Verbrauchermodul kann ihn hinzufügen. Belegt ist nur, dass Eigentümer oder Sponsor kein Bestandteil des gemeinsamen generischen Status ist. Wer diesen Status als Autorisierungsbeweis verwenden will, muss die fehlende Verbindung selbst liefern.

„Der aktuelle Zeitplan lief erfolgreich“ bleibt deshalb mehrdeutig. Aktuell kann nur die gespeicherte Fassung meinen; erfolgreich vielleicht nur den Aufruf der Aktion. Die gegenwärtige Befugnis ist eine weitere Aussage.

NACM schützt die Anfrage, doch die spätere Ausführung braucht ein Prinzipal

RFC 8341 definiert NACM für NETCONF und RESTCONF. Eine authentisierte Sitzung wird Benutzer und Gruppen zugeordnet. Der Server verwendet die Regeln, die beim Beginn der Nachrichtenverarbeitung gelten. Damit lassen sich Anlegen, Ändern und Löschen eines Zeitplans sowie vom Verbrauchermodul angebotene Aktionen schützen.

Es wäre also falsch zu behaupten, YANG kenne keine Zugriffskontrolle. Offen ist die Identität, unter der ein viel späteres Vorkommnis handelt.

RFC 8341 behandelt vor allem Anfragen aus Benutzersitzungen und unterscheidet bestimmte serverinitiierte Zugriffe. Er legt nicht für jeden Scheduler fest, ob der alte Benutzer, ein Dienstkonto, der Controller oder ein neu bewertetes institutionelles Mandat die Aktion trägt.

Ein regelmäßiges Backup soll einen Personalwechsel überstehen. Eine Schlüsselrotation, Routenrücknahme oder Ressourcenverdrängung kann dagegen eine neue Entscheidung brauchen, wenn Ziel oder Risiko wechseln. Beide Regeln können vernünftig sein. Gefährlich ist eine unbenannte Voreinstellung.

Ersteller, heutiger institutioneller Träger, technisches Ausführungsprinzipal und genehmigende Stelle sollten getrennt werden. Ein alter Benutzername ist weder ein gutes Kontinuitätsmodell noch ein präziser Widerrufspunkt.

Eine authentisierte Uhr erteilt keine Erlaubnis

RFC 9922 nennt zuverlässige Zeit eine Sicherheitsabhängigkeit. Falsche Zeit kann Ereignisse in falschen Abständen auslösen. Häufige Wiederholungen können ungewöhnliches Verhalten im Normalbetrieb verstecken oder Ressourcen binden. Fehlen detaillierte Protokolle jedes Auslösers und Ergebnisses, wird Nachvollziehbarkeit schwierig.

RFC 3339 definiert die Zeitdarstellung. RFC 7317 stellt Zeitzonen- und NTP-Konfiguration für YANG-Systeme bereit. RFC 8915 schützt NTP mit Network Time Security: Identität, Authentisierung, Wiederholungsschutz und Zuordnung von Anfrage und Antwort.

Diese Mechanismen stärken die Aussage, dass es wirklich zwei Uhr war. Sie sagen nicht, dass die Handlung um zwei Uhr noch erlaubt war. Eine sichere Uhr kann ein veraltetes Mandat pünktlich auslösen; eine legitime Aktion kann an falscher Zeit scheitern.

Der Beleg muss deshalb zwei Ketten führen: Zeitquelle, Soll- und Ist-Zeit sowie Unsicherheit einerseits; Sponsor, Richtlinie, Prinzipal und Allow-oder-Deny-Entscheidung andererseits. Ein gemeinsamer „gültig“-Indikator verdeckt die Fehlergrenze.

Reservierte Zukunft macht die Trennung praktisch

RFC 8413 beschreibt die zeitgeplante Reservierung von Traffic-Engineering-Ressourcen. Ein künftiger LSP kann heute berechnet und mit Kapazität hinterlegt werden, obwohl er erst zu Beginn des Fensters entsteht. Der Rahmen verlangt die Korrelation von LSP und Reservierung, damit Grund, Verdrängung und Freigabe nach Stornierung verständlich bleiben. Betreiberpolitik steuert Umfang und Reoptimierung.

RFC 8934 konkretisiert dies für PCEP. Eine Stateful PCE verwaltet geplante LSPs; zum Start stößt der PCC den Aufbau an und zum Ende gegebenenfalls die Entfernung. Anfrage, Berechnung, Synchronisierung, Aktivierung und Löschung liegen auseinander.

Die RFCs dokumentieren keinen Autorisierungsfehler. Sie zeigen den Ort einer verzögerten Wirkung. Der Pfad kann weiter alle Bedingungen erfüllen und die Ressource verfügbar sein, obwohl eine Kundenanforderung in einem anderen System storniert oder der Dienst übertragen wurde. Machbarkeit, Protokollkorrektheit und Entscheidungsbefugnis sind getrennte Verbindungen.

Ein Autoritätsbeleg für jedes Vorkommnis

Das gemeinsame Modul muss dafür nicht geändert werden. Wo ein Verbrauchermodul den Zeitplan mit einer folgenreichen Aktion verbindet, kann es pro Ausführung einen kompakten Beleg erzeugen. Eine klar begrenzte Serie gleichartiger, risikoarmer Vorgänge darf gemeinsam autorisiert werden.

Der Beleg verbindet:

  • stabile Zeitplan-ID, aktuelle Version und Hash der vollständigen Definition;
  • Wiederholungsinstanz, geplante und beobachtete Zeit;
  • Aktions- und Zielklasse mit geschützten Bindungen sensibler Werte;
  • Ersteller und heutigen institutionellen Sponsor;
  • Genehmigungsgrundlage bei Erstellung und aktuelle Richtlinien- oder Delegationsfassung;
  • Ausführungsprinzipal und gegenwärtiges Allow- oder Deny-Ergebnis;
  • Zeitquelle und relevante Unsicherheit;
  • Konflikt-, Vorrang- oder Verdrängungsentscheidung;
  • Bindung des Sollzustands, beobachteten Istzustand und Ergebnis;
  • Grund für Fehler, Stornierung oder bewusste Nichtausführung;
  • Verweise auf Ablösung und Korrektur.

Das verlangt keinen Menschenklick pro Minute. Eine signierte Autorisierungslease kann Aktionsklasse, Zielmenge, Risikogrenze und Vorkommnisbereich umfassen. Ändern sich Version, Sponsor, Ziel, Richtlinie oder Wirkung, endet ihre Wiederverwendung.

Öffentlich müssen auch keine Benutzernamen, Topologien oder Konfigurationen stehen. Eine sichtbare Fläche kann Rollenklasse, Richtlinien-ID, Hashes, Verwahrer und Entscheidung nennen; Details bleiben geschützt.

So wird „warum durfte dies laufen?“ genauso präzise beantwortbar wie „wann lief es?“.

Einwände bestimmen die Proportion

Kontinuität ist der erste Einwand. Institutionelle Zeitpläne dürfen nicht mit jeder Versetzung sterben. Richtig: Eine ausdrückliche Übertragung auf eine dauerhafte Rolle ist besser als die stille Erhaltung eines verwaisten Kontos.

Der zweite Einwand ist Aufwand. Komplexe Regeln bei jeder Sekunde neu zu prüfen kann untragbar sein. Eine begrenzte, zwischengespeicherte Entscheidung ist vertretbar, wenn Umfang, Laufzeit und Widerrufsauslöser sichtbar sind.

Der dritte ist Doppelarbeit. NACM, Orchestrator und Auditplattform besitzen vielleicht bereits die Daten. Dann ist der Beleg eine überprüfbare Verknüpfung, keine neue Gesamtdatenbank. Entscheidend ist, ob ein Berechtigter Version, heutige Autorität, Vorkommnis und Ergebnis ohne mündliche Überlieferung verbinden kann.

Der vierte betrifft Modularität. RFC 9922 kennt die Aktionen absichtlich nicht. Deshalb gehört die Kontrolle ins Verbrauchermodul oder die Betriebssicherung. Das respektiert die Standardgrenze.

Grenzen der Belege

Die Quellen beschreiben Standards, keine Produktionslandschaft. Sie belegen nicht, dass ein bestimmter Anbieter oder Betreiber Zeitpläne mit veralteter Autorität ausführt. Es gibt hier keinen nachgewiesenen Angriff, Ausfall, Verlust oder Regelverstoß. Ebenso wenig ist belegt, dass vorhandene Implementierungen Eigentümer, Dienstprinzipale, erneute Freigaben oder ausreichende Protokolle vermissen lassen.

Der vorgeschlagene Beleg ist keine IETF-Vorgabe. RFC 9922 ist ein Konsensdokument mit klarer Interoperabilitätsaufgabe und weist aktionsbezogene Sicherheitsfragen zu Recht den verbrauchenden Modulen zu.

Die tragfähige Schlussfolgerung ist enger: Ein Zeitplan kann im zeitlichen und betrieblichen Vokabular von RFC 9922 aktuell bleiben, während die institutionelle Befugnis seiner Aktion eine getrennte Tatsache ist. Wird nicht festgehalten, ob diese Befugnis fortbesteht, übertragen, neu geprüft oder entzogen wurde, verspricht „enabled“ mehr, als das Modell beweist.

Sources

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://www.rfc-editor.org/info/rfc9922/
  5. https://www.rfc-editor.org/rfc/rfc9922.html
  6. https://www.rfc-editor.org/rfc/rfc8341.html
  7. https://www.rfc-editor.org/info/rfc8413/
  8. https://www.rfc-editor.org/rfc/rfc8934.html
  9. https://www.rfc-editor.org/rfc/rfc3339.html
  10. https://www.rfc-editor.org/rfc/rfc7317.html
  11. https://www.rfc-editor.org/rfc/rfc8915.html
  12. https://www.rfc-editor.org/rfc/rfc8342.html
  13. https://www.rfc-editor.org/rfc/rfc7950.html
  14. https://www.rfc-editor.org/rfc/rfc6241.html
  15. https://www.rfc-editor.org/rfc/rfc8040.html