Subject: schedule mib updates

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 18 Jun 2001 17:49:32 +0200

I have updated the schedule MIB revision. Despite some minor editorial
changes, I have added new compliance and conformance definitions that
were needed because of the introduction of schedTriggers. 

I also rewrote the section on time transitions as was discussed in
Minneapolis and on the disman list in March. Below is the unified
context diff (which is actually showing lots of editorial changes).

Randy, please do whatever needs to be done next to get this revision
out to the IESG.

/js

Index: sched.me
===================================================================
RCS file: /usr/home/schoenw/CVS/ietf/disman/src/sched.me,v
retrieving revision 1.13
diff -u -r1.13 sched.me
--- sched.me	2001/03/02 12:32:34	1.13
+++ sched.me	2001/06/18 15:27:17
@@ -12,7 +12,7 @@
 .nr sf R
 .nr bm 0.5i
 .nr fm 0 \}
-.he 'Internet-Draft'Schedule MIB'March 2001'
+.he 'Internet-Draft'Schedule MIB'June 2001'
 .fo 'Levi & Schoenwaelder'Standards Track'[Page %ENDPAGE'
 .hy 0
 .de $0
@@ -28,14 +28,14 @@
 Internet-Draft                                           Nortel Networks
 Expires September 2001                                  J. Schoenwaelder
                                                          TU Braunschweig
-						           1. March 2001
+						               June 2001
 .sp1
 .ce 2
 Definitions of Managed Objects for
 Scheduling Management Operations
 .sp 1
 .ce 1
-<draft-ietf-disman-schedule-mib-v2-03.txt>
+<draft-ietf-disman-schedule-mib-v2-04.txt>
 
 .ti 0
 Status of this Memo
@@ -73,6 +73,8 @@
 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
+This document obsoletes RFC 2591.
 
 .bp
 .PP
@@ -173,37 +175,28 @@
 
 .sh 2 "Time Transitions"
 .PP
-When a system's notion of time is changed for some reason, implementations
-of the Schedule MIB must schedule actions differently.  One example of
-a change to a system's notion of time is when a daylight savings time
-transition occurs.
-.PP
-There are two possible situations when a time transition occurs.  First,
-time may be set backwards, in which case particular times will appear to
-occur twice within the same day.  These are called 'ambiguous times'.
-Second, time may be set forwards, in which case particular times will
-appear to not occur within a day.  This are called 'nonexistent times'.
+A time transition occurs when the Schedule MIB's notion of time (as
+reported by schedLocalTime) is changed so that time continuity is
+lost. Time transitions may be caused by daylight savings times or
+administrative changes of the system's notion of time.
+.PP
+There are two possible situations when a time transition occurs.
+First, time may be set backwards, in which case particular times will
+appear to occur twice.  These are called 'ambiguous times'.  Second,
+time may be set forwards, in which case particular times will not
+occur.  These are called 'nonexistent times'.
 .PP
 When an action is configured in the Schedule MIB to occur at an
-ambiguous time during a time transition, the action SHALL only
-be invoked at the first occurence of the ambiguous time.
-For example, if an action is scheduled to occur at 2:00 am,
-and a time transition occurs at 3:00 am which sets the clock
-back to 2:00 am, the action SHALL only be invoked at the
-first occurence of 2:00 am.
+ambiguous time, the action will be invoked at all occurences of the
+ambiguous time.  For example, if an action is scheduled to occur at
+2:10 am, and a time transition occurs at 3:00 am which sets the clock
+back to 2:00 am, the action will be invoked twice.
 .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.
+nonexistent time, the action will not be invoked at all. For example,
+if an action is scheduled to occur at 2:10 am, and a time transition
+occurs at 2:00 am which sets the clock to 3:00 am, the action will not
+be invoked.
 
 .sh 2 Actions
 .PP
@@ -242,36 +235,50 @@
 	FROM SNMP-FRAMEWORK-MIB;
 
 schedMIB MODULE-IDENTITY
-    LAST-UPDATED "200103010000Z"
+    LAST-UPDATED "200106180000Z"
     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]	 
-
-	 Juergen Schoenwaelder
-	 TU Braunschweig
-	 Bueltenweg 74/75
-	 38106 Braunschweig
-	 Germany
-	 Tel: +49 531 391-3283
-	 E-mail: [email-masked]"
+        "WG EMail:  [email-masked]
+	 Subscribe: [email-masked] 
+
+	 Chair:	    Randy Presuhn
+	            BMC Software, Inc.
+	 Postal:    Office 1-3141
+                    2141 North First Street
+                    San Jose,  California 95131
+                    USA
+	 EMail:	    [email-masked]
+	 Phone:     +1 408 546-1006
+
+	 Editor:    David B. Levi
+	            Nortel Networks
+	 Postal:    4401 Great America Parkway
+                    Santa Clara, CA 95052-8185
+                    USA
+	 EMail:     [email-masked]
+         Phone:     +1 423 686 0432
+
+         Editor:    Juergen Schoenwaelder
+                    TU Braunschweig
+         Postal:    Bueltenweg 74/75
+                    38106 Braunschweig
+                    Germany
+         EMail:     [email-masked]
+         Phone:     +49 531 391-3283"
     DESCRIPTION
 	"This MIB module defines a MIB which provides mechanisms to
 	 schedule SNMP set operations periodically or at specific
 	 points in time."
-    REVISION	"200103010000Z"
+    REVISION	"200106180000Z"
     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."
+	 schedTriggers. Created new conformance and compliance
+	 statements that take care of the new schedTriggers object.
+
+	 Several clarifications have been added to remove ambiguities
+	 that were discovered and reported by implementors."
     REVISION	"199811171800Z"
     DESCRIPTION	
 	"Initial version, published as RFC 2591."
@@ -416,7 +423,7 @@
     DESCRIPTION
 	"The human readable description of the purpose of this
 	 scheduling entry."
-    DEFVAL { ''H }
+    DEFVAL      { "" }
     ::= { schedEntry 3 }
 
 schedInterval OBJECT-TYPE
@@ -443,7 +450,7 @@
 	 Note that implementations which maintain a list of pending
          activations must re-calculate them when this object is 
 	 changed."
-    DEFVAL { 0 }
+    DEFVAL      { 0 }
     ::= { schedEntry 4 }
 
 schedWeekDay OBJECT-TYPE
@@ -468,7 +475,7 @@
 	 Note that implementations which maintain a list of pending
          activations must re-calculate them when this object is 
 	 changed."
-    DEFVAL { {} }
+    DEFVAL      { {} }
     ::= { schedEntry 5 }
 
 schedMonth OBJECT-TYPE
@@ -498,7 +505,7 @@
 	 Note that implementations which maintain a list of pending
          activations must re-calculate them when this object is 
 	 changed."
-    DEFVAL { {} }
+    DEFVAL      { {} }
     ::= { schedEntry 6 }
 
 schedDay OBJECT-TYPE
@@ -547,7 +554,7 @@
 	 Note that implementations which maintain a list of pending
          activations must re-calculate them when this object is 
 	 changed."
-    DEFVAL { {} }
+    DEFVAL      { {} }
     ::= { schedEntry 7 }
 
 schedHour OBJECT-TYPE
@@ -567,7 +574,7 @@
 	 Note that implementations which maintain a list of pending
          activations must re-calculate them when this object is 
 	 changed."
-    DEFVAL { {} }
+    DEFVAL      { {} }
     ::= { schedEntry 8 }
 
 schedMinute OBJECT-TYPE
@@ -594,7 +601,7 @@
 	 Note that implementations which maintain a list of pending
          activations must re-calculate them when this object is 
 	 changed."
-    DEFVAL { {} }
+    DEFVAL      { {} }
     ::= { schedEntry 9 }
 
 schedContextName OBJECT-TYPE
@@ -667,7 +674,7 @@
 	 Note that implementations which maintain a list of pending
          activations must re-calculate them when this object is 
 	 changed."
-    DEFVAL { periodic }
+    DEFVAL      { periodic }
     ::= { schedEntry 13 }
 
 schedAdminStatus OBJECT-TYPE
@@ -679,7 +686,7 @@
     STATUS	current
     DESCRIPTION
 	"The desired state of the schedule."
-    DEFVAL { disabled }
+    DEFVAL      { disabled }
     ::= { schedEntry 14 }
 
 schedOperStatus OBJECT-TYPE
@@ -723,7 +730,7 @@
 	"The most recent error that occured during the invocation of
 	 a scheduled action. The value noError(0) is returned
 	 if no errors have occurred yet."
-    DEFVAL { noError }
+    DEFVAL      { noError }
     ::= { schedEntry 17 }
 
 schedLastFailed OBJECT-TYPE
@@ -734,7 +741,7 @@
 	"The date and time when the most recent failure occured. The
 	 value '0000000000000000'H is returned if no failure occured
 	 since the last re-initialization of the scheduler."
-    DEFVAL { '0000000000000000'H }
+    DEFVAL      { '0000000000000000'H }
     ::= { schedEntry 18 }
 
 schedStorageType OBJECT-TYPE
@@ -753,7 +760,7 @@
 	 schedCalendarGroup, write access must be also allowed to 
 	 the columnar objects schedWeekDay, schedMonth, schedDay,
 	 schedHour, schedMinute."
-    DEFVAL { volatile }
+    DEFVAL      { volatile }
     ::= { schedEntry 19 }
 
 schedRowStatus OBJECT-TYPE
@@ -808,14 +815,14 @@
 
 -- compliance statements
 
-schedCompliance MODULE-COMPLIANCE
+schedCompliance2 MODULE-COMPLIANCE
     STATUS	current
     DESCRIPTION
 	"The compliance statement for SNMP entities which implement
 	 the scheduling MIB."
     MODULE	-- this module
     MANDATORY-GROUPS {
-           schedGroup, schedNotificationsGroup
+           schedGroup2, schedNotificationsGroup
     }
     GROUP  schedCalendarGroup
     DESCRIPTION
@@ -828,38 +835,25 @@
 	 schedCalendarGroup. Such an implementation must return
 	 inconsistentValue error responses for attempts to set
 	 schedAdminStatus to calendar(2) or oneshot(3)."
-    ::= { schedCompliances 1 }
+    ::= { schedCompliances 2 }
 
-schedGroup OBJECT-GROUP
+schedGroup2 OBJECT-GROUP
     OBJECTS {
-	schedDescr,
-	schedInterval,
-	schedContextName,
-	schedVariable,
-	schedValue,
-	schedType,
-	schedAdminStatus,
-	schedOperStatus,
-	schedFailures,
-	schedLastFailure,
-	schedLastFailed,
-	schedStorageType,
-	schedRowStatus,
-	schedTriggers
+	schedDescr, schedInterval, schedContextName, 
+	schedVariable, schedValue, schedType, 
+	schedAdminStatus, schedOperStatus, schedFailures,
+	schedLastFailure, schedLastFailed, schedStorageType,
+	schedRowStatus, schedTriggers
     }
     STATUS	current
     DESCRIPTION
 	"A collection of objects providing scheduling capabilities."
-    ::= { schedGroups 1 }
+    ::= { schedGroups 4 }
 
 schedCalendarGroup OBJECT-GROUP
     OBJECTS {
-	schedLocalTime,
-	schedWeekDay,
-	schedMonth,
-	schedDay,
-	schedHour,
-	schedMinute
+	schedLocalTime, schedWeekDay, schedMonth, 
+	schedDay, schedHour, schedMinute
     }
     STATUS	current
     DESCRIPTION
@@ -875,6 +869,46 @@
 	"The notifications emitted by the scheduler."
     ::= { schedGroups 3 }
 
+--
+-- Deprecated compliance and conformance group definitions 
+-- from RFC 2591.
+--
+
+schedCompliance MODULE-COMPLIANCE
+    STATUS	deprecated
+    DESCRIPTION
+	"The compliance statement for SNMP entities which implement
+	 the scheduling MIB."
+    MODULE	-- this module
+    MANDATORY-GROUPS {
+           schedGroup, schedNotificationsGroup
+    }
+    GROUP  schedCalendarGroup
+    DESCRIPTION
+	"The schedCalendarGroup is mandatory only for those 
+	 implementations that support calendar based schedules."
+    OBJECT schedType
+    DESCRIPTION
+	"The values calendar(2) or oneshot(3) are not valid for
+	 implementations that do not implement the
+	 schedCalendarGroup. Such an implementation must return
+	 inconsistentValue error responses for attempts to set
+	 schedAdminStatus to calendar(2) or oneshot(3)."
+    ::= { schedCompliances 1 }
+
+schedGroup OBJECT-GROUP
+    OBJECTS {
+	schedDescr, schedInterval, schedContextName,
+	schedVariable, schedValue, schedType,
+	schedAdminStatus, schedOperStatus, schedFailures,
+	schedLastFailure, schedLastFailed, schedStorageType,
+	schedRowStatus
+    }
+    STATUS	deprecated
+    DESCRIPTION
+	"A collection of objects providing scheduling capabilities."
+    ::= { schedGroups 1 }
+
 END
 .fi
 
@@ -1113,9 +1147,7 @@
 .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.
+Clarified the behavior during time transitions.
 .ip "   -" 6
 Clarified that schedInterval and schedCalendarGroup objects can be
 modified regardless of the current value of schedRowStatus,
@@ -1140,7 +1172,9 @@
 .ip "   -" 6
 Added DEFVALs for schedContextName, schedVariable, and schedValue and
 updated the schedRowStatus description.
-
+.ip "   -" 6
+Deprecated schedCompliance, schedGroup and created schedCompliance2
+and schedGroup2 that take care of the new schedTriggers object.
 
 .sh 1 "Acknowledgments"
 .PP
@@ -1171,7 +1205,7 @@
 Nortel Networks
 4401 Great America Parkway
 Santa Clara, CA 95052-8185
-U.S.A.
+USA
 
 Phone: +1 423 686 0432
 EMail: [email-masked]