Subject: Re: snmpconf Schedule Requirements

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 15 Sep 2000 14:45:03 +0200

>>>>> Thippanna Hongal writes:

Thippanna> Here is the list of requirement I did compile to associate
Thippanna> time with the policies.

Thanks for posting this summary. Let me try to rephrase your
requirements to see whether I did understand you correctly:

  The requirement is to support two additional scheduling types. Both
  new scheduling types schedule time intervals, which means they create
  a set operation at the beginning of a time interval and at the end of
  the time interval. It is sufficient if the sets triggered by the
  scheduler modifies the same integer variable. However, it is necessary
  to be able to set two different values at the start and the end of the
  time interval.

  The first new scheduling type (A) specifies the time interval based on
  calendar time. The second new scheduling type (B) specifies the start
  point based on calendar time and the duration of the time interval.

  (Well, you actually wrote in your email that the second starts
  immediately when something (the schedTable entry?) is enabled and runs
  for the duration specified, but the proposed solution you described is
  not really consistent with this. Anyway, I will call this variation
  (B').)

Is that summary of the requirements correct so far?

Now lets look what we have right now in RFC 2591. I believe you can
realize all schedules described above as follows with RFC 2591:

(A)  You create two oneshot schedules in the schedTable, one for
     the start time and one for the end time.

(B)  Similar to (A), you create two oneshot schedules in the
     schedTable, one for the start time and one for the end time.  You
     simply let the manager calculate the end time by adding the time
     interval to the start time.

(B') You generate a single oneshot schedule for the end time and once
     the manager has calculated the end time based on the current
     time. (An alternative would be a very slight modification to add
     a new scheduling type which is basically a periodic schedule
     which disables itself after the first scheduled event.)

Now, from looking at the proposed solution, it looks like you are for
some reason uncomfortable with what I have described above. Is it
possible to clearly describe why the solutions outlined above do not
work or are way too ugly in the snmpconf context? Can you provide
examples to demonstrate your points?

[There are many issues I have with the proposed solutions. But before
 discussing this in detail, I would first like to better understand
 what the problem really is. Maybe there are other solutions that fit
 better into the design of the current scheduler.]

/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: Thippanna Hongal <[email-masked]>
Date: Fri, 15 Sep 2000 09:53:32 -0700

Juergen Schoenwaelder wrote:

>   the time interval.

The scheduler will   operate in the startDateAndTime ,
and  endDateAndTime.
It triggers events at StartTime and at EndTime as specified in the
schedTimeOfDay
and uses masks schedMonth,schedDay, schedDayOfWeek enabling multiple
schedules in the selected range of Dates.
The picture shown will give better picture what I have in mind.

1. as understood
startDateAndTime                               endDateAndTime
|--------------------------------------------------------|
T
T.

2.as required
startDateAndTime                               endDateAndTime
|---|--|---d1---|--|---d2---|--|---d3---|--|---d4---|--|---|
     T T'           T T'           T T'           T  T'          T  T'

T- Trigger indicating the Start of policy
T' - Trigger indicating the End of Policy
dn- Day n, n = 0..31

> It is sufficient if the sets triggered by the

I mean the periodic scheduler time tick start as soon as the schedTable
entry
is enabled. I have no plans to associate this with Calendar Entry  to start
with.

I am exactly looking for: B'
>    (An alternative would be a very slight modification to add

I will again look into the proposed solution, if I need to fix it.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Sep 2000 16:08:48 +0200

>>>>> Thippanna Hongal writes:

Thippanna> The scheduler will operate in the startDateAndTime , and
Thippanna> endDateAndTime.  It triggers events at StartTime and at
Thippanna> EndTime as specified in the schedTimeOfDay and uses masks
Thippanna> schedMonth,schedDay, schedDayOfWeek enabling multiple
Thippanna> schedules in the selected range of Dates.  The picture
Thippanna> shown will give better picture what I have in mind.

[...]

Let me check whether I understand what you were saying. You want to
have a time interval schedule (defined by a start and an end event)
and in addition another time interval schedule which defines the
lifetime of the first time interval schedule. In other words, with RFC
2591, you would have two rows, one for the start and one for the end
event of the first time interval. You would have four additional rows
to turn the first two rows on and off (two rows to turn the other two
rows on and two rows to turn the other two rows off).

[If there were a mechanism to set multiple variables or to have
 multiple values, then it would be possible to reduce the total 
 number of rows I think.]

/js

---

From: Jon Saperia <[email-masked]>
Date: Fri, 22 Sep 2000 06:30:14 -0400

> multiple values, then it would be possible to reduce the total

Juergen, I do not want to speak for Hongal, but on reading your reply, I too
was wondering if we may have ended up with too many rows. Without limiting
Hongal's other proposal points I would like to see if we can do a simple
duration schedule in one row. Hongal, if you had intended this and I
misread, sorry.

I see this duration type schedule as having a start time and a duration.
Without changing the flexibility of the other items proposed, can we have
this simple case?

It would have a schedType of duration and a new object, duration would
indicate how long the policy was to be in effect.

/jon

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 22 Sep 2000 13:02:06 +0200

>>>>> Jon Saperia writes:

Jon> Juergen, I do not want to speak for Hongal, but on reading your
Jon> reply, I too was wondering if we may have ended up with too many
Jon> rows.

Jon,

I am currently just trying to understand what the additional
requirements boil down. I just wanted to figure out what Hongal was
asking for, whether it is doable with the current RFC 2591 and what
the implications are.

Jon> Without limiting Hongal's other proposal points I would like to
Jon> see if we can do a simple duration schedule in one row.

So your requirements seem to be less than Hongal's requirements.

Jon> I see this duration type schedule as having a start time and a
Jon> duration. 

Jon> It would have a schedType of duration and a new object, duration
Jon> would indicate how long the policy was to be in effect.

I think you also need to have another value which you set on the end
of the time interval, right? We probably also need to document the
behaviour in some corner cases (e.g. the start time triggers again
before the previous start time trigger + duration, or the behaviour
in case of time transitions).

Jon> Without changing the flexibility of the other items proposed, can
Jon> we have this simple case?

The DISMAN WG has to make this decision. So please post your thoughts
on this proposed RFC 2591 extension. Personally, I am especially
interested in the opinion of people who have already implemented RFC
2591.

Randy, does it make sense to put out a deadline for people to raise
their views so that we actually get to a decision in the near future?

/js

---

From: Jon Saperia <[email-masked]>
Date: Sat, 23 Sep 2000 09:12:35 -0400

> So your requirements seem to be less than Hongal's requirements.
Please do not interpret it that way at all. I was pointing to one of the
requirements that Hongal put forward. Specifically to a schedule that starts
at a specified time and runs for a fixed length of length of time.  Hongel
put forward others that are important as well.

I would like to be able to say start at a time and run for 90 mins. Or Under
condition A run for 1 hour.  I understand these are two different requests.

> in case of time transitions).
In the types of schedule that I have described which are a subset of those
Hongal proposes, I do not need an end time since that is implicit in
duration.  My subset should not be interpreted as suggesting Hongals other
points are not important, only that I wanted to emphasize issues of
particular interest to me.

/jon