idnits 2.17.1 draft-ietf-disman-schedule-mib-05.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1146 has weird spacing: '...for the purpo...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1998) is 9385 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '16' is defined on line 1109, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2271 (ref. '1') (Obsoleted by RFC 2571) ** Downref: Normative reference to an Informational RFC: RFC 1215 (ref. '4') ** Obsolete normative reference: RFC 1902 (ref. '5') (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (ref. '6') (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1904 (ref. '7') (Obsoleted by RFC 2580) ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '8') ** Downref: Normative reference to an Historic RFC: RFC 1901 (ref. '9') ** Obsolete normative reference: RFC 1906 (ref. '10') (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2272 (ref. '11') (Obsoleted by RFC 2572) ** Obsolete normative reference: RFC 2274 (ref. '12') (Obsoleted by RFC 2574) ** Obsolete normative reference: RFC 1905 (ref. '13') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2273 (ref. '14') (Obsoleted by RFC 2573) ** Obsolete normative reference: RFC 2275 (ref. '15') (Obsoleted by RFC 2575) ** Obsolete normative reference: RFC 2028 (ref. '16') (Obsoleted by RFC 9281) -- Possible downref: Non-RFC (?) normative reference: ref. '17' ** Obsolete normative reference: RFC 2233 (ref. '18') (Obsoleted by RFC 2863) Summary: 26 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Schedule MIB August 1998 4 Definitions of Managed Objects for 5 Scheduling Management Operations 7 August 7, 1998 9 11 David B. Levi 12 SNMP Research, Inc. 13 levi@snmp.com 15 Juergen Schoenwaelder 16 TU Braunschweig 17 schoenw@ibr.cs.tu-bs.de 19 Status of this Memo 21 This document is an Internet-Draft. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as ``work in progress.'' 31 To view the entire list of current Internet-Drafts, please check the 32 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 33 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 34 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 35 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 37 Distribution of this document is unlimited. Please send comments to 38 the Distributed Management Working Group, . 40 Copyright Notice 42 Copyright (C) The Internet Society (1998). All Rights Reserved. 44 1. Abstract 46 This memo defines an experimental portion of the Management 47 Information Base (MIB) for use with network management protocols in 48 the Internet community. In particular, it describes a set of managed 49 objects that are used to schedule management operations periodically 50 or at specified dates and times. 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC 2119. 56 This memo does not specify a standard for the Internet community. 58 2. The SNMP Management Framework 60 The SNMP Management Framework presently consists of five major 61 components: 63 o An overall architecture, described in RFC 2271 [1]. 65 o Mechanisms for describing and naming objects and events for the 66 purpose of management. The first version of this Structure of 67 Management Information (SMI) is called SMIv1 and described in 68 RFC 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version, 69 called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 70 1904 [7]. 72 o Message protocols for transferring management information. The 73 first version of the SNMP message protocol is called SNMPv1 and 74 described in RFC 1157 [8]. A second version of the SNMP message 75 protocol, which is not an Internet standards track protocol, is 76 called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. 77 The third version of the message protocol is called SNMPv3 and 78 described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. 80 o Protocol operations for accessing management information. The 81 first set of protocol operations and associated PDU formats is 82 described in RFC 1157 [8]. A second set of protocol operations 83 and associated PDU formats is described in RFC 1905 [13]. 85 o A set of fundamental applications described in RFC 2273 [14] and 86 the view-based access control mechanism described in RFC 2275 87 [15]. 89 Managed objects are accessed via a virtual information store, termed 90 the Management Information Base or MIB. Objects in the MIB are 91 defined using the mechanisms defined in the SMI. 93 This memo specifies a MIB module that is compliant to the SMIv2. A 94 MIB conforming to the SMIv1 can be produced through the appropriate 95 translations. The resulting translated MIB must be semantically 96 equivalent, except where objects or events are omitted because no 97 translation is possible (use of Counter64). Some machine readable 98 information in SMIv2 will be converted into textual descriptions in 99 SMIv1 during the translation process. However, this loss of machine 100 readable information is not considered to change the semantics of the 101 MIB. 103 3. Overview 105 The MIB defined in this memo provides scheduling of actions 106 periodically or at specified dates and times. The actions can be used 107 to realize on-duty / off-duty schedules or to trigger management 108 functions in a distributed management application. 110 Schedules can be enabled or disabled by modifying a control object. 111 This allows pre-configured schedules which are activated or de- 112 activated by some other management functions. 114 The term `scheduler' is used throughout this memo to refer to the 115 entity which implements the scheduling MIB and which invokes the 116 actions at the specified points in time. 118 3.1. Periodic Schedules 120 Periodic schedules are based on fixed time periods between the 121 initiation of scheduled actions. Periodic schedules are defined by 122 specifying the number of seconds between two initiations. The time 123 needed to complete the action is usually not known by the scheduler 124 and does therefore not influence the next scheduling point. 126 Implementations must guarantee that action invocations will not occur 127 before their next scheduled time. However, implementations may be 128 forced to delay invocations in the face of local constraints (e.g., a 129 heavy load on higher-priority tasks). An accumulation of such delays 130 would result in a drift of the scheduling interval with respect to 131 time, and should be avoided. 133 Scheduled actions collecting statistical data should retrieve time 134 stamps from the data source and not rely on the accuracy of the 135 periodic scheduler in order to obtain accurate statistics. 137 3.2. Calendar Schedules 139 Calendar schedules trigger scheduled actions at specified days of the 140 week and days of the month. Calendar schedules are therefore aware of 141 the notion of months, days, weekdays, hours and minutes. 143 It is possible to specify multiple values for each calendar item. 144 This provides a mechanism for defining complex schedules. For 145 example, a schedule could be defined which triggers an action every 146 15 minutes on a given weekday. 148 Months, days and weekdays are specified using the objects schedMonth, 149 schedDay and schedWeekDay of type BITS. Setting multiple bits to one 150 in these objects causes an OR operation. For example, setting the 151 bits monday(1) and friday(5) in schedWeekDay restricts the schedule 152 to Mondays and Fridays. 154 The bit fields for schedMonth, schedDay and schedWeekDay are combined 155 using an AND operation. For example, setting the bits june(5) and 156 july(6) in schedMonth and combining it with the bits monday(1) and 157 friday(5) set in schedWeekDay will result in a schedule which is 158 restricted to every Monday and Friday in the months June and July. 159 Wildcarding of calendar items is achieved by setting all bits to one. 161 It is possible to define calendar schedules that will never trigger 162 an action. For example, one can define a calendar schedule which 163 should trigger an action on February 31st. Schedules like this will 164 simply be ignored by the scheduler. 166 Finally, calendar schedules are always expressed in local time. A 167 scalar, schedLocalTime is provided so that a manager can retrieve the 168 notion of local time and the offset to GMT time. 170 3.3. One-shot Schedules 172 One-shot Schedules are similar to calendar schedules. The difference 173 between a calendar schedule and a one-shot schedule is that a one- 174 shot schedule will automatically disable itself once an action has 175 been invoked. 177 3.4. Time Transitions 179 When a system's notion of time is changed for some reason, 180 implementations of the Schedule MIB must schedule actions 181 differently. One example of a change to a system's notion of time is 182 when a daylight savings time transition occurs. 184 There are two possible situations when a time transition occurs. 185 First, time may be set backwards, in which case particular times will 186 appear to occur twice within the same day. These are called 187 'ambiguous times'. Second, time may be set forwards, in which case 188 particular times will appear to not occur within a day. This are 189 called 'nonexistent times'. 191 When an action is configured in the Schedule MIB to occur at an 192 ambiguous time during a time transition, the action should only be 193 invoked at the first occurence of the ambiguous time. For example, 194 if an action is scheduled to occur at 2:00 am, and a time transition 195 occurs at 3:00 am which sets the clock back to 2:00 am, the action 196 should only be invoked at the first occurence of 2:00 am. 198 When an action is configured in the Schedule MIB to occur at a 199 nonexistent time, the action should be invoked immediately upon a 200 time transition. If multiple actions are invoked in this way, they 201 should be invoked in the order in which they normally would be 202 invoked had the time transition not occured. For example, if an 203 action (a) is scheduled at 2:05 am and another action (b) at 2:10 am, 204 then both actions should be invoked at 3:00 am in the order (a),(b) 205 if the time jumps forward from 2:00 am to 3:00 am. 207 3.5. Actions 209 Scheduled actions are modeled by SNMP set operations on local MIB 210 variables. Scheduled actions described in this MIB are further 211 restricted to objects of type INTEGER. This restriction does not 212 limit the usefulness of the MIB. Simple schedules such as on-duty / 213 off-duty schedules for resources that have a status MIB object (e.g. 214 ifAdminStatus) are possible. 216 More complex actions can be realized by triggering a management 217 script which is responsible for performing complex state transitions. 218 A management script can also be used to perform SNMP set operations 219 on remote SNMP engines. 221 4. Definitions 223 DISMAN-SCHEDULE-MIB DEFINITIONS ::= BEGIN 225 IMPORTS 226 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, 227 Integer32, Unsigned32, Counter32, experimental 228 FROM SNMPv2-SMI 230 TEXTUAL-CONVENTION, 231 DateAndTime, RowStatus, StorageType, VariablePointer 232 FROM SNMPv2-TC 234 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 235 FROM SNMPv2-CONF 237 SnmpAdminString 238 FROM SNMP-FRAMEWORK-MIB; 240 schedMIB MODULE-IDENTITY 241 LAST-UPDATED "9808071800Z" 242 ORGANIZATION "IETF DISMAN Working Group" 243 CONTACT-INFO 244 "David B. Levi 245 SNMP Research, Inc. 246 3001 Kimberlin Heights Road 247 Knoxville, TN 37920-9716 248 U.S.A. 249 Tel: +1 423 573 1434 250 E-mail: levi@snmp.com 252 Juergen Schoenwaelder 253 TU Braunschweig 254 Bueltenweg 74/75 255 38106 Braunschweig 256 Germany 257 Tel: +49-531-391-3283 258 E-mail: schoenw@ibr.cs.tu-bs.de" 259 DESCRIPTION 260 "This MIB module defines a MIB which provides mechanisms to 261 schedule SNMP set operations periodically or at specific 262 points in time." 263 -- XXX Replace with real registration number from IANA. Note, the 264 -- XXX IMPORTS must be updated when the real number is assigned. 265 -- ::= { mib-2 XXXX } 266 ::= { experimental 6789 } 268 -- 269 -- The various groups defined within this MIB definition: 270 -- 272 schedObjects OBJECT IDENTIFIER ::= { schedMIB 1 } 273 schedNotifications OBJECT IDENTIFIER ::= { schedMIB 2 } 274 schedConformance OBJECT IDENTIFIER ::= { schedMIB 3 } 276 -- 277 -- Textual Conventions: 278 -- 280 SnmpPduErrorStatus ::= TEXTUAL-CONVENTION 281 STATUS current 282 DESCRIPTION 283 "This TC enumerates the SNMPv1 and SNMPv2 PDU error status 284 codes as defined in RFC 1157 and RFC 1905. It also adds a 285 pseudo error status code `noResponse' which indicates a 286 timeout condition." 287 SYNTAX INTEGER { 288 noResponse(-1), 289 noError(0), 290 tooBig(1), 291 noSuchName(2), 292 badValue(3), 293 readOnly(4), 294 genErr(5), 295 noAccess(6), 296 wrongType(7), 297 wrongLength(8), 298 wrongEncoding(9), 299 wrongValue(10), 300 noCreation(11), 301 inconsistentValue(12), 302 resourceUnavailable(13), 303 commitFailed(14), 304 undoFailed(15), 305 authorizationError(16), 306 notWritable(17), 307 inconsistentName(18) 308 } 310 -- 311 -- Some scalars which provide information about the local time zone. 312 -- 314 schedLocalTime OBJECT-TYPE 315 SYNTAX DateAndTime (SIZE (11)) 316 MAX-ACCESS read-only 317 STATUS current 318 DESCRIPTION 319 "The local time used by the scheduler. Schedules which refer 320 to calendar time will use the local time indicated by this 321 object. An implementation MUST return all 11 bytes of the 322 DateAndTime textual-convention so that a manager may 323 retrieve the offset from GMT time." 324 ::= { schedObjects 1 } 326 -- 327 -- The schedule table which controls the scheduler. 328 -- 330 schedTable OBJECT-TYPE 331 SYNTAX SEQUENCE OF SchedEntry 332 MAX-ACCESS not-accessible 333 STATUS current 334 DESCRIPTION 335 "This table defines scheduled actions triggered by 336 SNMP set operations." 337 ::= { schedObjects 2 } 339 schedEntry OBJECT-TYPE 340 SYNTAX SchedEntry 341 MAX-ACCESS not-accessible 342 STATUS current 343 DESCRIPTION 344 "An entry describing a particular scheduled action." 345 INDEX { schedOwner, schedName } 346 ::= { schedTable 1 } 348 SchedEntry ::= SEQUENCE { 349 schedOwner SnmpAdminString, 350 schedName SnmpAdminString, 351 schedDescr SnmpAdminString, 352 schedInterval Unsigned32, 353 schedWeekDay BITS, 354 schedMonth BITS, 355 schedDay BITS, 356 schedHour BITS, 357 schedMinute BITS, 358 schedContextName SnmpAdminString, 359 schedVariable VariablePointer, 360 schedValue Integer32, 361 schedType INTEGER, 362 schedAdminStatus INTEGER, 363 schedOperStatus INTEGER, 364 schedFailures Counter32, 365 schedLastFailure SnmpPduErrorStatus, 366 schedLastFailed DateAndTime, 367 schedStorageType StorageType, 368 schedRowStatus RowStatus 369 } 371 schedOwner OBJECT-TYPE 372 SYNTAX SnmpAdminString (SIZE(0..32)) 373 MAX-ACCESS not-accessible 374 STATUS current 375 DESCRIPTION 376 "The owner of this scheduling entry. The exact semantics of 377 this string are subject to the security policy defined by 378 the security administrator." 379 ::= { schedEntry 1 } 381 schedName OBJECT-TYPE 382 SYNTAX SnmpAdminString (SIZE(1..32)) 383 MAX-ACCESS not-accessible 384 STATUS current 385 DESCRIPTION 386 "The locally-unique, administratively assigned name for this 387 scheduling entry. This object allows a schedOwner to have 388 multiple entries in the schedTable." 389 ::= { schedEntry 2 } 391 schedDescr OBJECT-TYPE 392 SYNTAX SnmpAdminString 393 MAX-ACCESS read-create 394 STATUS current 395 DESCRIPTION 396 "The human readable description of the purpose of this 397 scheduling entry." 398 DEFVAL { ''H } 399 ::= { schedEntry 3 } 401 schedInterval OBJECT-TYPE 402 SYNTAX Unsigned32 403 UNITS "seconds" 404 MAX-ACCESS read-create 405 STATUS current 406 DESCRIPTION 407 "The number of seconds between two action invocations of 408 a periodic scheduler. Implementations must guarantee 409 that action invocations will not occur before at least 410 schedInterval seconds have passed. 412 The scheduler must ignore all periodic schedules that 413 have a schedInterval value of 0. A periodic schedule 414 with a scheduling interval of 0 seconds will therefore 415 never invoke an action. 417 Implementations may be forced to delay invocations in the 418 face of local constraints. A scheduled management function 419 should therefore not rely on the accuracy provided by the 420 scheduler implementation." 421 DEFVAL { 0 } 422 ::= { schedEntry 4 } 424 schedWeekDay OBJECT-TYPE 425 SYNTAX BITS { 426 sunday(0), 427 monday(1), 428 tuesday(2), 429 wednesday(3), 430 thursday(4), 431 friday(5), 432 saturday(6) 433 } 434 MAX-ACCESS read-create 435 STATUS current 436 DESCRIPTION 437 "The set of weekdays on which the scheduled action should 438 take place. Setting multiple bits will include several 439 weekdays in the set of possible weekdays for this schedule. 440 Setting all bits will cause the scheduler to ignore the 441 weekday." 442 DEFVAL { {} } 443 ::= { schedEntry 5 } 445 schedMonth OBJECT-TYPE 446 SYNTAX BITS { 447 january(0), 448 february(1), 449 march(2), 450 april(3), 451 may(4), 452 june(5), 453 july(6), 454 august(7), 455 september(8), 456 october(9), 457 november(10), 458 december(11) 459 } 460 MAX-ACCESS read-create 461 STATUS current 462 DESCRIPTION 463 "The set of months during which the scheduled action should 464 take place. Setting multiple bits will include several 465 months in the set of possible months for this schedule. 466 Setting all bits will cause the scheduler to ignore the 467 month." 468 DEFVAL { {} } 469 ::= { schedEntry 6 } 471 schedDay OBJECT-TYPE 472 SYNTAX BITS { 473 d1(0), d2(1), d3(2), d4(3), d5(4), 474 d6(5), d7(6), d8(7), d9(8), d10(9), 475 d11(10), d12(11), d13(12), d14(13), d15(14), 476 d16(15), d17(16), d18(17), d19(18), d20(19), 477 d21(20), d22(21), d23(22), d24(23), d25(24), 478 d26(25), d27(26), d28(27), d29(28), d30(29), 479 d31(30), 480 r1(31), r2(32), r3(33), r4(34), r5(35), 481 r6(36), r7(37), r8(38), r9(39), r10(40), 482 r11(41), r12(42), r13(43), r14(44), r15(45), 483 r16(46), r17(47), r18(48), r19(49), r20(50), 484 r21(51), r22(52), r23(53), r24(54), r25(55), 485 r26(56), r27(57), r28(58), r29(59), r30(60), 486 r31(61) 487 } 488 MAX-ACCESS read-create 489 STATUS current 490 DESCRIPTION 491 "The set of days in a month on which a scheduled action 492 should take place. There are two sets of bits one can 493 use to define the day within a month: 495 Enumerations starting with the letter 'd' indicate a 496 day in a month relative to the first day of a month. 497 The first day of the month can therefore be specified 498 by setting the bit d1(0) and d31(30) means the last 499 day of a month with 31 days. 501 Enumerations starting with the letter 'r' indicate a 502 day in a month in reverse order, relative to the last 503 day of a month. The last day in the month can therefore 504 be specified by setting the bit r1(31) and r31(61) means 505 the first day of a month with 31 days. 507 Setting multiple bits will include several days in the set 508 of possible days for this schedule. Setting all bits will 509 cause the scheduler to ignore the day within a month. 510 Setting all bits starting with the letter 'd' or the 511 letter 'r' will also cause the scheduler to ignore the 512 day within a month." 513 DEFVAL { {} } 514 ::= { schedEntry 7 } 516 schedHour OBJECT-TYPE 517 SYNTAX BITS { 518 h0(0), h1(1), h2(2), h3(3), h4(4), 519 h5(5), h6(6), h7(7), h8(8), h9(9), 520 h10(10), h11(11), h12(12), h13(13), h14(14), 521 h15(15), h16(16), h17(17), h18(18), h19(19), 522 h20(20), h21(21), h22(22), h23(23) 523 } 524 MAX-ACCESS read-create 525 STATUS current 526 DESCRIPTION 527 "The set of hours within a day during which the scheduled 528 action should take place." 529 DEFVAL { {} } 530 ::= { schedEntry 8 } 532 schedMinute OBJECT-TYPE 533 SYNTAX BITS { 534 m0(0), m1(1), m2(2), m3(3), m4(4), 535 m5(5), m6(6), m7(7), m8(8), m9(9), 536 m10(10), m11(11), m12(12), m13(13), m14(14), 537 m15(15), m16(16), m17(17), m18(18), m19(19), 538 m20(20), m21(21), m22(22), m23(23), m24(24), 539 m25(25), m26(26), m27(27), m28(28), m29(29), 540 m30(30), m31(31), m32(32), m33(33), m34(34), 541 m35(35), m36(36), m37(37), m38(38), m39(39), 542 m40(40), m41(41), m42(42), m43(43), m44(44), 543 m45(45), m46(46), m47(47), m48(48), m49(49), 544 m50(50), m51(51), m52(52), m53(53), m54(54), 545 m55(55), m56(56), m57(57), m58(58), m59(59) 546 } 547 MAX-ACCESS read-create 548 STATUS current 549 DESCRIPTION 550 "The set of minutes within an hour when the scheduled action 551 should take place." 552 DEFVAL { {} } 553 ::= { schedEntry 9 } 555 schedContextName OBJECT-TYPE 556 SYNTAX SnmpAdminString (SIZE(0..32)) 557 MAX-ACCESS read-create 558 STATUS current 559 DESCRIPTION 560 "The context which contains the local MIB variable pointed 561 to by schedVariable." 562 ::= { schedEntry 10 } 564 schedVariable OBJECT-TYPE 565 SYNTAX VariablePointer 566 MAX-ACCESS read-create 567 STATUS current 568 DESCRIPTION 569 "An object identifier pointing to a local MIB variable 570 which resolves to an ASN.1 primitive type of INTEGER." 571 ::= { schedEntry 11 } 573 schedValue OBJECT-TYPE 574 SYNTAX Integer32 575 MAX-ACCESS read-create 576 STATUS current 577 DESCRIPTION 578 "The value which is written to the MIB object pointed to by 579 schedVariable when the scheduler invokes an action. The 580 implementation shall enforce the use of access control 581 rules when performing the set operation on schedVariable. 582 This is accomplished by calling the isAccessAllowed abstract 583 service interface as defined in RFC 2271." 584 ::= { schedEntry 12 } 586 schedType OBJECT-TYPE 587 SYNTAX INTEGER { 588 periodic(1), 589 calendar(2), 590 oneshot(3) 591 } 592 MAX-ACCESS read-create 593 STATUS current 594 DESCRIPTION 595 "The type of this schedule. The value periodic(1) indicates 596 that this entry specifies a periodic schedule. A periodic 597 schedule is defined by the value of schedInterval. The values 598 of schedWeekDay, schedMonth, schedDay, schedHour and 599 schedMinute are ignored. 601 The value calendar(2) indicates that this entry describes a 602 calendar schedule. A calendar schedule is defined by the 603 values of schedWeekDay, schedMonth, schedDay, schedHour and 604 schedMinute. The value of schedInterval is ignored. A 605 calendar schedule will trigger on all local times that 606 satisfy the bits set in schedWeekDay, schedMonth, schedDay, 607 schedHour and schedMinute. 609 The value oneshot(3) indicates that this entry describes a 610 one-shot schedule. A one-shot schedule is similar to a calendar 611 schedule with the additional feature that it disables itself 612 by changing in the `finished' schedOperStatus once the 613 schedule triggers an action. 615 Changing a schedule's type is equivalent to deleting the 616 old-type schedule and creating a new-type one." 617 DEFVAL { periodic } 618 ::= { schedEntry 13 } 620 schedAdminStatus OBJECT-TYPE 621 SYNTAX INTEGER { 622 enabled(1), 623 disabled(2) 624 } 625 MAX-ACCESS read-create 626 STATUS current 627 DESCRIPTION 628 "The desired state of the schedule." 629 DEFVAL { disabled } 630 ::= { schedEntry 14 } 632 schedOperStatus OBJECT-TYPE 633 SYNTAX INTEGER { 634 enabled(1), 635 disabled(2), 636 finished(3) 637 } 638 MAX-ACCESS read-only 639 STATUS current 640 DESCRIPTION 641 "The current operational state of this schedule. The state 642 enabled(1) indicates this entry is active and that the 643 scheduler will invoke actions at appropriate times. The 644 disabled(2) state indicates that this entry is currently 645 inactive and ignored by the scheduler. The finished(3) 646 state indicates that the schedule has ended. Schedules 647 in the finished(3) state are ignored by the scheduler. 648 A one-shot schedule enters the finished(3) state when it 649 deactivates itself." 650 ::= { schedEntry 15 } 652 schedFailures OBJECT-TYPE 653 SYNTAX Counter32 654 MAX-ACCESS read-only 655 STATUS current 656 DESCRIPTION 657 "This variable counts the number of failures while invoking 658 the scheduled action." 659 ::= { schedEntry 16 } 661 schedLastFailure OBJECT-TYPE 662 SYNTAX SnmpPduErrorStatus 663 MAX-ACCESS read-only 664 STATUS current 665 DESCRIPTION 666 "The most recent error that occured during the invocation of 667 a scheduled action. The value noError(0) is returned 668 if no errors have occurred yet." 669 DEFVAL { noError } 670 ::= { schedEntry 17 } 672 schedLastFailed OBJECT-TYPE 673 SYNTAX DateAndTime 674 MAX-ACCESS read-only 675 STATUS current 676 DESCRIPTION 677 "The date and time when the most recent failure occured. The 678 value '0000000000000000'H is returned if no failure occured 679 since the last re-initialization of the scheduler." 680 DEFVAL { '0000000000000000'H } 681 ::= { schedEntry 18 } 683 schedStorageType OBJECT-TYPE 684 SYNTAX StorageType 685 MAX-ACCESS read-create 686 STATUS current 687 DESCRIPTION 688 "This object defines whether this scheduled action is kept in 689 volatile storage and lost upon reboot or if this row is 690 backed up by non-volatile or permanent storage. 692 Conceptual rows having the value `permanent' must allow 693 write access to the columnar objects schedDescr, 694 schedInterval, schedContextName, schedVariable, schedValue, 695 and schedAdminStatus. If an implementation supports the 696 schedCalendarGroup, write access must be also allowed to 697 the columnar objects schedWeekDay, schedMonth, schedDay, 698 schedHour, schedMinute." 699 DEFVAL { volatile } 700 ::= { schedEntry 19 } 702 schedRowStatus OBJECT-TYPE 703 SYNTAX RowStatus 704 MAX-ACCESS read-create 705 STATUS current 706 DESCRIPTION 707 "The status of this scheduled action. A control that allows 708 entries to be added and removed from this table. 710 The miminum number of objects that need to be set during 711 row creation before a row can be set to `active' are 712 schedContextName, schedVariable and schedValue." 713 ::= { schedEntry 20 } 715 -- 716 -- Notifications that are emitted to indicate failures. The definition 717 -- of schedTraps makes notification registrations reversible. 718 -- 720 schedTraps OBJECT IDENTIFIER ::= { schedNotifications 0 } 722 schedActionFailure NOTIFICATION-TYPE 723 OBJECTS { schedLastFailure, schedLastFailed } 724 STATUS current 725 DESCRIPTION 726 "This notification is generated whenever the invocation of a 727 scheduled action fails." 728 ::= { schedTraps 1 } 730 -- conformance information 732 schedCompliances OBJECT IDENTIFIER ::= { schedConformance 1 } 733 schedGroups OBJECT IDENTIFIER ::= { schedConformance 2 } 735 -- compliance statements 737 schedCompliance MODULE-COMPLIANCE 738 STATUS current 739 DESCRIPTION 740 "The compliance statement for SNMP entities which implement 741 the scheduling MIB." 742 MODULE -- this module 743 MANDATORY-GROUPS { 744 schedGroup, schedNotificationsGroup 745 } 746 GROUP schedCalendarGroup 747 DESCRIPTION 748 "The schedCalendarGroup is mandatory only for those 749 implementations that support calendar based schedules." 750 OBJECT schedType 751 DESCRIPTION 752 "The values calendar(2) or oneshot(3) are not valid for 753 implementations that do not implement the 754 schedCalendarGroup. Such an implementation must return 755 inconsistentValue error responses for attempts to set 756 schedAdminStatus to calendar(2) or oneshot(3)." 757 ::= { schedCompliances 1 } 759 schedGroup OBJECT-GROUP 760 OBJECTS { 761 schedDescr, 762 schedInterval, 763 schedContextName, 764 schedVariable, 765 schedValue, 766 schedType, 767 schedAdminStatus, 768 schedOperStatus, 769 schedFailures, 770 schedLastFailure, 771 schedLastFailed, 772 schedStorageType, 773 schedRowStatus 774 } 775 STATUS current 776 DESCRIPTION 777 "A collection of objects providing scheduling capabilities." 778 ::= { schedGroups 1 } 780 schedCalendarGroup OBJECT-GROUP 781 OBJECTS { 782 schedLocalTime, 783 schedWeekDay, 784 schedMonth, 785 schedDay, 786 schedHour, 787 schedMinute 788 } 789 STATUS current 790 DESCRIPTION 791 "A collection of objects providing calendar based schedules." 792 ::= { schedGroups 2 } 794 schedNotificationsGroup NOTIFICATION-GROUP 795 NOTIFICATIONS { 796 schedActionFailure 797 } 798 STATUS current 799 DESCRIPTION 800 "The notifications emitted by the scheduler." 801 ::= { schedGroups 3 } 803 END 805 5. Usage Examples 807 This section presents some examples how the scheduling MIB can be 808 used to schedule scripts with the Script MIB [17] or to realize on- 809 duty/off-duty schedules by modifying status objects of other MIB 810 modules. 812 5.1. Starting a script to ping devices every 20 minutes 814 It is assumed that the schedule entry is owned by schedOwner = "joe" 815 and its name is schedName = "ping". The instance identifier for the 816 scheduling entry is therefore 3.106.111.101.4.112.105.110.103. 818 It is further assumed that the smLaunchTable entry is owned by 819 smLaunchOwner = "joe" and its name is smLaunchName = "ping-devs". The 820 complete object identifier for the smLaunchStart object is therefore 821 smLaunchStart.3.106.111.101.9.112.105.110.103.45.100.101.118.115. The 822 script lives in the context identified by the string "engine1". 824 The configuration of the scheduler entry which presses the launch 825 button every 20 minutes would look as follows: 827 schedInterval.3.106.111.101.4.112.105.110.103 = 1200 829 schedValue.3.106.111.101.4.112.105.110.103 = 0 830 schedContextName.3.106.111.101.4.112.105.110.103 = "engine1" 831 schedVariable.3.106.111.101.4.112.105.110.103 = 832 smLaunchStart.3.106.111.101.9.112.105.110.103.45.100.101.118.115 834 schedType.3.106.111.101.4.112.105.110.103 = periodic(1) 835 schedAdminStatus.3.106.111.101.4.112.105.110.103 = enabled(1) 836 schedStorageType.3.106.111.101.4.112.105.110.103 = nonVolatile(3) 837 schedRowStatus.3.106.111.101.4.112.105.110.103 = active(1) 839 All the remaining columns in the schedTable represent status 840 information and are not shown here. 842 5.2. Starting a script at the next Friday the 13th 844 It is assumed that the schedule entry is owned by schedOwner = "joe" 845 and its name is schedName = "13th". The instance identifier for the 846 scheduling entry is therefore 3.106.111.101.4.49.51.116.104. 848 It is further assumed that the smLaunchTable entry is owned by 849 smLaunchOwner = "joe" and its name is smLaunchName = "ghost". The 850 complete object identifier for the smLaunchStart object is therefore 851 smLaunchStart.3.106.111.101.5.103.104.111.115.116. The script lives 852 in the context identified by the string "engine1". 854 The configuration of the scheduler entry which presses the launch 855 button on every Friday 13th at midnight would look as follows: 857 schedWeekDay.3.106.111.101.4.49.51.116.104 = { friday } 858 schedMonth.3.106.111.101.4.49.51.116.104 = { 859 january, february, march, april, may, june, 860 july, august, september, october, november, december 861 } 862 schedDay.3.106.111.101.4.49.51.116.104 = { d13 } 863 schedHour.3.106.111.101.4.49.51.116.104 = { h0 } 864 schedMinute.3.106.111.101.4.49.51.116.104 = { m0 } 866 schedValue.3.106.111.101.4.49.51.116.104 = 0 867 schedContextName.3.106.111.101.4.49.51.116.104 = "engine1" 868 schedVariable.3.106.111.101.4.49.51.116.104 = 869 smLaunchStart.3.106.111.101.5.103.104.111.115.116 871 schedType.3.106.111.101.4.49.51.116.104 = oneshot(3) 872 schedAdminStatus.3.106.111.101.4.49.51.116.104 = enabled(2) 873 schedStorageType.3.106.111.101.4.49.51.116.104 = nonVolatile(3) 874 schedRowStatus.3.106.111.101.4.49.51.116.104 = active(1) 876 All the remaining columns in the schedTable represent status 877 information and are not shown here. 879 5.3. Turning an interface off during weekends 881 This example assumes that a network interface should be taken down 882 during weekends. The interface table (ifTable) of the IF-MIB [18] is 883 assumed to exist in the context identified by an empty string and the 884 index of the interface is ifIndex = 6. 886 The scheduling entry which brings the interface down on every Friday 887 evening at 20:30 (8:30 pm) is owned by schedOwner = "bob" and its 888 name is schedName = "if-off". The instance identifier for the 889 scheduling entry is therefore 3.98.111.98.6.105.102.45.111.102.102. 891 schedWeekDay.3.98.111.98.6.105.102.45.111.102.102 = { friday } 892 schedMonth.3.98.111.98.6.105.102.45.111.102.102 = { 893 january, february, march, april, may, june, 894 july, august, september, october, november, december 895 } 896 schedDay.3.98.111.98.6.105.102.45.111.102.102 = { 897 d1, d2, d3, d4, d5, d6, d7, d8, d9, d10, 898 d11, d12, d13, d14, d15, d16, d17, d18, d19, d20, 899 d21, d22, d23, d24, d25, d26, d27, d28, d29, d30, d31 900 } 901 schedHour.3.98.111.98.6.105.102.45.111.102.102 = { h20 } 902 schedMinute.3.98.111.98.6.105.102.45.111.102.102 = { m30 } 904 schedValue.3.98.111.98.6.105.102.45.111.102.102 = down(2) 905 schedContextName.3.98.111.98.6.105.102.45.111.102.102 = "" 906 schedVariable.3.98.111.98.6.105.102.45.111.102.102 = 907 ifAdminStatus.6 909 schedType.3.98.111.98.6.105.102.45.111.102.102 = calendar(2) 910 schedAdminStatus.3.98.111.98.6.105.102.45.111.102.102 = enabled(1) 911 schedStorageType.3.98.111.98.6.105.102.45.111.102.102 = 912 nonVolatile(3) 913 schedRowStatus.3.98.111.98.6.105.102.45.111.102.102 = active(1) 915 The scheduling entry which brings the interface up on every Monday 916 morning at 5:30 is owned by schedOwner = "bob" and its name is 917 schedName = "if-on". The instance identifier for the scheduling entry 918 is therefore 3.98.111.98.5.105.102.45.111.110. 920 The entry in the schedTable which brings the interface up again on 921 every Monday morning at 5:30 looks as follows: 923 schedWeekDay.3.98.111.98.5.105.102.45.111.110 = { monday } 924 schedMonth.3.98.111.98.5.105.102.45.111.110 = { 925 january, february, march, april, may, june, 926 july, august, september, october, november, december 927 } 928 schedDay.3.98.111.98.5.105.102.45.111.110 = { 929 d1, d2, d3, d4, d5, d6, d7, d8, d9, d10, 930 d11, d12, d13, d14, d15, d16, d17, d18, d19, d20, 931 d21, d22, d23, d24, d25, d26, d27, d28, d29, d30, d31 932 } 933 schedHour.3.98.111.98.5.105.102.45.111.110 = { h5 } 934 schedMinute.3.98.111.98.5.105.102.45.111.110 = { m30 } 936 schedValue.3.98.111.98.5.105.102.45.111.110 = up(1) 937 schedContextName.3.98.111.98.5.105.102.45.111.110 = "" 938 schedVariable.3.98.111.98.5.105.102.45.111.110 = ifAdminStatus.6 940 schedType.3.98.111.98.5.105.102.45.111.110 = calendar(2) 941 schedAdminStatus.3.98.111.98.5.105.102.45.111.110 = enabled(1) 942 schedStorageType.3.98.111.98.5.105.102.45.111.110 = nonVolatile(3) 943 schedRowStatus.3.98.111.98.5.105.102.45.111.110 = active(1) 945 A similar configuration could be used to control other schedules. For 946 example, one could change the "if-on" and "if-off" schedules to 947 enable and disable the periodic scheduler defined in the first 948 example. 950 6. Security Considerations 952 Scheduled SNMP set operations must use the security credentials that 953 were present when the corresponding row in the scheduling entry was 954 created. An implementation must therefore record and maintain the 955 credentials for every scheduling entry. 957 An implementation must ensure that access control rules are applied 958 when doing the set operation. This is accomplished by calling the 959 isAccessAllowed abstract service interface defined in RFC 2271 [1]: 961 statusInformation = -- success or errorIndication 962 isAccessAllowed( 963 IN securityModel -- Security Model in use 964 IN securityName -- principal who wants to access 965 IN securityLevel -- Level of Security 966 IN viewType -- read, write, or notify view 967 IN contextName -- context containing variableName 968 IN variableName -- OID for the managed object 969 ) 971 The securityModel, securityName and securityLevel parameters are set 972 to the values that were recorded when the scheduling entry was 973 created. The viewType parameter must select the write view and the 974 contextName and variableName parameters are taken from the 975 schedContextName and schedVariableName values of the scheduling 976 entry. 978 This MIB limits scheduled actions to objects in the local MIB. This 979 avoids security problems with the delegation of access rights. 980 However, it might be possible for a user of this MIB to own some 981 schedules that might trigger far in the future. This can cause 982 security risks if the security administrator did not properly update 983 the access control lists when a user is withdrawn from an SNMP 984 engine. Therefore, entries in the schedTable SHOULD be cleaned up 985 whenever a user is removed from an SNMP engine. 987 To facilitate the provisioning of access control by a security 988 administrator using the View-Based Access Control Model (VACM) 989 defined in RFC 2275 [15] for tables in which multiple users may need 990 to independently create or modify entries, the initial index is used 991 as an "owner index". Such an initial index has a syntax of 992 SnmpAdminString, and can thus be trivially mapped to a securityName 993 or groupName as defined in VACM, in accordance with a security 994 policy. 996 All entries in related tables belonging to a particular user will 997 have the same value for this initial index. For a given user's 998 entries in a particular table, the object identifiers for the 999 information in these entries will have the same subidentifiers 1000 (except for the "column" subidentifier) up to the end of the encoded 1001 owner index. To configure VACM to permit access to this portion of 1002 the table, one would create vacmViewTreeFamilyTable entries with the 1003 value of vacmViewTreeFamilySubtree including the owner index portion, 1004 and vacmViewTreeFamilyMask "wildcarding" the column subidentifier. 1005 More elaborate configurations are possible. 1007 7. Intellectual Property 1009 The IETF takes no position regarding the validity or scope of any 1010 intellectual property or other rights that might be claimed to 1011 pertain to the implementation or use of the technology described in 1012 this document or the extent to which any license under such rights 1013 might or might not be available; neither does it represent that it 1014 has made any effort to identify any such rights. Information on the 1015 IETF's procedures with respect to rights in standards-track and 1016 standards-related documentation can be found in BCP-11. Copies of 1017 claims of rights made available for publication and any assurances of 1018 licenses to be made available, or the result of an attempt made to 1019 obtain a general license or permission for the use of such 1020 proprietary rights by implementors or users of this specification can 1021 be obtained from the IETF Secretariat. 1023 The IETF invites any interested party to bring to its attention any 1024 copyrights, patents or patent applications, or other proprietary 1025 rights which may cover technology that may be required to practice 1026 this standard. Please address the information to the IETF Executive 1027 Director. 1029 8. Acknowledgments 1031 This document was produced by the IETF Distributed Management 1032 (DISMAN) working group. 1034 9. References 1036 [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 1037 Describing SNMP Management Frameworks", RFC 2271, Cabletron 1038 Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, 1039 January 1998 1041 [2] Rose, M., and K. McCloghrie, "Structure and Identification of 1042 Management Information for TCP/IP-based Internets", RFC 1155, 1043 Performance Systems International, Hughes LAN Systems, May 1990 1045 [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, 1046 Performance Systems International, Hughes LAN Systems, March 1991 1048 [4] M. Rose, "A Convention for Defining Traps for use with the SNMP", 1049 RFC 1215, Performance Systems International, March 1991 1051 [5] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure 1052 of Management Information for Version 2 of the Simple Network 1053 Management Protocol (SNMPv2)", RFC 1902, SNMP Research,Inc., Cisco 1054 Systems, Inc., Dover Beach Consulting, Inc., International Network 1055 Services, January 1996. 1057 [6] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual 1058 Conventions for Version 2 of the Simple Network Management Protocol 1059 (SNMPv2)", RFC 1903, SNMP Research, Inc., Cisco Systems, Inc., 1060 Dover Beach Consulting, Inc., International Network Services, 1061 January 1996. 1063 [7] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance 1064 Statements for Version 2 of the Simple Network Management Protocol 1065 (SNMPv2)", RFC 1904, SNMP Research, Inc., Cisco Systems, Inc., 1066 Dover Beach Consulting, Inc., International Network Services, 1067 January 1996. 1069 [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 1070 Management Protocol", RFC 1157, SNMP Research, Performance Systems 1071 International, Performance Systems International, MIT Laboratory 1072 for Computer Science, May 1990. 1074 [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 1075 "Introduction to Community-based SNMPv2", RFC 1901, SNMP Research, 1076 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1077 International Network Services, January 1996. 1079 [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport 1080 Mappings for Version 2 of the Simple Network Management Protocol 1081 (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., 1082 Dover Beach Consulting, Inc., International Network Services, 1083 January 1996. 1085 [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 1086 Processing and Dispatching for the Simple Network Management 1087 Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron Systems, 1088 Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. 1090 [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for 1091 version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 1092 2274, IBM T. J. Watson Research, January 1998. 1094 [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol 1095 Operations for Version 2 of the Simple Network Management Protocol 1096 (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc., 1097 Dover Beach Consulting, Inc., International Network Services, 1098 January 1996. 1100 [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 1101 2273, SNMP Research, Inc., Secure Computing Corporation, Cisco 1102 Systems, January 1998 1104 [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access 1105 Control Model (VACM) for the Simple Network Management Protocol 1106 (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc., 1107 Cisco Systems, Inc., January 1998 1109 [16] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF 1110 Standards Process", BCP 11, RFC 2028, October 1996. 1112 [17] Levi, D., and J. Schoenwaelder, "Definitions of Managed Objects for 1113 the Delegation of Management Scripts", Internet-Draft , SNMP Research, Inc., TU Braunschweig, 1115 May 1998. 1117 [18] McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB using 1118 SMIv2", RFC 2233, Cisco Systems, FTP Software, November 1997. 1120 10. Editors' Addresses 1122 David B. Levi Email: levi@snmp.com 1123 SNMP Research, Inc. Tel: +1 423 573 1434 1124 3001 Kimberlin Heights Road 1125 Knoxville, TN 37920-9716 1126 U.S.A. 1128 Juergen Schoenwaelder Email: schoenw@ibr.cs.tu-bs.de 1129 TU Braunschweig Tel: +49 531 391-3283 1130 Bueltenweg 74/75 1131 38106 Braunschweig 1132 Germany 1134 11. Full Copyright Statement 1136 Copyright (C) The Internet Society (1998). All Rights Reserved. 1138 This document and translations of it may be copied and furnished to 1139 others, and derivative works that comment on or otherwise explain it 1140 or assist in its implementation may be prepared, copied, published 1141 and distributed, in whole or in part, without restriction of any 1142 kind, provided that the above copyright notice and this paragraph are 1143 included on all such copies and derivative works. However, this 1144 document itself may not be modified in any way, such as by removing 1145 the copyright notice or references to the Internet Society or other 1146 Internet organizations, except as needed for the purpose of 1147 developing Internet standards in which case the procedures for 1148 copyrights defined in the Internet Standards process must be 1149 followed, or as required to translate it into languages other than 1150 English. 1152 The limited permissions granted above are perpetual and will not be 1153 revoked by the Internet Society or its successors or assigns. 1155 This document and the information contained herein is provided on an 1156 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1157 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1158 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1159 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1160 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1162 12. Revision History 1164 This section should be removed once this document gets published as an 1165 RFC. 1167 12.1. Changes from 1169 o Clarifications about drifts between initiations of action in a 1170 periodic scheduler. 1172 o Made the registration of the notification reversible. 1174 o Changed the syntax of schedInterval from TimeInterval to 1175 Unsigned32. The maximum resolution is now seconds instead of 1176 hundreds of a second. 1178 o The conformance statement makes objects for the calendar-based 1179 scheduler optional. 1181 o Minor changes to make the MIB compile with smicng. 1183 12.2. Changes from 1185 o Updated the section about the SNMP management framework and 1186 added references to SNMPv3. 1188 o Replaced Utf8String with SnmpAdminString. 1190 o Added Intellectual Property section. 1192 o Changed some wordings to make the text more readable. 1194 12.3. Changes from 1196 o Fixes some typos. 1198 o Changed the semantics of "no bits set" and added DEFVALs which 1199 default to nothing scheduled. 1201 o Added reference to BCP-11. 1203 o Added the schedContextName object to indicate the context of the 1204 variable being set by the scheduler. 1206 o Added three examples to demonstrate the usage of the scheduling 1207 MIB. 1209 o Created a new TC SnmpPduErrorStatus which contains SNMP PDU 1210 error status codes plus `noResponse'. 1212 o Added the new boilerplate and the references that go along with 1213 it. 1215 o Removed the transitional states `enabling' and `disabling' from 1216 the schedOperStatus object. 1218 o Defined the set of objects that must be writable if the storage 1219 type of a row is permanent. 1221 o List the objects that have to get values assigned during row 1222 creation in order to set a row to `active'. 1224 o Added text which describes how the isAccessAllowed abstract 1225 service interface is called for access control. 1227 o Added Randy's text which explains the indexing structure without 1228 refering to a DISMAN framework. 1230 o Replaced schedIndex with schedName. This allows semantic 1231 meaningful references to scheduling entries. 1233 12.4. Changes from 1235 o Changed the MIB module name to DISMAN-SCHEDULE-MIB. 1237 o Fixed the example to make the indexing consistent with the new 1238 version of the Script MIB. 1240 o Removed the IMPLIED keyword and updated the examples. 1242 o Moved the change logs to the end of the document. 1244 12.5. Changes from 1246 o Added the key words boilerplate from RFC 2119. 1248 o Replaced "DISMAN application" with distributed management 1249 application. 1251 o Replaced schedMIBTraps with schedTraps. 1253 o Reworded the last sentence in the second paragraph of the 1254 security considerations to use SHOULD as defined in RFC 2119. 1256 o Exchanged monday and friday in the example. 1258 o Added a new section about time transitions. 1260 o Added the schedLocalTime object which provides access to the 1261 local time and the local timezone (offset from GMT). Add text to 1262 define that calendar schedules are always in local time. 1264 o Added the DEFVAL { 0 } to schedInterval and added text which 1265 describes that periodic schedules with a schedInterval of 0 1266 seconds must be ignored. 1268 o Added schedLastFailed to the schedActionFailure notification. 1270 o Replaced the phrase "launch button" with more precise 1271 terminology. 1273 o Changed schedAdminStatus and schedOperStatus to have only the 1274 states enabled/disabled. Added a new schedType object which 1275 defines whether we have a periodic, calendar or one-shot 1276 schedule. Added a new schedOperStatus state finished which is 1277 used when a one-shot schedule ends. Changed the first example to 1278 schedule an event on the next friday 13th using a one-shot 1279 schedule and updated all examples. 1281 o Defined the term scheduler in the overview section. 1283 o Added text to the section describing calendar schedules in order 1284 to better describe how it works. 1286 o Added bits to schedDay which allow to specify days relative to 1287 the end of the month. 1289 Table of Contents 1291 1 Abstract ..................................................... 2 1292 2 The SNMP Management Framework ................................ 2 1293 3 Overview ..................................................... 3 1294 3.1 Periodic Schedules ......................................... 3 1295 3.2 Calendar Schedules ......................................... 4 1296 3.3 One-shot Schedules ......................................... 4 1297 3.4 Time Transitions ........................................... 5 1298 3.5 Actions .................................................... 5 1299 4 Definitions .................................................. 6 1300 5 Usage Examples ............................................... 19 1301 5.1 Starting a script to ping devices every 20 minutes ......... 19 1302 5.2 Starting a script at the next Friday the 13th .............. 19 1303 5.3 Turning an interface off during weekends ................... 20 1304 6 Security Considerations ...................................... 22 1305 7 Intellectual Property ........................................ 23 1306 8 Acknowledgments .............................................. 23 1307 9 References ................................................... 24 1308 10 Editors' Addresses .......................................... 26 1309 11 Full Copyright Statement .................................... 26 1310 12 Revision History ............................................ 27 1311 12.1 Changes from .......... 27 1312 12.2 Changes from .......... 27 1313 12.3 Changes from .......... 27 1314 12.4 Changes from .......... 28 1315 12.5 Changes from .......... 29