Subject: RE: <draft-ietf-disman-schedule-mib-v2-04.txt>

From: "Ayers, Mike" <[email-masked]>
Date: Thu, 21 Jun 2001 13:44:56 -0500

> From: Alan Luchuk [mailto:[email-masked]] 

> 1.  One could argue that either the time transition behavior described
>     in RFC 2591 is more useful or the time transition 
> behavior described
>     in <draft-ietf-disman-schedule-mib-v2-04.txt> is more 
> useful; there
>     are situations in which either behavior might be more 
> useful or more
>     problematic.

	I have maintained all along that this is not so.  Specifically,
there is a foreseeable set of circumstances for which the original time
transition behavior can cause impairment to a host's functionality - when a
scheduled activity uses more host time than its schedule interval.  With the
old model, this could lock up, even crash, the system; in the new model,
this will simply cause the script to miss some of its slots.  I welcome an
example of the new model leading to such dire consequences.

<SNIP/>

> 1.  First, if the DISMAN-SCHEDULE-MIB agent is running on a 
> heavily-loaded
>     system, and doesn't get serviced for several minutes, how 
> can the agent
>     differentiate this from a situation where the system time 
> is administ-
>     ratively changed by several minutes?  What is the agent 
> supposed to do
>     with events calendar-scheduled for the minutes during 
> which the agent
>     was suspended by the system?  Skipping these events 
> because the system 
>     was heavily loaded seems like a undesirable behavior.

	Again, the scripts themselves could be the cause of the load.  Also
note that if system load causes the script agent to miss some time, then the
script agent is not the highest priority process on the system.  This seems
to boil down to an issue of guaranteed execution.  I think we should add an
explicit clause stating that execution at any time slot cannot be
guaranteed.

> 2.  Although (as far as I can see), all of the other 
> changes/clarifications
>     in <draft-ietf-disman-schedule-mib-v2-04.txt> are 
> upwardly-compatible
>     with RFC 2591, changing the time-transition behavior 
> breaks this.  That
>     is, users that expect RFC 2591 time-transition behavior 
> may be surprised
>     by the time transition behavior described in 
> <draft-ietf-disman-schedule-
>     mib-v2-04.txt>.  Hence, this behavioral change must be 
> documented in
>     release notes for the user.

	Yes, and those release notes can include an explanation of why the
change was made, and perhaps discuss how scripts can handle missed
opportunities.  This is one of those areas that folk tend to miss, leading
to great consternation when they discover the issue the hard way.
Explaining the issue up front and encouraging and suggesting good handling
techniques is good customer service, IMHO.

> I cannot argue for or against either time transition behavior 
> as being the
> "correct" behavior, so I have no preference based upon 
> "correctness".  How-
> ever, I prefer the time transition behavior described in RFC 
> 2591 because
> we have a released product with an installed customer base 
> that expects the
> time transition behavior documented in RFC 2591.

	Early adopters should not be surprised when behaviors change a
little - it's part of the risk involved.  However, I suspect that few of
your users actually rely on the behavior during these situations, since they
should be quite rare.

/|/|ike