< draft-ietf-disman-schedule-mib-05.txt   draft-ietf-disman-schedule-mib-06.txt >
Internet-Draft Schedule MIB August 1998 Network Working Group David Levi
Internet-Draft SNMP Research, Inc.
Expires May 1999 Juergen Schoenwaelder
TU Braunschweig
18 November 1998
Definitions of Managed Objects for Definitions of Managed Objects for
Scheduling Management Operations Scheduling Management Operations
August 7, 1998 <draft-ietf-disman-schedule-mib-06.txt>
<draft-ietf-disman-schedule-mib-05.txt>
David B. Levi
SNMP Research, Inc.
levi@snmp.com
Juergen Schoenwaelder
TU Braunschweig
schoenw@ibr.cs.tu-bs.de
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 2, line 5 skipping to change at page 1, line 39
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Distribution of this document is unlimited. Please send comments to Distribution of this document is unlimited. Please send comments to
the Distributed Management Working Group, <disman@nexen.com>. the Distributed Management Working Group, <disman@nexen.com>.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved. Copyright (C) The Internet Society (1998). All Rights Reserved.
1. Abstract Abstract
This memo defines an experimental portion of the Management This memo defines a portion of the Management Information Base (MIB)
Information Base (MIB) for use with network management protocols in for use with network management protocols in the Internet community.
the Internet community. In particular, it describes a set of managed In particular, it describes a set of managed objects that are used to
objects that are used to schedule management operations periodically schedule management operations periodically or at specified dates and
or at specified dates and times. times.
Table of Contents
1 Introduction ................................................. 3
2 The SNMP Management Framework ................................ 3
3 Overview ..................................................... 4
3.1 Periodic Schedules ......................................... 4
3.2 Calendar Schedules ......................................... 5
3.3 One-shot Schedules ......................................... 5
3.4 Time Transitions ........................................... 5
3.5 Actions .................................................... 6
4 Definitions .................................................. 7
5 Usage Examples ............................................... 20
5.1 Starting a script to ping devices every 20 minutes ......... 20
5.2 Starting a script at the next Friday the 13th .............. 20
5.3 Turning an interface off during weekends ................... 21
6 Security Considerations ...................................... 23
7 Intellectual Property ........................................ 24
8 Acknowledgments .............................................. 24
9 References ................................................... 25
10 Editors' Addresses .......................................... 27
11 Full Copyright Statement .................................... 27
1. Introduction
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes a set of 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", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119 [19].
This memo does not specify a standard for the Internet community.
2. The SNMP Management Framework 2. The SNMP Management Framework
The SNMP Management Framework presently consists of five major The SNMP Management Framework presently consists of five major
components: components:
o An overall architecture, described in RFC 2271 [1]. o An overall architecture, described in RFC 2271 [1].
o Mechanisms for describing and naming objects and events for the o Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of purpose of management. The first version of this Structure of
skipping to change at page 5, line 20 skipping to change at page 6, line 14
when a daylight savings time transition occurs. when a daylight savings time transition occurs.
There are two possible situations when a time transition occurs. There are two possible situations when a time transition occurs.
First, time may be set backwards, in which case particular times will First, time may be set backwards, in which case particular times will
appear to occur twice within the same day. These are called appear to occur twice within the same day. These are called
'ambiguous times'. Second, time may be set forwards, in which case 'ambiguous times'. Second, time may be set forwards, in which case
particular times will appear to not occur within a day. This are particular times will appear to not occur within a day. This are
called 'nonexistent times'. called 'nonexistent times'.
When an action is configured in the Schedule MIB to occur at an When an action is configured in the Schedule MIB to occur at an
ambiguous time during a time transition, the action should only be ambiguous time during a time transition, the action SHALL only be
invoked at the first occurence of the ambiguous time. For example, invoked at the first occurence of the ambiguous time. For example,
if an action is scheduled to occur at 2:00 am, and a time transition 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 occurs at 3:00 am which sets the clock back to 2:00 am, the action
should only be invoked at the first occurence of 2:00 am. SHALL only be invoked at the first occurence of 2:00 am.
When an action is configured in the Schedule MIB to occur at a When an action is configured in the Schedule MIB to occur at a
nonexistent time, the action should be invoked immediately upon a nonexistent time, the action SHOULD be invoked immediately upon a
time transition. If multiple actions are invoked in this way, they time transition. If multiple actions are invoked in this way, they
should be invoked in the order in which they normally would be SHALL be invoked in the order in which they normally would be invoked
invoked had the time transition not occured. For example, if an had the time transition not occured. For example, if an action (a) is
action (a) is scheduled at 2:05 am and another action (b) at 2:10 am, scheduled at 2:05 am and another action (b) at 2:10 am, then both
then both actions should be invoked at 3:00 am in the order (a),(b) actions SHOULD be invoked at 3:00 am in the order (a),(b) if the time
if the time jumps forward from 2:00 am to 3:00 am. jumps forward from 2:00 am to 3:00 am.
3.5. Actions 3.5. Actions
Scheduled actions are modeled by SNMP set operations on local MIB Scheduled actions are modeled by SNMP set operations on local MIB
variables. Scheduled actions described in this MIB are further variables. Scheduled actions described in this MIB are further
restricted to objects of type INTEGER. This restriction does not restricted to objects of type INTEGER. This restriction does not
limit the usefulness of the MIB. Simple schedules such as on-duty / limit the usefulness of the MIB. Simple schedules such as on-duty /
off-duty schedules for resources that have a status MIB object (e.g. off-duty schedules for resources that have a status MIB object (e.g.
ifAdminStatus) are possible. ifAdminStatus) are possible.
skipping to change at page 6, line 25 skipping to change at page 7, line 25
DateAndTime, RowStatus, StorageType, VariablePointer DateAndTime, RowStatus, StorageType, VariablePointer
FROM SNMPv2-TC FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF FROM SNMPv2-CONF
SnmpAdminString SnmpAdminString
FROM SNMP-FRAMEWORK-MIB; FROM SNMP-FRAMEWORK-MIB;
schedMIB MODULE-IDENTITY schedMIB MODULE-IDENTITY
LAST-UPDATED "9808071800Z" LAST-UPDATED "9811171800Z"
ORGANIZATION "IETF DISMAN Working Group" ORGANIZATION "IETF Distributed Management Working Group"
CONTACT-INFO CONTACT-INFO
"David B. Levi "David B. Levi
SNMP Research, Inc. SNMP Research, Inc.
3001 Kimberlin Heights Road 3001 Kimberlin Heights Road
Knoxville, TN 37920-9716 Knoxville, TN 37920-9716
U.S.A. U.S.A.
Tel: +1 423 573 1434 Tel: +1 423 573 1434
E-mail: levi@snmp.com E-mail: levi@snmp.com
Juergen Schoenwaelder Juergen Schoenwaelder
TU Braunschweig TU Braunschweig
Bueltenweg 74/75 Bueltenweg 74/75
38106 Braunschweig 38106 Braunschweig
Germany Germany
Tel: +49-531-391-3283 Tel: +49 531 391-3283
E-mail: schoenw@ibr.cs.tu-bs.de" E-mail: schoenw@ibr.cs.tu-bs.de"
DESCRIPTION DESCRIPTION
"This MIB module defines a MIB which provides mechanisms to "This MIB module defines a MIB which provides mechanisms to
schedule SNMP set operations periodically or at specific schedule SNMP set operations periodically or at specific
points in time." points in time."
-- XXX Replace with real registration number from IANA. Note, the -- XXX Replace with real registration number from IANA. Note, the
-- XXX IMPORTS must be updated when the real number is assigned. -- XXX IMPORTS must be updated when the real number is assigned.
-- ::= { mib-2 XXXX } -- ::= { mib-2 XXXX }
::= { experimental 6789 } ::= { experimental 6789 }
skipping to change at page 16, line 30 skipping to change at page 17, line 30
"The status of this scheduled action. A control that allows "The status of this scheduled action. A control that allows
entries to be added and removed from this table. entries to be added and removed from this table.
The miminum number of objects that need to be set during The miminum number of objects that need to be set during
row creation before a row can be set to `active' are row creation before a row can be set to `active' are
schedContextName, schedVariable and schedValue." schedContextName, schedVariable and schedValue."
::= { schedEntry 20 } ::= { schedEntry 20 }
-- --
-- Notifications that are emitted to indicate failures. The definition -- Notifications that are emitted to indicate failures. The definition
-- of schedTraps makes notification registrations reversible. -- of schedTraps makes notification registrations reversible (see
-- section 8.3 in RFC 1902).
-- --
schedTraps OBJECT IDENTIFIER ::= { schedNotifications 0 } schedTraps OBJECT IDENTIFIER ::= { schedNotifications 0 }
schedActionFailure NOTIFICATION-TYPE schedActionFailure NOTIFICATION-TYPE
OBJECTS { schedLastFailure, schedLastFailed } OBJECTS { schedLastFailure, schedLastFailed }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This notification is generated whenever the invocation of a "This notification is generated whenever the invocation of a
scheduled action fails." scheduled action fails."
skipping to change at page 19, line 24 skipping to change at page 20, line 24
It is assumed that the schedule entry is owned by schedOwner = "joe" It is assumed that the schedule entry is owned by schedOwner = "joe"
and its name is schedName = "ping". The instance identifier for the and its name is schedName = "ping". The instance identifier for the
scheduling entry is therefore 3.106.111.101.4.112.105.110.103. scheduling entry is therefore 3.106.111.101.4.112.105.110.103.
It is further assumed that the smLaunchTable entry is owned by It is further assumed that the smLaunchTable entry is owned by
smLaunchOwner = "joe" and its name is smLaunchName = "ping-devs". The smLaunchOwner = "joe" and its name is smLaunchName = "ping-devs". The
complete object identifier for the smLaunchStart object is therefore complete object identifier for the smLaunchStart object is therefore
smLaunchStart.3.106.111.101.9.112.105.110.103.45.100.101.118.115. The smLaunchStart.3.106.111.101.9.112.105.110.103.45.100.101.118.115. The
script lives in the context identified by the string "engine1". script lives in the context identified by the string "engine1".
The configuration of the scheduler entry which presses the launch The configuration of the scheduler entry which launches the script
button every 20 minutes would look as follows: every 20 minutes would look as follows:
schedInterval.3.106.111.101.4.112.105.110.103 = 1200 schedInterval.3.106.111.101.4.112.105.110.103 = 1200
schedValue.3.106.111.101.4.112.105.110.103 = 0 schedValue.3.106.111.101.4.112.105.110.103 = 0
schedContextName.3.106.111.101.4.112.105.110.103 = "engine1" schedContextName.3.106.111.101.4.112.105.110.103 = "engine1"
schedVariable.3.106.111.101.4.112.105.110.103 = 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 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) schedType.3.106.111.101.4.112.105.110.103 = periodic(1)
schedAdminStatus.3.106.111.101.4.112.105.110.103 = enabled(1) schedAdminStatus.3.106.111.101.4.112.105.110.103 = enabled(1)
skipping to change at page 20, line 8 skipping to change at page 21, line 8
It is assumed that the schedule entry is owned by schedOwner = "joe" It is assumed that the schedule entry is owned by schedOwner = "joe"
and its name is schedName = "13th". The instance identifier for the and its name is schedName = "13th". The instance identifier for the
scheduling entry is therefore 3.106.111.101.4.49.51.116.104. scheduling entry is therefore 3.106.111.101.4.49.51.116.104.
It is further assumed that the smLaunchTable entry is owned by It is further assumed that the smLaunchTable entry is owned by
smLaunchOwner = "joe" and its name is smLaunchName = "ghost". The smLaunchOwner = "joe" and its name is smLaunchName = "ghost". The
complete object identifier for the smLaunchStart object is therefore complete object identifier for the smLaunchStart object is therefore
smLaunchStart.3.106.111.101.5.103.104.111.115.116. The script lives smLaunchStart.3.106.111.101.5.103.104.111.115.116. The script lives
in the context identified by the string "engine1". in the context identified by the string "engine1".
The configuration of the scheduler entry which presses the launch The configuration of the scheduler entry which launches the script on
button on every Friday 13th at midnight would look as follows: every Friday 13th at midnight would look as follows:
schedWeekDay.3.106.111.101.4.49.51.116.104 = { friday } schedWeekDay.3.106.111.101.4.49.51.116.104 = { friday }
schedMonth.3.106.111.101.4.49.51.116.104 = { schedMonth.3.106.111.101.4.49.51.116.104 = {
january, february, march, april, may, june, january, february, march, april, may, june,
july, august, september, october, november, december july, august, september, october, november, december
} }
schedDay.3.106.111.101.4.49.51.116.104 = { d13 } schedDay.3.106.111.101.4.49.51.116.104 = { d13 }
schedHour.3.106.111.101.4.49.51.116.104 = { h0 } schedHour.3.106.111.101.4.49.51.116.104 = { h0 }
schedMinute.3.106.111.101.4.49.51.116.104 = { m0 } schedMinute.3.106.111.101.4.49.51.116.104 = { m0 }
skipping to change at page 21, line 15 skipping to change at page 22, line 15
d1, d2, d3, d4, d5, d6, d7, d8, d9, d10, d1, d2, d3, d4, d5, d6, d7, d8, d9, d10,
d11, d12, d13, d14, d15, d16, d17, d18, d19, d20, d11, d12, d13, d14, d15, d16, d17, d18, d19, d20,
d21, d22, d23, d24, d25, d26, d27, d28, d29, d30, d31 d21, d22, d23, d24, d25, d26, d27, d28, d29, d30, d31
} }
schedHour.3.98.111.98.6.105.102.45.111.102.102 = { h20 } 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 } 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) 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 = "" schedContextName.3.98.111.98.6.105.102.45.111.102.102 = ""
schedVariable.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 ifAdminStatus.6
schedType.3.98.111.98.6.105.102.45.111.102.102 = calendar(2) 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) 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 = schedStorageType.3.98.111.98.6.105.102.45.111.102.102 =
nonVolatile(3) nonVolatile(3)
schedRowStatus.3.98.111.98.6.105.102.45.111.102.102 = active(1) schedRowStatus.3.98.111.98.6.105.102.45.111.102.102 = active(1)
The scheduling entry which brings the interface up on every Monday The scheduling entry which brings the interface up on every Monday
morning at 5:30 is owned by schedOwner = "bob" and its name is morning at 5:30 is owned by schedOwner = "bob" and its name is
schedName = "if-on". The instance identifier for the scheduling entry schedName = "if-on". The instance identifier for the scheduling entry
is therefore 3.98.111.98.5.105.102.45.111.110. is therefore 3.98.111.98.5.105.102.45.111.110.
The entry in the schedTable which brings the interface up again on The entry in the schedTable which brings the interface up again on
every Monday morning at 5:30 looks as follows: every Monday morning at 5:30 looks as follows:
skipping to change at page 25, line 37 skipping to change at page 26, line 37
[15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access
Control Model (VACM) for the Simple Network Management Protocol Control Model (VACM) for the Simple Network Management Protocol
(SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc., (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc.,
Cisco Systems, Inc., January 1998 Cisco Systems, Inc., January 1998
[16] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF [16] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF
Standards Process", BCP 11, RFC 2028, October 1996. Standards Process", BCP 11, RFC 2028, October 1996.
[17] Levi, D., and J. Schoenwaelder, "Definitions of Managed Objects for [17] Levi, D., and J. Schoenwaelder, "Definitions of Managed Objects for
the Delegation of Management Scripts", Internet-Draft <draft-ietf- the Delegation of Management Scripts", Internet-Draft <draft-ietf-
disman-script-mib-04.txt>, SNMP Research, Inc., TU Braunschweig, disman-script-mib-06.txt>, SNMP Research, Inc., TU Braunschweig,
May 1998. November 1998.
[18] McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB using [18] McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB using
SMIv2", RFC 2233, Cisco Systems, FTP Software, November 1997. SMIv2", RFC 2233, Cisco Systems, FTP Software, November 1997.
[19] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, Harvard University, March 1997.
10. Editors' Addresses 10. Editors' Addresses
David B. Levi Email: levi@snmp.com David B. Levi Email: levi@snmp.com
SNMP Research, Inc. Tel: +1 423 573 1434 SNMP Research, Inc. Tel: +1 423 573 1434
3001 Kimberlin Heights Road 3001 Kimberlin Heights Road
Knoxville, TN 37920-9716 Knoxville, TN 37920-9716
U.S.A. U.S.A.
Juergen Schoenwaelder Email: schoenw@ibr.cs.tu-bs.de Juergen Schoenwaelder Email: schoenw@ibr.cs.tu-bs.de
TU Braunschweig Tel: +49 531 391-3283 TU Braunschweig Tel: +49 531 391-3283
skipping to change at page 27, line 4 skipping to change at line 1187
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
12. Revision History
This section should be removed once this document gets published as an
RFC.
12.1. Changes from <draft-ietf-disman-schedule-mib-00>
o Clarifications about drifts between initiations of action in a
periodic scheduler.
o Made the registration of the notification reversible.
o Changed the syntax of schedInterval from TimeInterval to
Unsigned32. The maximum resolution is now seconds instead of
hundreds of a second.
o The conformance statement makes objects for the calendar-based
scheduler optional.
o Minor changes to make the MIB compile with smicng.
12.2. Changes from <draft-ietf-disman-schedule-mib-01>
o Updated the section about the SNMP management framework and
added references to SNMPv3.
o Replaced Utf8String with SnmpAdminString.
o Added Intellectual Property section.
o Changed some wordings to make the text more readable.
12.3. Changes from <draft-ietf-disman-schedule-mib-02>
o Fixes some typos.
o Changed the semantics of "no bits set" and added DEFVALs which
default to nothing scheduled.
o Added reference to BCP-11.
o Added the schedContextName object to indicate the context of the
variable being set by the scheduler.
o Added three examples to demonstrate the usage of the scheduling
MIB.
o Created a new TC SnmpPduErrorStatus which contains SNMP PDU
error status codes plus `noResponse'.
o Added the new boilerplate and the references that go along with
it.
o Removed the transitional states `enabling' and `disabling' from
the schedOperStatus object.
o Defined the set of objects that must be writable if the storage
type of a row is permanent.
o List the objects that have to get values assigned during row
creation in order to set a row to `active'.
o Added text which describes how the isAccessAllowed abstract
service interface is called for access control.
o Added Randy's text which explains the indexing structure without
refering to a DISMAN framework.
o Replaced schedIndex with schedName. This allows semantic
meaningful references to scheduling entries.
12.4. Changes from <draft-ietf-disman-schedule-mib-03>
o Changed the MIB module name to DISMAN-SCHEDULE-MIB.
o Fixed the example to make the indexing consistent with the new
version of the Script MIB.
o Removed the IMPLIED keyword and updated the examples.
o Moved the change logs to the end of the document.
12.5. Changes from <draft-ietf-disman-schedule-mib-04>
o Added the key words boilerplate from RFC 2119.
o Replaced "DISMAN application" with distributed management
application.
o Replaced schedMIBTraps with schedTraps.
o Reworded the last sentence in the second paragraph of the
security considerations to use SHOULD as defined in RFC 2119.
o Exchanged monday and friday in the example.
o Added a new section about time transitions.
o Added the schedLocalTime object which provides access to the
local time and the local timezone (offset from GMT). Add text to
define that calendar schedules are always in local time.
o Added the DEFVAL { 0 } to schedInterval and added text which
describes that periodic schedules with a schedInterval of 0
seconds must be ignored.
o Added schedLastFailed to the schedActionFailure notification.
o Replaced the phrase "launch button" with more precise
terminology.
o Changed schedAdminStatus and schedOperStatus to have only the
states enabled/disabled. Added a new schedType object which
defines whether we have a periodic, calendar or one-shot
schedule. Added a new schedOperStatus state finished which is
used when a one-shot schedule ends. Changed the first example to
schedule an event on the next friday 13th using a one-shot
schedule and updated all examples.
o Defined the term scheduler in the overview section.
o Added text to the section describing calendar schedules in order
to better describe how it works.
o Added bits to schedDay which allow to specify days relative to
the end of the month.
Table of Contents
1 Abstract ..................................................... 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 ........................................... 5
3.5 Actions .................................................... 5
4 Definitions .................................................. 6
5 Usage Examples ............................................... 19
5.1 Starting a script to ping devices every 20 minutes ......... 19
5.2 Starting a script at the next Friday the 13th .............. 19
5.3 Turning an interface off during weekends ................... 20
6 Security Considerations ...................................... 22
7 Intellectual Property ........................................ 23
8 Acknowledgments .............................................. 23
9 References ................................................... 24
10 Editors' Addresses .......................................... 26
11 Full Copyright Statement .................................... 26
12 Revision History ............................................ 27
12.1 Changes from <draft-ietf-disman-schedule-mib-00> .......... 27
12.2 Changes from <draft-ietf-disman-schedule-mib-01> .......... 27
12.3 Changes from <draft-ietf-disman-schedule-mib-02> .......... 27
12.4 Changes from <draft-ietf-disman-schedule-mib-03> .......... 28
12.5 Changes from <draft-ietf-disman-schedule-mib-04> .......... 29
 End of changes. 19 change blocks. 
41 lines changed or deleted 67 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/