RFC 2591
Definitions of Managed Objects for Scheduling Management Operations
RFC 2591: Definitions of Managed Objects for Scheduling Management Operations ✨
Network Working Group 🌸 Request for Comments: 2591
Authors: D. Levi from Nortel Networks, and J. Schoenwaelder from TU Braunschweig
Category: Standards Track
Date: May 1999
Obsoletes / Updates: The title block doesn't list anything that this RFC obsoletes or updates. 🫶
Status of This Memo 📋
okay so this doc is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 💬. If you want the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🦋.
Copyright Notice ©️
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract 🎀
This memo defines a chunk of the Management Information Base (MIB) for use with network management protocols in the Internet community. Basically it describes a set of managed objects that schedule management operations periodically or at specified dates and times. It's giving scheduler energy 🗓️✨
Table of Contents 📚
1. Introduction ....................................................2
2. The SNMP Management Framework....................................2
3. Overview ........................................................3
3.1 Periodic Schedules .............................................3
3.2 Calendar Schedules .............................................4
3.3 One-shot Schedules .............................................4
3.4 Time Transitions ...............................................4
3.5 Actions ........................................................5
4. Definitions .....................................................5
5. Usage Examples .................................................18
5.1 Starting a script to ping devices every 20 minutes ............18
5.2 Starting a script at the next Friday the 13th .................18
5.3 Turning an interface off during weekends ......................19
6. Security Considerations ........................................21
7. Intellectual Property ..........................................22
8. Acknowledgments ................................................22
9. References .....................................................22
10. Editors' Addresses ............................................24
11. Full Copyright Statement ......................................251. Introduction 🌷
Okay, so this memo defines a portion of the Management Information Base (MIB) for network management protocols in the Internet community 🫧. Specifically, it describes managed objects that are used to schedule management operations periodically or at specified dates and times ⏰.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [19]. 🔑
2. The SNMP Management Framework 🧚
The SNMP Management Framework is currently made up of five major components 💜:
- An overall architecture, described in RFC 2271 [1].
- Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and is described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], RFC 2579 [6] and RFC 2580 [7].
- Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and is described in RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and is described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and is described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12].
- Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13].
- A set of fundamental applications described in RFC 2273 [14], plus the view-based access control mechanism described in RFC 2275 [15].
Managed objects are accessed through a virtual information store called the Management Information Base, or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI 🔍.
This memo specifies a MIB module that is compliant to SMIv2. A MIB conforming to SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB 🙈.
3. Overview 🦋
The MIB defined in this memo provides scheduling of actions periodically or at specified dates and times. Those actions can be used to realize on-duty / off-duty schedules, or to trigger management functions in a distributed management application 💅.
Schedules can be enabled or disabled by modifying a control object. This lets you pre-configure schedules that get activated or de-activated by other management functions 🎛️.
The term scheduler is used throughout this memo to refer to the entity which implements the scheduling MIB and invokes the actions at the specified points in time ⭐.
3.1. Periodic Schedules 🔁
Periodic schedules are based on fixed time periods between the initiation of scheduled actions. You define them by specifying the number of seconds between two initiations. The time needed to complete the action is usually not known by the scheduler, so it does not influence the next scheduling point 🧮.
Implementations must guarantee that action invocations will not occur before their next scheduled time. However, implementations may be forced to delay invocations in the face of local constraints (e.g., a heavy load on higher-priority tasks). An accumulation of such delays would result in a drift of the scheduling interval with respect to time, and should be avoided 😭.
Scheduled actions that collect statistical data should retrieve time stamps from the data source, and not rely on the accuracy of the periodic scheduler to get accurate statistics 📊.
3.2. Calendar Schedules 📅
Calendar schedules trigger scheduled actions on specified days of the week and days of the month. That means calendar schedules are aware of months, days, weekdays, hours and minutes 🌈.
You can specify multiple values for each calendar item, which gives you a way to define complex schedules 🍓. For example, a schedule could be defined that triggers an action every 15 minutes on a given weekday.
Months, days and weekdays are specified using the objects schedMonth, schedDay and schedWeekDay, which are of type BITS. Setting multiple bits to one in these objects causes an OR operation. For example, setting the bits monday(1) and friday(5) in schedWeekDay restricts the schedule to Mondays and Fridays 💖.
The bit fields for schedMonth, schedDay and schedWeekDay are combined using an AND operation. For example, setting the bits june(5) and july(6) in schedMonth, and combining that with the bits monday(1) and friday(5) set in schedWeekDay, results in a schedule restricted to every Monday and Friday in the months of June and July 🎀. Wildcarding a calendar item is done by setting all of its bits to one.
It's possible to define calendar schedules that will never trigger an action. For example, you could define a calendar schedule that should trigger an action on February 31st. Schedules like that will simply be ignored by the scheduler 💀.
Last thing: calendar schedules are always expressed in local time. The scalar schedLocalTime is provided so a manager can retrieve the notion of local time and the offset to GMT time 🕰️.
3.3. One-shot Schedules 🎯
One-shot schedules are similar to calendar schedules. The difference is that a one-shot schedule automatically disables itself once an action has been invoked 🫶.
3.4. Time Transitions 🌗
When a system's notion of time changes for some reason, implementations of the Schedule MIB must schedule actions differently. One example of a change to a system's notion of time is a daylight savings time transition 🌞.
There are two possible situations when a time transition occurs. First, time may be set backwards, in which case particular times will appear to occur twice within the same day. These are called 'ambiguous times'. Second, time may be set forwards, in which case particular times will appear to not occur within a day. These are called 'nonexistent times' 👻.
When an action is configured in the Schedule MIB to occur at an ambiguous time during a time transition, the action SHALL only be invoked at the first occurrence of the ambiguous time. For example, if an action is scheduled to occur at 2:00 am, and a time transition occurs at 3:00 am which sets the clock back to 2:00 am, the action SHALL only be invoked at the first occurrence of 2:00 am 🔥.
When an action is configured in the Schedule MIB to occur at a nonexistent time, the action SHOULD be invoked immediately upon a time transition. If multiple actions are invoked in this way, they SHALL be invoked in the order in which they normally would have been invoked had the time transition not occurred. For example, if an action (a) is scheduled at 2:05 am and another action (b) at 2:10 am, then both actions SHOULD be invoked at 3:00 am in the order (a),(b) if the time jumps forward from 2:00 am to 3:00 am 🧚♀️.
3.5. Actions 💅
Scheduled actions are modeled by SNMP set operations on local MIB variables. Scheduled actions described in this MIB are further restricted to objects of type INTEGER. This restriction doesn't limit the usefulness of the MIB 🙌. Simple schedules, like on-duty / off-duty schedules for resources that have a status MIB object (e.g. ifAdminStatus), are totally possible.
More complex actions can be realized by triggering a management script that is responsible for performing complex state transitions. A management script can also be used to perform SNMP set operations on remote SNMP engines 🛰️.
okay bestie, here's the actual MIB module, the part where the scheduler gets its whole identity 💖
schedMIB MODULE-IDENTITY
LAST-UPDATED "9811171800Z"
ORGANIZATION "IETF Distributed Management Working Group"
CONTACT-INFO
"David B. Levi
Nortel Networks
4401 Great America Parkway
Santa Clara, CA 95052-8185
U.S.A.
Tel: +1 423 686 0432
E-mail: dlevi@nortelnetworks.com
Juergen Schoenwaelder
TU Braunschweig
Bueltenweg 74/75
38106 Braunschweig
Germany
Tel: +49 531 391-3283
E-mail: schoenw@ibr.cs.tu-bs.de"
DESCRIPTION
"This MIB module defines a MIB which provides mechanisms
to schedule SNMP set operations periodically or at
specific points in time."
::= { mib-2 63 }the module identity is the ID card, complete with the writers' names and when it was last updated 🎀
--
-- The various groups defined within this MIB definition:
--
schedObjects OBJECT IDENTIFIER ::= { schedMIB 1 }
schedNotifications OBJECT IDENTIFIER ::= { schedMIB 2 }
schedConformance OBJECT IDENTIFIER ::= { schedMIB 3 }
--
-- Textual Conventions:
--
SnmpPduErrorStatus ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This TC enumerates the SNMPv1 and SNMPv2 PDU error status
codes as defined in RFC 1157 and RFC 1905. It also adds a
pseudo error status code `noResponse' which indicates a
timeout condition."
SYNTAX INTEGER {
noResponse(-1),
noError(0),
tooBig(1),
noSuchName(2),
badValue(3),
readOnly(4),
genErr(5),
noAccess(6),
wrongType(7),
wrongLength(8),
wrongEncoding(9),
wrongValue(10),
noCreation(11),
inconsistentValue(12),
resourceUnavailable(13),
commitFailed(14),
undoFailed(15),
authorizationError(16),
notWritable(17),
inconsistentName(18)
}the groups are like the little folders of the module 🧚 and the error-status textual convention is a whole enum of PDU error codes, iconic 💅
--
-- Some scalars which provide information about the local time
-- zone.
--
schedLocalTime OBJECT-TYPE
SYNTAX DateAndTime (SIZE (11))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The local time used by the scheduler. Schedules which
refer to calendar time will use the local time indicated
by this object. An implementation MUST return all 11 bytes
of the DateAndTime textual-convention so that a manager
may retrieve the offset from GMT time."
::= { schedObjects 1 }this one is giving time zone realness 🌸 the implementation MUST return all 11 bytes so the manager can get the offset from GMT, no cap
--
-- The schedule table which controls the scheduler.
--
schedTable OBJECT-TYPE
SYNTAX SEQUENCE OF SchedEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table defines scheduled actions triggered by
SNMP set operations."
::= { schedObjects 2 }
schedEntry OBJECT-TYPE
SYNTAX SchedEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describing a particular scheduled action."
INDEX { schedOwner, schedName }
::= { schedTable 1 }
SchedEntry ::= SEQUENCE {
schedOwner SnmpAdminString,
schedName SnmpAdminString,
schedDescr SnmpAdminString,
schedInterval Unsigned32,
schedWeekDay BITS,
schedMonth BITS,
schedDay BITS,
schedHour BITS,
schedMinute BITS,
schedContextName SnmpAdminString,
schedVariable VariablePointer,
schedValue Integer32,
schedType INTEGER,
schedAdminStatus INTEGER,
schedOperStatus INTEGER,
schedFailures Counter32,
schedLastFailure SnmpPduErrorStatus,
schedLastFailed DateAndTime,
schedStorageType StorageType,
schedRowStatus RowStatus
}
schedOwner OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The owner of this scheduling entry. The exact semantics of
this string are subject to the security policy defined by
the security administrator."
::= { schedEntry 1 }
schedName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The locally-unique, administratively assigned name for this
scheduling entry. This object allows a schedOwner to have
multiple entries in the schedTable."
::= { schedEntry 2 }
schedDescr OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The human readable description of the purpose of this
scheduling entry."
DEFVAL { ''H }
::= { schedEntry 3 }
schedInterval OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The number of seconds between two action invocations of
a periodic scheduler. Implementations must guarantee
that action invocations will not occur before at least
schedInterval seconds have passed.
The scheduler must ignore all periodic schedules that
have a schedInterval value of 0. A periodic schedule
with a scheduling interval of 0 seconds will therefore
never invoke an action.
Implementations may be forced to delay invocations in the
face of local constraints. A scheduled management function
should therefore not rely on the accuracy provided by the
scheduler implementation."
DEFVAL { 0 }
::= { schedEntry 4 }the schedule table is the whole main character storyline 👑 every row is one scheduled action, keyed by schedOwner and schedName, and the owner string is at the mercy of the security admin 🙈
schedInterval is where the drama is 😭 a 0 interval means the scheduler ignores that periodic schedule, so it never fires, and delays can happen because of local constraints so don't count on perfect timing
schedWeekDay OBJECT-TYPE
SYNTAX BITS {
sunday(0),
monday(1),
tuesday(2),
wednesday(3),
thursday(4),
friday(5),
saturday(6)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The set of weekdays on which the scheduled action should
take place. Setting multiple bits will include several
weekdays in the set of possible weekdays for this schedule.
Setting all bits will cause the scheduler to ignore the
weekday."
DEFVAL { {} }
::= { schedEntry 5 }
schedMonth OBJECT-TYPE
SYNTAX BITS {
january(0),
february(1),
march(2),
april(3),
may(4),
june(5),
july(6),
august(7),
september(8),
october(9),
november(10),
december(11)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The set of months during which the scheduled action should
take place. Setting multiple bits will include several
months in the set of possible months for this schedule.
Setting all bits will cause the scheduler to ignore the
month."
DEFVAL { {} }
::= { schedEntry 6 }
schedDay OBJECT-TYPE
SYNTAX BITS {
d1(0), d2(1), d3(2), d4(3), d5(4),
d6(5), d7(6), d8(7), d9(8), d10(9),
d11(10), d12(11), d13(12), d14(13), d15(14),
d16(15), d17(16), d18(17), d19(18), d20(19),
d21(20), d22(21), d23(22), d24(23), d25(24),
d26(25), d27(26), d28(27), d29(28), d30(29),
d31(30),
r1(31), r2(32), r3(33), r4(34), r5(35),
r6(36), r7(37), r8(38), r9(39), r10(40),
r11(41), r12(42), r13(43), r14(44), r15(45),
r16(46), r17(47), r18(48), r19(49), r20(50),
r21(51), r22(52), r23(53), r24(54), r25(55),
r26(56), r27(57), r28(58), r29(59), r30(60),
r31(61)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The set of days in a month on which a scheduled action
should take place. There are two sets of bits one can
use to define the day within a month:
Enumerations starting with the letter 'd' indicate a
day in a month relative to the first day of a month.
The first day of the month can therefore be specified
by setting the bit d1(0) and d31(30) means the last
day of a month with 31 days.
Enumerations starting with the letter 'r' indicate a
day in a month in reverse order, relative to the last
day of a month. The last day in the month can therefore
be specified by setting the bit r1(31) and r31(61) means
the first day of a month with 31 days.
Setting multiple bits will include several days in the set
of possible days for this schedule. Setting all bits will
cause the scheduler to ignore the day within a month.
Setting all bits starting with the letter 'd' or the
letter 'r' will also cause the scheduler to ignore the
day within a month."
DEFVAL { {} }
::= { schedEntry 7 }
schedHour OBJECT-TYPE
SYNTAX BITS {
h0(0), h1(1), h2(2), h3(3), h4(4),
h5(5), h6(6), h7(7), h8(8), h9(9),
h10(10), h11(11), h12(12), h13(13), h14(14),
h15(15), h16(16), h17(17), h18(18), h19(19),
h20(20), h21(21), h22(22), h23(23)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The set of hours within a day during which the scheduled
action should take place."
DEFVAL { {} }
::= { schedEntry 8 }the calendar bits are literally my favourite part 🌈 weekdays, months, days counted from the front with d and from the back with r, and hours from h0 to h23 🦋
schedMinute OBJECT-TYPE
SYNTAX BITS {
m0(0), m1(1), m2(2), m3(3), m4(4),
m5(5), m6(6), m7(7), m8(8), m9(9),
m10(10), m11(11), m12(12), m13(13), m14(14),
m15(15), m16(16), m17(17), m18(18), m19(19),
m20(20), m21(21), m22(22), m23(23), m24(24),
m25(25), m26(26), m27(27), m28(28), m29(29),
m30(30), m31(31), m32(32), m33(33), m34(34),
m35(35), m36(36), m37(37), m38(38), m39(39),
m40(40), m41(41), m42(42), m43(43), m44(44),
m45(45), m46(46), m47(47), m48(48), m49(49),
m50(50), m51(51), m52(52), m53(53), m54(54),
m55(55), m56(56), m57(57), m58(58), m59(59)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The set of minutes within an hour when the scheduled action
should take place."
DEFVAL { {} }
::= { schedEntry 9 }
schedContextName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The context which contains the local MIB variable pointed
to by schedVariable."
::= { schedEntry 10 }
schedVariable OBJECT-TYPE
SYNTAX VariablePointer
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"An object identifier pointing to a local MIB variable
which resolves to an ASN.1 primitive type of INTEGER."
::= { schedEntry 11 }
schedValue OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The value which is written to the MIB object pointed to by
schedVariable when the scheduler invokes an action. The
implementation shall enforce the use of access control
rules when performing the set operation on schedVariable.
This is accomplished by calling the isAccessAllowed abstract
service interface as defined in RFC 2271."
::= { schedEntry 12 }
schedType OBJECT-TYPE
SYNTAX INTEGER {
periodic(1),
calendar(2),
oneshot(3)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The type of this schedule. The value periodic(1) indicates
that this entry specifies a periodic schedule. A periodic
schedule is defined by the value of schedInterval. The
values of schedWeekDay, schedMonth, schedDay, schedHour
and schedMinute are ignored.
The value calendar(2) indicates that this entry describes a
calendar schedule. A calendar schedule is defined by the
values of schedWeekDay, schedMonth, schedDay, schedHour and
schedMinute. The value of schedInterval is ignored. A
calendar schedule will trigger on all local times that
satisfy the bits set in schedWeekDay, schedMonth, schedDay,
schedHour and schedMinute.
The value oneshot(3) indicates that this entry describes a
one-shot schedule. A one-shot schedule is similar to a
calendar schedule with the additional feature that it
disables itself by changing in the `finished'
schedOperStatus once the schedule triggers an action.
Changing a schedule's type is equivalent to deleting the
old-type schedule and creating a new-type one."
DEFVAL { periodic }
::= { schedEntry 13 }
schedAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
enabled(1),
disabled(2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The desired state of the schedule."
DEFVAL { disabled }
::= { schedEntry 14 }
schedOperStatus OBJECT-TYPE
SYNTAX INTEGER {
enabled(1),
disabled(2),
finished(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current operational state of this schedule. The state
enabled(1) indicates this entry is active and that the
scheduler will invoke actions at appropriate times. The
disabled(2) state indicates that this entry is currently
inactive and ignored by the scheduler. The finished(3)
state indicates that the schedule has ended. Schedules
in the finished(3) state are ignored by the scheduler.
A one-shot schedule enters the finished(3) state when it
deactivates itself."
::= { schedEntry 15 }
schedFailures OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This variable counts the number of failures while invoking
the scheduled action."
::= { schedEntry 16 }
schedLastFailure OBJECT-TYPE
SYNTAX SnmpPduErrorStatus
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The most recent error that occured during the invocation of
a scheduled action. The value noError(0) is returned
if no errors have occurred yet."
DEFVAL { noError }
::= { schedEntry 17 }
schedLastFailed OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The date and time when the most recent failure occured. The
value '0000000000000000'H is returned if no failure occured
since the last re-initialization of the scheduler."
DEFVAL { '0000000000000000'H }
::= { schedEntry 18 }
schedStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object defines whether this scheduled action is kept
in volatile storage and lost upon reboot or if this row is
backed up by non-volatile or permanent storage.
Conceptual rows having the value `permanent' must allow
write access to the columnar objects schedDescr,
schedInterval, schedContextName, schedVariable, schedValue,
and schedAdminStatus. If an implementation supports the
schedCalendarGroup, write access must be also allowed to
the columnar objects schedWeekDay, schedMonth, schedDay,
schedHour, schedMinute."
DEFVAL { volatile }
::= { schedEntry 19 }
schedRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this scheduled action. A control that allows
entries to be added and removed from this table.
The miminum number of objects that need to be set during
row creation before a row can be set to `active' are
schedContextName, schedVariable and schedValue."
::= { schedEntry 20 }
--
-- Notifications that are emitted to indicate failures. The
-- definition of schedTraps makes notification registrations
-- reversible (see STD 58, RFC 2578).
--
schedTraps OBJECT IDENTIFIER ::= { schedNotifications 0 }
schedActionFailure NOTIFICATION-TYPE
OBJECTS { schedLastFailure, schedLastFailed }
STATUS current
DESCRIPTION
"This notification is generated whenever the invocation of a
scheduled action fails."
::= { schedTraps 1 }
-- conformance information
schedCompliances OBJECT IDENTIFIER ::= { schedConformance 1 }
schedGroups OBJECT IDENTIFIER ::= { schedConformance 2 }
-- compliance statements
schedCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities which implement
the scheduling MIB."
MODULE -- this module
MANDATORY-GROUPS {
schedGroup, schedNotificationsGroup
}
GROUP schedCalendarGroup
DESCRIPTION
"The schedCalendarGroup is mandatory only for those
implementations that support calendar based schedules."
OBJECT schedType
DESCRIPTION
"The values calendar(2) or oneshot(3) are not valid for
implementations that do not implement the
schedCalendarGroup. Such an implementation must return
inconsistentValue error responses for attempts to set
schedAdminStatus to calendar(2) or oneshot(3)."
::= { schedCompliances 1 }
schedGroup OBJECT-GROUP
OBJECTS {
schedDescr,
schedInterval,
schedContextName,
schedVariable,
schedValue,
schedType,
schedAdminStatus,
schedOperStatus,
schedFailures,
schedLastFailure,
schedLastFailed,
schedStorageType,
schedRowStatus
}
STATUS current
DESCRIPTION
"A collection of objects providing scheduling capabilities."
::= { schedGroups 1 }
schedCalendarGroup OBJECT-GROUP
OBJECTS {
schedLocalTime,
schedWeekDay,
schedMonth,
schedDay,
schedHour,
schedMinute
}
STATUS current
DESCRIPTION
"A collection of objects providing calendar based schedules."
::= { schedGroups 2 }
schedNotificationsGroup NOTIFICATION-GROUP
NOTIFICATIONS {
schedActionFailure
}
STATUS current
DESCRIPTION
"The notifications emitted by the scheduler."
::= { schedGroups 3 }
END5. Usage Examples ✨
okay bestie, this section is all about showing off how the scheduling MIB can be used 💖 you can schedule scripts with the Script MIB [17], or set up on-duty/off-duty schedules by changing status objects in other MIB modules 🎀 it's giving practical, no cap 💅
5.1. Starting a script to ping devices every 20 minutes 💖
okay so, bestie, picture this: joe wants a script to ping his devices every 20 minutes, and we're setting it up with a scheduler entry 🦋 the schedule entry is owned by schedOwner = "joe" and it's named schedName = "ping", so the instance identifier is 3.106.111.101.4.112.105.110.103. slay 💅
next, the smLaunchTable entry is owned by smLaunchOwner = "joe" and named smLaunchName = "ping-devs". the full OID for smLaunchStart ends up being smLaunchStart.3.106.111.101.9.112.105.110.103.45.100.101.118.115. and the script lives in the context called "engine1" 🌸
here's how the scheduler entry that fires the script every 20 minutes is set up:
schedInterval.3.106.111.101.4.112.105.110.103 = 1200
schedValue.3.106.111.101.4.112.105.110.103 = 0
schedContextName.3.106.111.101.4.112.105.110.103 = "engine1"
schedVariable.3.106.111.101.4.112.105.110.103 =
smLaunchStart.3.106.111.101.9.112.105.110.103.45.100.101.118.115
schedType.3.106.111.101.4.112.105.110.103 = periodic(1)
schedAdminStatus.3.106.111.101.4.112.105.110.103 = enabled(1)
schedStorageType.3.106.111.101.4.112.105.110.103 = nonVolatile(3)
schedRowStatus.3.106.111.101.4.112.105.110.103 = active(1)all the other columns in the schedTable are status info, so i'm skipping them here 🎀
5.2. Starting a script at the next Friday the 13th 🔥
this one is giving spooky vibes 👻 the schedule entry is owned by schedOwner = "joe" and named schedName = "13th", so the instance identifier is 3.106.111.101.4.49.51.116.104.
joe also owns the smLaunchTable entry, with smLaunchOwner = "joe" and smLaunchName = "ghost". the complete OID for smLaunchStart is smLaunchStart.3.106.111.101.5.103.104.111.115.116, and the script lives in the context identified by "engine1" 🧚
now the scheduler entry that launches the script on every Friday the 13th at midnight:
schedWeekDay.3.106.111.101.4.49.51.116.104 = { friday }
schedMonth.3.106.111.101.4.49.51.116.104 = {
january, february, march, april, may, june,
july, august, september, october, november, december
}
schedDay.3.106.111.101.4.49.51.116.104 = { d13 }
schedHour.3.106.111.101.4.49.51.116.104 = { h0 }
schedMinute.3.106.111.101.4.49.51.116.104 = { m0 }
schedValue.3.106.111.101.4.49.51.116.104 = 0
schedContextName.3.106.111.101.4.49.51.116.104 = "engine1"
schedVariable.3.106.111.101.4.49.51.116.104 =
smLaunchStart.3.106.111.101.5.103.104.111.115.116
schedType.3.106.111.101.4.49.51.116.104 = oneshot(3)
schedAdminStatus.3.106.111.101.4.49.51.116.104 = enabled(2)
schedStorageType.3.106.111.101.4.49.51.116.104 = nonVolatile(3)
schedRowStatus.3.106.111.101.4.49.51.116.104 = active(1)all the remaining schedTable columns are status info and not shown here 💅
5.3. Turning an interface off during weekends 🌈
this example is about taking a network interface down over the weekend 🌙 it assumes the interface table (ifTable) of the IF-MIB [18] exists in the context identified by an empty string, and the interface's index is ifIndex = 6.
the scheduling entry that takes the interface down every Friday evening at 20:30 (8:30 pm) is owned by schedOwner = "bob" and named schedName = "if-off". its instance identifier is 3.98.111.98.6.105.102.45.111.102.102.
schedWeekDay.3.98.111.98.6.105.102.45.111.102.102 = { friday }
schedMonth.3.98.111.98.6.105.102.45.111.102.102 = {
january, february, march, april, may, june,
july, august, september, october, november, december
}
schedDay.3.98.111.98.6.105.102.45.111.102.102 = {
d1, d2, d3, d4, d5, d6, d7, d8, d9, d10,
d11, d12, d13, d14, d15, d16, d17, d18, d19, d20,
d21, d22, d23, d24, d25, d26, d27, d28, d29, d30, d31
}
schedHour.3.98.111.98.6.105.102.45.111.102.102 = { h20 }
schedMinute.3.98.111.98.6.105.102.45.111.102.102 = { m30 }
schedValue.3.98.111.98.6.105.102.45.111.102.102 = down(2)
schedContextName.3.98.111.98.6.105.102.45.111.102.102 = ""
schedVariable.3.98.111.98.6.105.102.45.111.102.102 =
ifAdminStatus.6
schedType.3.98.111.98.6.105.102.45.111.102.102 = calendar(2)
schedAdminStatus.3.98.111.98.6.105.102.45.111.102.102 = enabled(1)
schedStorageType.3.98.111.98.6.105.102.45.111.102.102 =
nonVolatile(3)
schedRowStatus.3.98.111.98.6.105.102.45.111.102.102 = active(1)then the "if-on" scheduling entry brings the interface back up. it's owned by schedOwner = "bob" and named schedName = "if-on", with instance identifier 3.98.111.98.5.105.102.45.111.110 ✨ this is the entry in the schedTable that brings the interface up again every Monday morning at 5:30:
schedWeekDay.3.98.111.98.5.105.102.45.111.110 = { monday }
schedMonth.3.98.111.98.5.105.102.45.111.110 = {
january, february, march, april, may, june,
july, august, september, october, november, december
}
schedDay.3.98.111.98.5.105.102.45.111.110 = {
d1, d2, d3, d4, d5, d6, d7, d8, d9, d10,
d11, d12, d13, d14, d15, d16, d17, d18, d19, d20,
d21, d22, d23, d24, d25, d26, d27, d28, d29, d30, d31
}
schedHour.3.98.111.98.5.105.102.45.111.110 = { h5 }
schedMinute.3.98.111.98.5.105.102.45.111.110 = { m30 }
schedValue.3.98.111.98.5.105.102.45.111.110 = up(1)
schedContextName.3.98.111.98.5.105.102.45.111.110 = ""
schedVariable.3.98.111.98.5.105.102.45.111.110 = ifAdminStatus.6
schedType.3.98.111.98.5.105.102.45.111.110 = calendar(2)
schedAdminStatus.3.98.111.98.5.105.102.45.111.110 = enabled(1)
schedStorageType.3.98.111.98.5.105.102.45.111.110 = nonVolatile(3)
schedRowStatus.3.98.111.98.5.105.102.45.111.110 = active(1)you could use a similar setup to control other schedules too 🫶 for example, the "if-on" and "if-off" entries could be changed to enable and disable the periodic scheduler from the first example. iykyk 🍓
6. Security Considerations 💀
ok bestie, this part is serious, so let's get into it 🙈 scheduled SNMP set operations must use the security credentials that were present when the matching row in the scheduling entry was created. so an implementation must record and keep the credentials for every scheduling entry.
an implementation must also make sure access control rules get applied when the set operation runs. this happens by calling the isAccessAllowed abstract service interface defined in RFC 2271 [1]:
statusInformation = -- success or errorIndication
isAccessAllowed(
IN securityModel -- Security Model in use
IN securityName -- principal who wants to access
IN securityLevel -- Level of Security
IN viewType -- read, write, or notify view
IN contextName -- context containing variableName
IN variableName -- OID for the managed object
)the securityModel, securityName and securityLevel parameters are set to the values that were recorded when the scheduling entry was created. the viewType parameter must select the write view, and the contextName and variableName parameters come from the schedContextName and schedVariableName values of the scheduling entry 🔐
this MIB only lets scheduled actions touch objects in the local MIB. that avoids security problems with delegating access rights. BUT a user of this MIB might own schedules that trigger far in the future, and that can cause security risks if the security administrator didn't properly update the access control lists when a user was withdrawn from an SNMP engine. so entries in the schedTable SHOULD be cleaned up whenever a user is removed from an SNMP engine 🚨
to make life easier for a security admin setting up access control with the View-Based Access Control Model (VACM) defined in RFC 2275 [15], the initial index works as an "owner index" for tables where several users might need to create or change entries on their own. that initial index has the SnmpAdminString syntax, so it can easily be mapped to a securityName or groupName as defined in VACM, following whatever security policy is in place 💜
all entries in related tables that belong to a particular user will have the same value for this initial index. for one user's entries in a given table, the object identifiers for that information share the same subidentifiers (except for the "column" subidentifier) right up to the end of the encoded owner index. to let VACM permit access to this part of the table, you'd create vacmViewTreeFamilyTable entries whose vacmViewTreeFamilySubtree value includes the owner index portion, and whose vacmViewTreeFamilyMask "wildcards" the column subidentifier. more elaborate configurations are possible too ✨
7. Intellectual Property 📜
the IETF doesn't take a position on whether any intellectual property or other rights claimed to apply to the technology in this document are valid or in scope, or whether any license for those rights would or wouldn't be available. it also doesn't say it has tried to find any such rights. info about the IETF's procedures for rights in standards-track and standards-related documents can be found in BCP-11. copies of rights claims made available for publication, and any assurances of licenses to be made available, or the results of an attempt to get a general license or permission for implementers or users of this spec to use those proprietary rights, can be requested from the IETF Secretariat 🌸
the IETF invites anyone interested to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that might cover technology required to practice this standard. send that info to the IETF Executive Director 🫶
8. Acknowledgments 🌷
this document was produced by the IETF Distributed Management (DISMAN) working group 👑
9. References 📚
Okay bestie, this is the bibliography, and it's giving research paper energy 🤓✨ Every single source stays exactly as written, so you can go check them yourself.
- [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, January 1998.
- [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990.
- [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
- [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
- [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
- [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
- [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
- [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990.
- [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
- [10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
- [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, January 1998.
- [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, January 1998.
- [13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", January 1996.
- [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2273, January 1998
- [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, January 1998.
- [16] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996.
- [17] Levi, D. and J. Schoenwaelder, "Definitions of Managed Objects for the Delegation of Management Scripts", RFC 2592, May 1999.
- [18] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB using SMIv2", RFC 2233, November 1997.
- [19] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
10. Editors' Addresses 💌
Here's where you can find the editors, bestie! 🦋
David B. Levi
Nortel Networks
4401 Great America Parkway
Santa Clara, CA 95052-8185
U.S.A.
Phone: +1 423 686 0432
EMail: dlevi@nortelnetworks.com
Juergen Schoenwaelder
TU Braunschweig
Bueltenweg 74/75
38106 Braunschweig
Germany
Phone: +49 531 391-3283
EMail: schoenw@ibr.cs.tu-bs.de11. Full Copyright Statement ⚖️
This part is legal stuff, so it stays word-for-word, no cap 🫶 The Internet Society owns the copyright, and the rules below say what you can and can't do with the document.
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🌈
Funding for the RFC Editor function is currently provided by the Internet Society. So the people keeping these documents tidy are supported by the Internet Society, and that's a whole mood 💜 Thank you for reading all five parts with me, bestie, you're literally the best networking girlie I know 👑✨
📦 where this page comes from
- ietf: rfc2591 1999-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms