Subject: RFC 2591 update diff

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 2 Mar 2001 13:53:14 +0100

Below is the Scheduling MIB diff relative to RFC 2591.

/js

Index: sched.me
===================================================================
RCS file: /usr/home/schoenw/CVS/ietf/disman/src/sched.me,v
retrieving revision 1.9
retrieving revision 1.13
diff -U10 -r1.9 -r1.13
--- sched.me	1999/10/20 09:18:09	1.9
+++ sched.me	2001/03/02 12:32:34	1.13
@@ -5,70 +5,72 @@
 .ie \nh \{\
 .ll 66
 .po 2 \}
 .el \{\
 .ll 7.2i
 .lt 7.2i
 .pl 10.0i
 .nr sf R
 .nr bm 0.5i
 .nr fm 0 \}
-.he 'Internet-Draft'Schedule MIB'May 1999'
-.fo 'Levi & Schoenwaelder''[Page %ENDPAGE'
+.he 'Internet-Draft'Schedule MIB'March 2001'
+.fo 'Levi & Schoenwaelder'Standards Track'[Page %ENDPAGE'
 .hy 0
 .de $0
 .(x t
 \\$2 \\$1
 .)x
 ..
 .lp
 .na
 .nh

 Network Working Group                                            D. Levi
-Request for Comments: 2591                               Nortel Networks
-Category: Standards Track                               J. Schoenwaelder
+Internet-Draft                                           Nortel Networks
+Expires September 2001                                  J. Schoenwaelder
                                                          TU Braunschweig
-							        May 1999
+						           1. March 2001
 .sp1
 .ce 2
 Definitions of Managed Objects for
 Scheduling Management Operations
 .sp 1
+.ce 1
+<draft-ietf-disman-schedule-mib-v2-03.txt>

 .ti 0
 Status of this Memo
 .PP
-This document is an Internet-Draft. Internet-Drafts are working
+This document is an Internet-Draft and is in full conformance with all
+provisions of Section 10 of RFC 2026.  Internet-Drafts are working
 documents of the Internet Engineering Task Force (IETF), its areas,
 and its working groups.  Note that other groups may also distribute
 working documents as Internet-Drafts.
 .PP
 Internet-Drafts are draft documents valid for a maximum of six months
 and may be updated, replaced, or obsoleted by other documents at any
 time.  It is inappropriate to use Internet-Drafts as reference
-material or to cite them other than as ``work in progress.''
+material or to cite them other than as "work in progress."
 .PP
-To view the entire list of current Internet-Drafts, please check
-the "1id-abstracts.txt" listing contained in the Internet-Drafts
-Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
-(Northern 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).
+The list of current Internet-Drafts can be accessed at
+http://www.ietf.org/ietf/1id-abstracts.txt
 .PP
+The list of Internet-Draft Shadow Directories can be accessed at
+http://www.ietf.org/shadow.html
+.PP
 Distribution of this document is unlimited. Please send comments
 to the Distributed Management Working Group <[email-masked]>.
 .PP
 .ti 0
 Copyright Notice
 .PP
-Copyright (C) The Internet Society (1998).  All Rights Reserved.
+Copyright (C) The Internet Society (2001).  All Rights Reserved.
 .PP
 .ti 0
 Abstract
 .PP
 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.

@@ -83,21 +85,21 @@
 .sh 1 Introduction
 .PP
 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.
 .PP
 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].
+document are to be interpreted as described in RFC 2119 [RFC2119].

 .so boiler.me

 .sh 1 Overview
 .PP
 The MIB defined in this memo provides scheduling of actions periodically
 or at specified dates and times. The actions can be used to realize
 on-duty / off-duty schedules or to trigger management functions in
 a distributed management application.

@@ -191,20 +193,24 @@
 first occurence of 2:00 am.
 .PP
 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 be invoked
 had the time transition not occured. 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.
+.PP
+This rule applies to all events scheduled for nonexistent time,
+regardless whether the scheduled events originate from one or multiple
+rows in the schedTable.

 .sh 2 Actions
 .PP
 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 does not 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. ifAdminStatus) are possible.
 .PP
@@ -215,35 +221,35 @@

 .bp
 .sh 1 Definitions
 .sp
 .in +.3i
 .nf
 DISMAN-SCHEDULE-MIB DEFINITIONS ::= BEGIN

 IMPORTS
     MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
-    Integer32, Unsigned32, Counter32, mib-2
+    Integer32, Unsigned32, Counter32, mib-2, zeroDotZero
 	FROM SNMPv2-SMI

     TEXTUAL-CONVENTION,
     DateAndTime, RowStatus, StorageType, VariablePointer
 	FROM SNMPv2-TC

     MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
 	FROM SNMPv2-CONF

     SnmpAdminString
 	FROM SNMP-FRAMEWORK-MIB;

 schedMIB MODULE-IDENTITY
-    LAST-UPDATED "9811171800Z"
+    LAST-UPDATED "200103010000Z"
     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: [email-masked]

@@ -251,20 +257,31 @@
 	 TU Braunschweig
 	 Bueltenweg 74/75
 	 38106 Braunschweig
 	 Germany
 	 Tel: +49 531 391-3283
 	 E-mail: [email-masked]"
     DESCRIPTION
 	"This MIB module defines a MIB which provides mechanisms to
 	 schedule SNMP set operations periodically or at specific
 	 points in time."
+    REVISION	"200103010000Z"
+    DESCRIPTION
+	"Revised version, published as RFC XXXX.
+
+	 This revision introduces a new object type called
+	 schedTriggers. Several clarifications have been added
+	 to remove ambiguities that were discovered and reported
+	 by implementors."
+    REVISION	"199811171800Z"
+    DESCRIPTION
+	"Initial version, published as RFC 2591."
     ::= { mib-2 63 }

 --
 -- The various groups defined within this MIB definition:
 --

 schedObjects	   OBJECT IDENTIFIER ::= { schedMIB 1 }
 schedNotifications OBJECT IDENTIFIER ::= { schedMIB 2 }
 schedConformance   OBJECT IDENTIFIER ::= { schedMIB 3 }

@@ -329,21 +346,29 @@
     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."
+	"An entry describing a particular scheduled action.
+
+	 Unless noted otherwise, writable objects of this row
+	 can be modified independent of the current value of
+	 schedRowStatus, schedAdminStatus and schedOperStatus.
+	 In particular, it is legal to modify schedInterval
+	 and the objects in the schedCalendarGroup when
+	 schedRowStatus is active and schedAdminStatus and
+	 schedOperStatus are both enabled."
     INDEX { schedOwner, schedName }
     ::= { schedTable 1 }

 SchedEntry ::= SEQUENCE {
     schedOwner		SnmpAdminString,
     schedName		SnmpAdminString,
     schedDescr		SnmpAdminString,
     schedInterval	Unsigned32,
     schedWeekDay	BITS,
     schedMonth		BITS,
@@ -353,21 +378,22 @@
     schedContextName	SnmpAdminString,
     schedVariable	VariablePointer,
     schedValue		Integer32,
     schedType		INTEGER,
     schedAdminStatus	INTEGER,
     schedOperStatus	INTEGER,
     schedFailures	Counter32,
     schedLastFailure	SnmpPduErrorStatus,
     schedLastFailed	DateAndTime,
     schedStorageType	StorageType,
-    schedRowStatus	RowStatus
+    schedRowStatus	RowStatus,
+    schedTriggers	Counter32
 }

 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."
@@ -405,42 +431,50 @@
 	 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."
+	 scheduler implementation.
+
+	 Note that implementations which maintain a list of pending
+         activations must re-calculate them when this object is
+	 changed."
     DEFVAL { 0 }
     ::= { schedEntry 4 }

 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."
+	 weekday.
+
+	 Note that implementations which maintain a list of pending
+         activations must re-calculate them when this object is
+	 changed."
     DEFVAL { {} }
     ::= { schedEntry 5 }

 schedMonth OBJECT-TYPE
     SYNTAX	BITS {
 		    january(0),
 		    february(1),
 		    march(2),
 		    april(3),
 		    may(4),
@@ -452,21 +486,25 @@
 		    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."
+	 month.
+
+	 Note that implementations which maintain a list of pending
+         activations must re-calculate them when this object is
+	 changed."
     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),
@@ -497,37 +535,45 @@
 	 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."
+	 day within a month.
+
+	 Note that implementations which maintain a list of pending
+         activations must re-calculate them when this object is
+	 changed."
     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."
+	 action should take place.
+
+	 Note that implementations which maintain a list of pending
+         activations must re-calculate them when this object is
+	 changed."
     DEFVAL { {} }
     ::= { schedEntry 8 }

 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),
@@ -536,53 +582,64 @@
 		    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."
+	 should take place.
+
+	 Note that implementations which maintain a list of pending
+         activations must re-calculate them when this object is
+	 changed."
     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."
+    DEFVAL	{ "" }
     ::= { 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."
+    DEFVAL	{ zeroDotZero }
     ::= { 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."
+	 service interface as defined in RFC 2571.
+
+	 Note that an implementation may choose to issue an SNMP Set
+	 message to the SNMP engine and leave the access control
+	 decision to the normal message processing procedure."
+    DEFVAL	{ 0 }
     ::= { schedEntry 12 }

 schedType OBJECT-TYPE
     SYNTAX	INTEGER {
 		    periodic(1),
 		    calendar(2),
 		    oneshot(3)
 		}
     MAX-ACCESS	read-create
     STATUS	current
@@ -600,22 +657,23 @@
 	 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."
+	 Note that implementations which maintain a list of pending
+         activations must re-calculate them when this object is
+	 changed."
     DEFVAL { periodic }
     ::= { schedEntry 13 }

 schedAdminStatus OBJECT-TYPE
     SYNTAX	INTEGER {
 		    enabled(1),
 		    disabled(2)
 		}
     MAX-ACCESS	read-create
     STATUS	current
@@ -634,30 +692,34 @@
     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."
+	 deactivates itself.
+
+	 Note that the operational state must not be enabled(1)
+	 when the schedRowStatus is not active."
     ::= { 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."
+	 the scheduled action. This counter at most increments once
+	 for a triggered 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."
@@ -695,25 +757,41 @@
     ::= { 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."
+	 Note that the operational state must change to enabled
+	 when the administrative state is enabled and the row
+	 status changes to active(1).
+
+	 Attempts to destroy(6) a row or to set a row
+	 notInService(2) while the operational state is enabled
+	 result in inconsistentValue errors.
+
+	 The value of this object has no effect on whether other
+	 objects in this conceptual row can be modified."
     ::= { schedEntry 20 }

+schedTriggers OBJECT-TYPE
+    SYNTAX	Counter32
+    MAX-ACCESS	read-only
+    STATUS	current
+    DESCRIPTION
+	"This variable counts the number of attempts (either
+         successful or failed) to invoke the scheduled action."
+    ::= { schedEntry 21 }
+
 --
 -- 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 }
@@ -759,21 +837,22 @@
 	schedContextName,
 	schedVariable,
 	schedValue,
 	schedType,
 	schedAdminStatus,
 	schedOperStatus,
 	schedFailures,
 	schedLastFailure,
 	schedLastFailed,
 	schedStorageType,
-	schedRowStatus
+	schedRowStatus,
+	schedTriggers
     }
     STATUS	current
     DESCRIPTION
 	"A collection of objects providing scheduling capabilities."
     ::= { schedGroups 1 }

 schedCalendarGroup OBJECT-GROUP
     OBJECTS {
 	schedLocalTime,
 	schedWeekDay,
@@ -796,21 +875,21 @@
 	"The notifications emitted by the scheduler."
     ::= { schedGroups 3 }

 END
 .fi

 .bp
 .sh 1 "Usage Examples"
 .PP
 This section presents some examples how the scheduling MIB can be used
-to schedule scripts with the Script MIB [17] or to realize
+to schedule scripts with the Script MIB [RFCXXXX] or to realize
 on-duty/off-duty schedules by modifying status objects of other MIB
 modules.

 .sh 2 "Starting a script to ping devices every 20 minutes"
 .PP
 It is assumed that the schedule entry is owned by schedOwner = "joe"
 and its name is schedName = "ping". The instance identifier for the
 scheduling entry is therefore 3.106.111.101.4.112.105.110.103.
 .PP
 It is further assumed that the smLaunchTable entry is owned by
@@ -843,21 +922,21 @@
 and its name is schedName = "13th". The instance identifier for the
 scheduling entry is therefore 3.106.111.101.4.49.51.116.104.
 .PP
 It is further assumed that the smLaunchTable entry is owned by
 smLaunchOwner = "joe" and its name is smLaunchName = "ghost". The
 complete object identifier for the smLaunchStart object is therefore
 smLaunchStart.3.106.111.101.5.103.104.111.115.116. The script lives in
 the context identified by the string "engine1".
 .PP
 The configuration of the scheduler entry which launches the script
-on every Friday 13th at midnight would look as follows:
+on the next Friday 13th at midnight would look as follows:
 .PP
   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 }

@@ -870,23 +949,23 @@
   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)
 .PP
 All the remaining columns in the schedTable represent status
 information and are not shown here.

 .sh 2 "Turning an interface off during weekends"
 .PP
 This example assumes that a network interface should be taken down
-during weekends. The interface table (ifTable) of the IF-MIB [18] is
-assumed to exist in the context identified by an empty string and the
-index of the interface is ifIndex = 6.
+during weekends. The interface table (ifTable) of the IF-MIB [RFC2863]
+is assumed to exist in the context identified by an empty string and
+the index of the interface is ifIndex = 6.
 .PP
 The scheduling entry which brings the interface down on every Friday
 evening at 20:30 (8:30 pm) is owned by schedOwner = "bob" and its name
 is schedName = "if-off". The instance identifier for the scheduling
 entry is therefore 3.98.111.98.6.105.102.45.111.102.102.
 .PP
   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
@@ -939,28 +1018,52 @@
   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)
 .PP
 A similar configuration could be used to control other schedules. For
 example, one could change the "if-on" and "if-off" schedules to enable
 and disable the periodic scheduler defined in the first example.

 .sh 1 "Security Considerations"
 .PP
+There are a number of management objects defined in this MIB that
+have a MAX-ACCESS clause of read-write and/or read-create. Such
+objects may be considered sensitive or vulnerable in some network
+environments. The support for SET operations in a non-secure
+environment without proper protection can have a negative effect on
+network operations.
+.PP
+SNMPv1 by itself is not a secure environment. Even if the network
+itself is secure (for example by using IPSec), even then, there is no
+control as to who on the secure network is allowed to access and
+GET/SET (read/change/create/delete) the objects in this MIB.
+.PP
+It is recommended that the implementers consider the security
+features as provided by the SNMPv3 framework.  Specifically, the use
+of the User-based Security Model RFC 2574 [RFC2574] and the View-
+based Access Control Model RFC 2575 [RFC2575] is recommended.
+.PP
+It is then a customer/user responsibility to ensure that the SNMP
+entity giving access to an instance of this MIB, is properly
+configured to give access to the objects only to those principals
+(users) that have legitimate rights to indeed GET or SET
+(change/create/delete) them.
+.PP
 Scheduled SNMP set operations must use the security credentials that
 were present when the corresponding row in the scheduling entry was
 created.  An implementation must therefore record and maintain the
 credentials for every scheduling entry.
 .PP
 An implementation must ensure that access control rules are applied
 when doing the set operation. This is accomplished by calling the
-isAccessAllowed abstract service interface defined in RFC 2271 [1]:
+isAccessAllowed abstract service interface defined in RFC 2571
+[RFC2571]:

    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
           )
@@ -975,62 +1078,101 @@
 avoids security problems with the delegation of access
 rights. However, it might be possible for a user of this MIB to own
 some schedules that might trigger far in the future. This can cause
 security risks if the security administrator did not properly update
 the access control lists when a user is withdrawn from an SNMP
 engine. Therefore, entries in the schedTable SHOULD be cleaned up
 whenever a user is removed from an SNMP engine.
 .PP
 To facilitate the provisioning of access control by a security
 administrator using the View-Based Access Control Model (VACM) defined
-in RFC 2275 [15] for tables in which multiple users may need to
+in RFC 2575 [RFC2575] for tables in which multiple users may need to
 independently create or modify entries, the initial index is used as
 an "owner index". Such an initial index has a syntax of
 SnmpAdminString, and can thus be trivially mapped to a securityName or
 groupName as defined in VACM, in accordance with a security policy.
 .PP
 All entries in related tables belonging to a particular user will
 have the same value for this initial index.  For a given user's
 entries in a particular table, the object identifiers for the
 information in these entries will have the same subidentifiers
 (except for the "column" subidentifier) up to the end of the
 encoded owner index. To configure VACM to permit access to this
 portion of the table, one would create vacmViewTreeFamilyTable
 entries with the value of vacmViewTreeFamilySubtree including the
 owner index portion, and vacmViewTreeFamilyMask "wildcarding" the
 column subidentifier.  More elaborate configurations are possible.

 .so ipr.me

+.sh 1 "Changes from RFC 2591"
+.PP
+The following list documents major changes from the previous version
+of this document, published as RFC 2591:
+.ip "   -" 6
+Updated the SNMP Management Framework boilerplate and the references.
+.ip "   -" 6
+Added revision clauses to the module identity macro.
+.ip "   -" 6
+Clarified that the rule for handling nonexistent times during time
+transitions applies to all scheduled events regardless whether the
+events originate from one or multiple rows in the schedTable.
+.ip "   -" 6
+Clarified that schedInterval and schedCalendarGroup objects can be
+modified regardless of the current value of schedRowStatus,
+schedAdminStatus and schedOperStatus.
+.ip "   -" 6
+Added some additional boilerplate text to the security considerations
+section.
+.ip "   -" 6
+Clarified that implementations must re-calculate any pending action
+invocations when scheduling parameters are modified.
+.ip "   -" 6
+Clarified that schedOperStatus must not be enabled while the
+schedRowStatus is not active.
+.ip "   -" 6
+Clarified that schedRowStatus can not be changed as long as the
+schedOperStatus is enabled.
+.ip "   -" 6
+Clarified that implementations can delegate the isAccessAllowed check
+by sending themself an SNMP Set message.
+.ip "   -" 6
+Added the schedTriggers object which counts the total number of triggers.
+.ip "   -" 6
+Added DEFVALs for schedContextName, schedVariable, and schedValue and
+updated the schedRowStatus description.
+
+
 .sh 1 "Acknowledgments"
 .PP
 This document was produced by the IETF Distributed Management
 (DISMAN) working group.

 .so refs.me
-.ip [17]
+.ip "   [RFC2028]" 14
+Hovey, R., and S. Bradner, \*(lqThe Organizations Involved in the IETF
+Standards Process\*(rq, BCP 11, RFC 2028, October 1996
+.ip "   [RFCXXXX]" 14
 Levi, D., and J. Schoenwaelder, \*(lqDefinitions of Managed Objects for
-the Delegation of Management Scripts\*(rq, Internet-Draft
-<draft-ietf-disman-script-mib-06.txt>, SNMP Research, Inc.,
-TU Braunschweig, November 1998.
-.ip [18]
-McCloghrie, K., and F. Kastenholz, \*(lqThe Interfaces Group MIB using
-SMIv2\*(rq, RFC 2233, Cisco Systems, FTP Software, November 1997.
-.ip [19]
+the Delegation of Management Scripts\*(rq, RFC XXXX, XXXX 2001
+.ip "   [RFC2863]" 14
+McCloghrie, K., and F. Kastenholz, \*(lqThe Interfaces Group MIB\*(rq,
+RFC 2863, June 2000
+.ip "   [RFC2119]" 14
 Bradner, S., \*(lqKey words for use in RFCs to Indicate Requirement
-Levels\*(rq, BCP 14, RFC 2119, Harvard University, March 1997.
+Levels\*(rq, BCP 14, RFC 2119, March 1997

 .bp
 .sh 1 "Editors' Addresses"
 .sp
-.in +.5i
+.in +.3i
 .nf
 David B. Levi
 Nortel Networks
 4401 Great America Parkway
 Santa Clara, CA 95052-8185
 U.S.A.

 Phone: +1 423 686 0432
 EMail: [email-masked]