rfc-2591

Definitions of Managed Objects for Scheduling Management Operations

D. Levi, J. Schoenwaelder
date1999-05 streamIETF areaops wgdisman statusPROPOSED STANDARD pages25 canonicalhttps://www.rfc-editor.org/rfc/rfc2591 doi10.17487/RFC2591
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]

obsoleted by

Extracted elements (24)

design-rationale §3.5

Actions are restricted to objects of type INTEGER, but the document notes this does not limit usefulness: simple on/off schedules use status objects directly (e.g., ifAdminStatus), while complex actions trigger a management script via the Script MIB that can perform arbitrary state transitions.

snmp

design-rationale §3.2

Calendar schedule BITS fields for the same calendar dimension (e.g., weekday) are combined with OR, while fields across different dimensions (e.g., weekday AND month) are combined with AND. Setting all bits in a field acts as a wildcard, causing the scheduler to ignore that dimension entirely.

snmp

design-rationale §3.5

Scheduled actions are restricted to SNMP set operations on local MIB objects only. This design avoids security problems that would arise from delegating access rights to remote SNMP engines, where the scheduler could not enforce the originating principal's access control policy.

snmp, security

design-rationale §6

The schedOwner initial index follows the VACM owner-index convention so that VACM subtree entries can be configured to scope each user's access to only their own rows, enabling multi-user tables without cross-user interference.

snmp, security

interoperability-note §2

The MIB module is specified in SMIv2. A translation to SMIv1 is possible but Counter64 objects would be omitted and some machine-readable information would be converted to textual descriptions, which is not considered a semantic change.

snmp

interoperability-note §4

The schedCalendarGroup (schedLocalTime, schedWeekDay, schedMonth, schedDay, schedHour, schedMinute) is an optional conformance group. Implementations that do not support it must return inconsistentValue if a manager attempts to set schedType to calendar(2) or oneshot(3).

snmp

normative-requirement §6 MUST

An implementation MUST ensure that access control rules are applied when performing the scheduled set operation by calling the isAccessAllowed abstract service interface defined in RFC 2271, using the recorded credentials and the write view.

snmp, security

normative-requirement §6 SHOULD

Entries in the schedTable SHOULD be cleaned up whenever a user is removed from an SNMP engine, to prevent schedules owned by withdrawn users from triggering future set operations under stale credentials.

snmp, security

normative-requirement §3.1 MUST

Implementations MUST guarantee that periodic action invocations will not occur before at least schedInterval seconds have passed since the previous invocation. The scheduler must ignore all periodic schedules with schedInterval equal to 0.

snmp

normative-requirement §4 MUST

Rows with schedStorageType permanent MUST allow write access to schedDescr, schedInterval, schedContextName, schedVariable, schedValue, and schedAdminStatus; if schedCalendarGroup is supported, write access must also be allowed for the calendar BITS objects.

snmp

normative-requirement §4 MUST

schedLocalTime MUST return all 11 bytes of the DateAndTime textual convention so that a manager may retrieve the UTC offset used by calendar schedules.

snmp

normative-requirement §6 MUST

Scheduled SNMP set operations MUST use the security credentials (securityModel, securityName, securityLevel) that were present when the corresponding schedTable row was created. Implementations must record and maintain these credentials per entry.

snmp, security

normative-requirement §4 REQUIRED

The minimum set of objects that must be set before a schedTable row can be made active are schedContextName, schedVariable, and schedValue.

snmp

normative-requirement §3.4 SHOULD

When an action is configured to occur at a nonexistent time caused by a forward time transition (e.g., start-of-DST clock-forward), the action SHOULD be invoked immediately upon the time transition. If multiple actions are affected, they SHALL be invoked in the order they would normally have occurred.

snmp

protocol-element §4

schedActionFailure NOTIFICATION-TYPE is emitted whenever the invocation of a scheduled action fails. It carries the varbinds schedLastFailure (SnmpPduErrorStatus) and schedLastFailed (DateAndTime) to identify the error and when it occurred.

snmp

protocol-element §4

schedDay uses a 62-bit BITS field with two complementary numbering schemes: bits d1(0)–d31(30) count forward from the first day of the month, and bits r1(31)–r31(61) count in reverse from the last day, enabling expressions such as 'last day of month' (r1) without knowing the month length.

snmp

protocol-element §4

SchedEntry is the conceptual row of schedTable, indexed by schedOwner (0–32 octets) and schedName (1–32 octets). It contains 20 columnar objects covering schedule parameters, operational status, failure counters, storage type, and row status.

snmp

protocol-element §4

schedType defines three schedule kinds: periodic(1) uses schedInterval in seconds; calendar(2) uses BITS fields schedWeekDay/schedMonth/schedDay/schedHour/schedMinute evaluated in local time; oneshot(3) behaves like calendar but transitions schedOperStatus to finished(3) after the first invocation.

snmp

protocol-element §4

SnmpPduErrorStatus is a textual convention enumerating all SNMPv1 (RFC 1157) and SNMPv2 (RFC 1905) PDU error status codes plus a pseudo-code noResponse(-1) to indicate a timeout condition when invoking a scheduled action.

snmp

protocol-element §4

The DISMAN-SCHEDULE-MIB module (OID mib-2 63) defines managed objects for scheduling SNMP set operations periodically or at specific calendar dates and times. It contains the schedTable, scalars, notifications, and conformance objects.

snmp, yang

security-consideration §6

Because schedules can be configured to trigger far in the future, removing a user from an SNMP engine without cleaning up their schedTable entries creates a security risk: the stored credentials could continue to perform set operations on behalf of the removed user.

snmp, security

security-consideration §6

The scheduled set operation is executed using the viewType write view together with the contextName and variableName from the schedule entry, ensuring the operation is constrained to what the original principal was authorised to write at the time the schedule was created.

snmp, security

state-machine §4

schedOperStatus transitions: enabled(1) — schedule is active and will invoke actions; disabled(2) — schedule is inactive and ignored; finished(3) — schedule has ended and is ignored. A one-shot schedule enters finished(3) automatically after its first action invocation.

snmp

wire-format §4

schedLocalTime has SYNTAX DateAndTime constrained to SIZE(11), meaning the full 11-byte form including UTC offset is always required. This allows a manager to determine the local-time-to-GMT offset used by calendar schedules.

snmp