Definitions of Managed Objects for Scheduling Management Operations
obsoletes
- rfc-2591 — Definitions of Managed Objects for Scheduling Management Operations
Extracted elements (26)
Calendar bit-fields use an OR within each object and AND across objects. This design allows compact expression of complex schedules (e.g., every Monday and Friday in June and July) without requiring enumeration of each individual date-time combination.
Scheduled actions are restricted to SNMP set operations on local INTEGER MIB objects rather than arbitrary operations. This avoids delegation-of-access-rights security problems and simplifies the model; complex actions can still be achieved by triggering a management script via the Script MIB.
The schedOwner initial index serves as an owner index enabling VACM to be configured per-user by matching the owner index subidentifiers in vacmViewTreeFamilySubtree, avoiding the need for per-row access control configuration.
The schedTriggers counter was added in RFC 3231 (not in RFC 2591) to distinguish total trigger attempts from schedFailures (error count), giving operators visibility into both successful and failed invocations without having to subtract.
The schedCompliance and schedGroup conformance definitions from RFC 2591 are deprecated by RFC 3231 and replaced by schedCompliance2 and schedGroup2, which add the mandatory schedTriggers object. Implementations conforming only to the deprecated schedGroup omit schedTriggers.
When time is set backwards (ambiguous times), the scheduler will invoke a scheduled action at every occurrence of the ambiguous time. When time is set forward causing a nonexistent time, the action will not be invoked at all for that skipped interval.
Entries in the schedTable SHOULD be cleaned up whenever a user is removed from an SNMP engine, to prevent stale schedule entries from executing with credentials of a withdrawn user.
Implementations MUST guarantee that action invocations will not occur before at least schedInterval seconds have passed since the previous invocation. A periodic schedule with schedInterval=0 MUST be ignored and never invoke an action.
Implementations that do not support schedCalendarGroup MUST return inconsistentValue errors on attempts to set schedType to calendar(2) or oneshot(3).
Implementations that maintain a list of pending activations MUST re-calculate them when schedInterval, schedWeekDay, schedMonth, schedDay, schedHour, schedMinute, or schedType is changed.
schedLocalTime MUST return all 11 bytes of the DateAndTime textual convention so that a manager can retrieve the local time offset from GMT.
The scheduler MUST enforce access control rules (via the isAccessAllowed abstract service interface from RFC 2571) when performing the SNMP set operation on schedVariable, using the securityModel, securityName, and securityLevel recorded at row-creation time.
Calendar scheduling uses five BITS objects: schedWeekDay (7 bits, sunday–saturday), schedMonth (12 bits, january–december), schedDay (62 bits, d1–d31 for forward and r1–r31 for reverse-from-end-of-month), schedHour (24 bits, h0–h23), and schedMinute (60 bits, m0–m59). Multiple bits set create an OR within an object; objects are ANDed together.
The schedActionFailure notification carries schedLastFailure (SnmpPduErrorStatus) and schedLastFailed (DateAndTime) to report scheduled action invocation failures.
The schedDay object provides two naming schemes: d1(0)–d31(30) count forward from the first day of the month, and r1(31)–r31(61) count backward from the last day, enabling last-day-of-month semantics.
The schedInterval object (Unsigned32, units seconds) specifies the period between periodic action invocations. A value of 0 means the scheduler MUST ignore the entry and never invoke the action.
The schedLocalTime scalar (DateAndTime, SIZE 11) reports the local time used by the scheduler. An implementation MUST return all 11 bytes so managers can retrieve the GMT offset.
The schedOperStatus object has three states: enabled(1) — scheduler is active; disabled(2) — entry is inactive; finished(3) — one-shot schedule has fired and self-disabled. The operational state MUST NOT be enabled when schedRowStatus is not active.
The schedTable is the central management table defining scheduled actions. Each entry is indexed by schedOwner (0..32 octets) and schedName (1..32 octets), and contains all parameters controlling when and how a scheduled SNMP set operation is invoked.
The schedTriggers counter (Counter32, read-only) counts the total number of action invocation attempts, both successful and failed. It was added in RFC 3231 (not present in the obsoleted RFC 2591).
The schedType object distinguishes three schedule types: periodic(1) uses schedInterval (seconds between invocations), calendar(2) uses the bit-field calendar objects, and oneshot(3) is like calendar but disables itself after first invocation by entering the finished schedOperStatus.
The SnmpPduErrorStatus textual convention enumerates all SNMPv1/v2 PDU error status codes (noError through inconsistentName) plus a pseudo-code noResponse(-1) to signal a timeout from the scheduler's perspective.
The DISMAN-SCHEDULE-MIB module is assigned OID { mib-2 63 } under the SNMP MIB-2 subtree. This document creates no new IANA registries but registers the MIB module identity within the existing mib-2 arc.
Scheduled SNMP set operations must use the security credentials (securityModel, securityName, securityLevel) that were present when the scheduling entry was created; an implementation must record and maintain these credentials for each entry and apply isAccessAllowed before every invocation.
SNMPv1 provides no access control; SNMPv3 with USM (RFC 2574) and VACM (RFC 2575) is recommended. Without SNMPv3, unauthorized principals on a secure network could still GET or SET scheduling objects, potentially causing unintended management actions.
A schedule entry transitions: created (notInService or notReady via schedRowStatus) → disabled (schedAdminStatus=disabled, schedRowStatus=active) → enabled (schedAdminStatus=enabled, schedRowStatus=active) → finished (oneshot only, after first trigger). Attempts to destroy or set notInService while schedOperStatus is enabled return inconsistentValue.