Subject: Comments on RFC 2591

From: Frank Strauss <[email-masked]>
Date: 30 Nov 2000 16:03:40 +0100

Hi!

Reading RFC 2591 (Schedule MIB) I came up with the following questions
and comments.

1. When an action is raised, does this mean that an SNMP Set message is
   sent to the local agent or is the Set operation expected to be handled
   internally? I assume the latter, because isAccessAllowed() is mentioned
   in the schedValue description and in the security considerations.
   However, it should also be possible to send a SNMP Set message to the
   local agent and don't care about the access control issues. Maybe,
   a note should be added to clarify this.

2. When schedFailures are counted, does this count each failed action
   once or are multiple retries of a single action counted as well
   (which could probably happen if we would use SNMP)? I guess only the
   number of failed actions should be counted.

3. 5.2. explains a oneshot schedule. The last sentence bofore the list of
   varbinds should say `on the next Friday' instead of `on every Friday'.

4. The description of schedType says `Changing a schedule's type is
   equivalent to deleting the old-type schedule and creating a
   new-type one.' Does this mean that setting a schedType object to an
   already current value does not reset the schedFail* objects, while
   setting it to a different value does reset them?

 Frank

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 30 Nov 2000 16:40:39 +0100

>>>>> Frank Strauss writes:

Frank> Reading RFC 2591 (Schedule MIB) I came up with the following
Frank> questions and comments.

Frank> 1. When an action is raised, does this mean that an SNMP Set
Frank> message is sent to the local agent or is the Set operation
Frank> expected to be handled internally? I assume the latter, because
Frank> isAccessAllowed() is mentioned in the schedValue description
Frank> and in the security considerations.  However, it should also be
Frank> possible to send a SNMP Set message to the local agent and
Frank> don't care about the access control issues. Maybe, a note
Frank> should be added to clarify this.

RFC 2591 only requires that the set operation goes through access
control. How you realize this is up to the implementor. With some
toolkits, one may do it via internal function calls. With other
toolkits, one may do it by injecting an SNMP message back into the
engine (which then will also apply access control).

Do you suggest that we say explicitely that there are different ways
to implement this? (Note that this is true for many things.) Do you
have a concrete proposal?

Frank> 2. When schedFailures are counted, does this count each failed
Frank> action once or are multiple retries of a single action counted
Frank> as well (which could probably happen if we would use SNMP)? I
Frank> guess only the number of failed actions should be counted.

The intention is that schedFailures is only incremented once per
triggered action, regardless whether the implementation internally
retries set operations (which is in most cases problematic anyway).
Does the following clarification help?

      "This variable counts the number of failures while invoking
       the scheduled action. This counter at most increments once
       for a triggered action."

Frank> 3. 5.2. explains a oneshot schedule. The last sentence bofore
Frank> the list of varbinds should say `on the next Friday' instead of
Frank> `on every Friday'.

Thanks. Fixed.

Frank> 4. The description of schedType says `Changing a schedule's
Frank> type is equivalent to deleting the old-type schedule and
Frank> creating a new-type one.' Does this mean that setting a
Frank> schedType object to an already current value does not reset the
Frank> schedFail* objects, while setting it to a different value does
Frank> reset them?

Yes, the text is not really precise. How about this:

      Changing a schedule's type is equivalent to deleting the
      old-type schedule and creating a new-type one, except that
      failure objects (schedFailures, schedLastFailure, and
      schedLastFailed) will keep their values.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

---

From: Frank Strauss <[email-masked]>
Date: 30 Nov 2000 17:19:04 +0100

Juergen> RFC 2591 only requires that the set operation goes through access
Juergen> control. How you realize this is up to the implementor. With some
Juergen> toolkits, one may do it via internal function calls. With other
Juergen> toolkits, one may do it by injecting an SNMP message back into the
Juergen> engine (which then will also apply access control).

Juergen> Do you suggest that we say explicitely that there are different ways
Juergen> to implement this? (Note that this is true for many things.) Do you
Juergen> have a concrete proposal?

I suggest to change the description of schedValue from

            "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."

to something like

            "The value which is written to the MIB object pointed to
             by schedVariable when the scheduler invokes an action. If
             the implementation forwards the set operation internally
             for execution, it shall enforce the use of access control
             rules. This is accomplished by calling the
             isAccessAllowed abstract service interface as defined in
             RFC 2271. Alternatively, the implementation may choose to
             issue an SNMP Set message and leave the access control
             decision to the local agent's message processing."

Furthermore, the Security Considerations would have be changed to some
extent.

Juergen> The intention is that schedFailures is only incremented once per
Juergen> triggered action, regardless whether the implementation internally
Juergen> retries set operations (which is in most cases problematic anyway).
Juergen> Does the following clarification help?

Juergen>       "This variable counts the number of failures while invoking
Juergen>        the scheduled action. This counter at most increments once
Juergen>        for a triggered action."

Fine with me.

Juergen> Yes, the text is not really precise. How about this:

Juergen>       Changing a schedule's type is equivalent to deleting the
Juergen>       old-type schedule and creating a new-type one, except that
Juergen>       failure objects (schedFailures, schedLastFailure, and
Juergen>       schedLastFailed) will keep their values.

Aha. This changes my understanding. ;-) My question was more concerned
about the word `changing' (in contrast to `writing' to a schedType
object). In other words: The things that happen and behave like
deleting the old entry and creating a new entry do only happen when I
write a value that differs from the current value. And they do not
happen if I write the current value again.  Is this right?

After all, I suggest to describe the behaviour explicitly instead of
in an `as if ... but ...' notation. How about

             When this object is written, any pending activations for
             this schedule are removed and re-calculated."

or what else is meant by `equivalent to deleting the old-type schedule
and creating a new-type one'?

Furthermore, a sentence like this should be added to the descriptions
of schedInterval, schedWeekDay, schedMonth, schedDay, schedHour, and
schedMinute, I guess.