Summary

  • RFC 9922 supplies reusable YANG scheduling and status vocabulary. An enabled recurrence, a counter, and last-occurrence or upcoming-occurrence describe the schedule surface; they do not identify an action receipt or an effect.
  • The standard makes no assumption about triggered actions and leaves conflict detection and resolution out of scope. Authorization, invocation, execution, rollback and outcome each need their own locally accountable evidence.

The review screen was persuasive. The maintenance recurrence was enabled; the next window appeared in the future; last-occurrence carried last week’s timestamp; the counter had advanced. A change manager read the row as a finished control: the recurring action had happened and would happen again.

The row did not say that.

It may have accurately described an instance of a schedule. It did not identify the consuming module that linked the schedule to an action. It did not show whether a principal was authorized to ask for that action at the relevant time. It did not contain an invocation record, a target, a device response, a rollback result, or independently observed service evidence. Those gaps are not paperwork around a complete technical fact. They are different facts.

RFC 9922, the IETF's common YANG data model for scheduling, is useful because it does not pretend otherwise. It defines types and groupings that another YANG module can reuse when an event, policy, service or resource has a date-and-time schedule. The common layer makes schedule meaning portable. It does not manufacture the action that a consuming module may later attach to that meaning.

A thin schedule model is a feature, not a missing workflow engine

RFC 9922 offers several ways to express periods and recurrences: basic recurrence, UTC forms, time-zone forms, period lists and iCalendar-derived rules. It also supplies the common schedule-status groupings. A consumer can expose state, version, schedule-type, local-time, last-update, a recurrence counter, last-occurrence, upcoming-occurrence, last-failed-occurrence and failure-counter.

Those names invite over-reading. They should instead be treated as bounded observations.

For a recurrence, upcoming-occurrence is available only when the schedule state is enabled. It says that the host has calculated a next scheduled occurrence under the schedule it represents. It does not say that the action will receive authority, that a resource will remain available, or that execution will succeed. last-occurrence identifies a prior scheduled occurrence; it is deliberately separate from last-failed-occurrence. Neither field names an action instance or its outcome. A counter tells a reader something about recurrence accounting, not whether all intended work committed.

The decisive architectural fact is even narrower. The ietf-schedule module itself defines identities, types and groupings. By itself it exposes no writable data nodes, no read-only state nodes and no RPCs. The module does not contain the actuator that would change a route, back up a configuration, allocate bandwidth, rotate a key or close a ticket. A module that reuses its vocabulary must supply the context, including its own security considerations.

RFC 9922 states the boundary plainly: it makes no assumption about the nature of actions triggered by schedules, and detection or resolution of schedule conflicts is outside scope. Calling this a limitation misses the design. A shared schedule format should not silently decide which two requests compete, whose policy wins, whether an exception is permitted, or what a device must do when the window opens. Those are local decisions with local consequences.

Time calculation is not an execution receipt

An apparently mature status record can still be misleading when its evidence chain is compressed. A credible review needs, at minimum, the schedule definition and version; its timezone and the relevant clock/UTC relationship; the calculated occurrence; the identity of the consuming module; the authorized request; the invocation; a target-specific receipt; and an independently measured effect.

Consider a planned maintenance action. A recurrence can calculate 02:00 accurately while the scheduled controller is offline. A controller can submit an operation while a local policy denies it. A device can acknowledge an operation while a later validation rejects the intended state. A resource planner can reserve a future interval while another event changes the usable resource at execution time. Each statement can be true without completing the next one.

RFC 9922 warns why this matters operationally. Inaccurate time synchronization can trigger events at incorrect intervals. Very frequent recurrences can keep a system busy or drown abnormal activity in expected activity. A lack of detailed logs of trigger times and action results makes incidents difficult to trace. The standard is not asking operators to distrust schedules; it is telling them that schedule evidence and execution evidence must be recorded separately.

RFC 8413 makes the same separation visible in a more concrete scheduling context. Future resource state helps plan a scheduled LSP, but a future request can at that time receive only a best-effort expectation of setup. Operator policy may refuse a computation request; later instantiation and signaling are their own path. RFC 8413 is not an implementation of RFC 9922, nor does it make every schedule a reservation. It demonstrates why a plan, a policy decision, an invocation and a realized resource state must keep separate records.

The management transport is another separate layer. RFC 9922 expects secure transport and mutual authentication for YANG management access. RFC 8341 NACM then controls access to operations, data, actions and notifications. An authenticated session with permission to read a schedule does not authorize an action; an authorized operation does not prove an action's physical or service effect. It proves only the particular access-control decision it records.

Heng Lu's Running-Code Primacy provides the executive test. A status field, a publication or a model is not the thing that runs. The relevant control is the executable path that evaluates the schedule with the correct clock, asks the local policy at invocation, carries an immutable action ID to the target, records its response and checks the promised effect. Thin shared vocabulary is valuable. It becomes dangerous only when a dashboard turns that vocabulary into an invented mandate or completed result.

Sources