When a valid YANG schedule has stale authority

Summary

RFC 9922 standardizes reusable YANG scheduling types, validity guards and status fields, but deliberately does not define the actions being triggered or resolve their conflicts. Its common status can show an enabled, current schedule without saying who still authorizes the action.
Daniel Kade proposes an occurrence-authority receipt that joins the schedule version, exact action, institutional sponsor, current policy and execution principal to the trigger and its result. This is an operator control proposal, not an RFC 9922 requirement or a claim of a known deployment failure.

The schedule wakes after its decision context has moved

A future action separates decision from execution. That separation is the point of scheduling: staff need not remain online until a maintenance window, a resource reservation can be prepared before demand arrives, and a recurring measurement can run without a fresh manual command. It is also where a quiet category error enters.

The system can answer whether a recurrence expression is valid, whether the next occurrence is inside an allowed window, whether a target resource appears available and whether the schedule is enabled. An operator looking at those green conditions may read them as a single answer: proceed. But none necessarily answers whether the institution still wants this action, under the authority that exists now.

Consider a recurring configuration task. When it was created, a network team controlled the target and a service account had permission to write it. Months later, ownership moves to a different team. The old account remains technically usable for a migration period. The schedule is neither malformed nor expired. Its seventh occurrence arrives on time.

There need not be an intruder, a software bug or a negligent administrator. The schedule can be faithful to its stored definition and still be detached from the current decision structure. The important question is no longer “did the scheduler follow the rule?” It is “which authority made this rule operative for this occurrence?”

RFC 9922 defines time validity, not institutional validity

RFC 9922 is a Standards Track product of the IETF, published in March 2026. It defines the ietf-schedule module: common types and reusable groupings for scheduling events, policies, services or resources by date and time. It supports one-shot periods and recurrence, including an iCalendar-like representation, and it supplies parameters for schedule validation and status reporting.

Its scope is disciplined. The RFC makes no assumption about the nature of the action triggered by a schedule. It places detection and resolution of schedule conflicts outside the document. The module itself contains groupings and types; by itself it exposes no writable data nodes, operational-state nodes or RPCs. Other YANG modules consume and augment it.

That modular boundary is not a flaw. It is the condition that makes the groupings reusable. A schedule for an alarm, an OAM test, a policy, an LSP and a destructive configuration action should not inherit one universal authorization theory from a recurrence library.

It does mean that “valid” must be read precisely. The generic-schedule-params grouping includes a validity value. RFC 9922 defines that as the point after which a schedule is no longer valid to start. An occurrence later than the configured value is not executed. Maximum and minimum starts, maximum end and discard behaviour add other temporal guards.

Those fields answer when a schedule may run. They do not identify an approving body, prove that a creator still holds a role, bind an action to a current policy version or say whether a changed target must be approved again. Temporal validity and decision authority can coincide, but one is not evidence of the other.

A version can be current while its sponsor is invisible

The RFC's status groupings are operationally useful. They can expose whether a schedule is enabled, disabled, finished, out of date or conflicted. They can carry a version, last update, occurrence counter, last and next occurrence, last failed occurrence and failure counter. An operator can learn that version 7 is enabled, last ran yesterday and has failed twice.

There is a revealing limit in the comparison with the older DISMAN-SCHEDULE-MIB. RFC 9922 maps many MIB objects into the YANG groupings, but lists schedOwner as “Not Supported.” It also says that future modules may add source and precedence when schedules arrive from multiple origins.

The inference must stay narrow. RFC 9922 does not prohibit ownership metadata. It leaves consuming modules free to add it. Many products may already record creators, approvers and service identities. The standard evidence is simply that owner or sponsor is not part of the generic common status.

That omission matters when the status is used as an executive shorthand. Version is not provenance. “Last updated” is not “last approved.” A failure counter cannot reveal that a successful action should no longer have been permitted. Even the state conflicted concerns scheduling state unless a consuming module gives it a wider meaning.

An assurance view should therefore resist a seductive sentence: “The current schedule executed successfully.” Current can refer to its latest stored version. Successfully can refer to the scheduler invoking an action. Neither term identifies the present authority behind the action.

NACM protects requests, but the later occurrence needs a named principal

RFC 8341 defines the Network Configuration Access Control Model for NETCONF and RESTCONF. It associates an authenticated session with a username and groups, applies rules to protocol operations and datastore access, and requires the server to use the rules in effect when it starts processing a message. NACM is essential to controlling who may create, alter, delete or invoke management objects.

Its time boundary is equally important. RFC 8341 discusses requests initiated from user sessions. It notes that server-initiated access, such as loading running configuration during boot, is not enforced as a user-session request. That sentence does not decide how every scheduler treats an occurrence. A consuming module may model the occurrence as an action, use a service principal, re-evaluate current policy or preserve a durable delegation.

The governance question is precisely which of those models applies. If Alice created a schedule while belonging to an operations group, does the seventh occurrence execute as Alice, as the scheduler, as the controller, or as an institutional service? If Alice leaves, should the schedule stop, transfer, or continue under a separately approved mandate? If the target moves into a protected subtree, which policy version controls the occurrence?

There is no universal answer. A backup job should not fail merely because its original creator changed departments. A scheduled trust-anchor change may deserve new approval if the target or evidence changed. What must not happen is an accidental answer hidden inside an implementation default.

The scheduler needs a named execution principal and an explicit continuity rule. Durable institutional authorization is legitimate; invisible inherited authority is not the same thing.

A trusted clock cannot authorize an action

RFC 9922 correctly treats time as a security dependency. Inaccurate time can trigger actions at the wrong intervals. Very frequent recurrences can conceal abnormal behaviour or keep a system busy. Missing detailed logs of trigger times and action results can make incidents hard to trace.

The surrounding standards divide the time problem carefully. RFC 3339 defines Internet timestamps. RFC 7317 gives YANG-managed systems time-zone and NTP configuration. RFC 8915's Network Time Security authenticates time synchronization, detects replay and binds responses to requests.

These controls strengthen the evidence that 02:00 really was 02:00 and that the time packet came from an authenticated source. They do not prove that the maintenance action remained allowed. An authenticated clock can trigger an unauthorized action exactly on time. Conversely, a legitimate action can misfire because the clock is wrong.

An occurrence record should keep the two proofs apart: time source and uncertainty on one side, authority and policy decision on the other. Combining them into a single “valid” badge conceals which proposition failed.

Scheduled resource control shows the delayed-action surface

RFC 8413 describes why operators reserve traffic-engineering resources for future LSPs. A path may be computed and capacity reserved now, while the LSP is established only when the requested window begins. The framework says future-LSP information should be correlated with resource reservations so the operator can see why a resource was booked, handle pre-emption and release it after cancellation. Operator policy governs how much can be booked and how reoptimization proceeds.

RFC 8934 turns that design into PCEP mechanisms. A stateful PCE can maintain scheduled LSP state; at the start time a PCC initiates setup, and at expiry it may remove the LSP according to the scheduled attributes. Creation, modification, synchronization and actual activation occur at different moments.

Nothing in those RFCs documents an authorization failure. They make the delayed-control surface visible. A path can still satisfy its constraints. The scheduled database can be synchronized. The start time can be correct. Yet the customer request may have been cancelled elsewhere, a sponsor may no longer control the service, or the operator's policy may have changed.

Resource availability, protocol validity and decision authority are independent joins. Reliable automation must show all three rather than let one stand in for the others.

The occurrence-authority receipt

The practical repair is not to reopen the common scheduling module. It is to attach a compact authority receipt where a consuming module binds a schedule to a consequential action.

For each occurrence—or for a cryptographically bounded series of equivalent low-risk occurrences—the receipt should record:

the stable schedule identifier, current version and exact definition hash;
the recurrence instance, planned time and observed trigger time;
the action and target classes, plus protected commitments to sensitive values;
the creator and current institutional sponsor, distinguishing people from durable service roles;
the authorization basis at creation and the current policy or delegation version;
the principal under which execution occurs and the current allow-or-deny result;
the time source and relevant uncertainty;
any schedule conflict, precedence, pre-emption or local-policy disposition;
the intended-state commitment, applied-state observation and action result;
the reason for failure, cancellation or deliberate non-execution; and
a supersession and correction link.

This does not require a human to click approve every minute. A signed policy decision can cover a defined action class, target set, risk ceiling and occurrence range. It should expire when a schedule version, sponsor, target, policy, conflict condition or requested effect changes.

The receipt also need not publish usernames, topology or configuration. A public accountability surface can expose a sponsor class, policy identifier, hashes, custodian and disposition. Protected evidence can retain the operational details.

The point is to make “why this ran” answerable at the same resolution as “when this ran.”

Strong objections improve the boundary

The first objection is continuity. Institutional schedules must survive vacations, staff turnover and account rotation. Correct. The receipt should support deliberate transfer from a person to a durable institutional sponsor. It should make continuity stronger, not attach the network to a departed employee.

The second is cost. Re-evaluating complex policy at every high-frequency occurrence could overwhelm the system. A bounded authorization lease can amortize the decision, provided its scope, policy version and invalidation triggers are explicit. The result is not perpetual creation-time permission; it is a current, inspectable authorization window.

The third is duplication. NACM, an orchestrator or an existing audit platform may already record much of this data. Then the receipt can be a join over existing evidence. The test is whether an independent operator can connect the schedule version, current authority, exact occurrence and outcome without relying on oral knowledge.

The fourth is modularity. RFC 9922 deliberately does not know what actions mean. That is why the control belongs in the consuming model or operational audit layer. The proposal respects the standard's boundary instead of treating genericity as negligence.

Evidence limits

This analysis reads standards, not production estates. It does not show that a named vendor, operator or open-source implementation runs stale-authority schedules. It does not establish a breach, outage, exploit, loss or policy violation. It does not show that existing systems lack owner fields, service principals, reauthorization or detailed logs.

Nor does it make the proposed receipt an IETF requirement. RFC 9922 is a consensus Standards Track document. Its groupings solve a defined interoperability problem, and its security section explicitly assigns action-specific considerations to modules that reuse them.

The supportable conclusion is narrower. A schedule can be current in the temporal and operational vocabulary standardized by RFC 9922 while the authority for its bound action is a separate, unstated fact. Once execution is delayed, the institution must decide whether authority is durable, transferred, re-evaluated or withdrawn. If that decision is not recorded, “enabled” becomes an assertion larger than the data can carry.

A Valid YANG Schedule Is Not Evidence That Its Action Is Still Authorized

Summary

The schedule wakes after its decision context has moved

RFC 9922 defines time validity, not institutional validity

A version can be current while its sponsor is invisible

NACM protects requests, but the later occurrence needs a named principal

A trusted clock cannot authorize an action

Scheduled resource control shows the delayed-action surface

The occurrence-authority receipt

Strong objections improve the boundary

Evidence limits

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing