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

From: Alan Luchuk <[email-masked]>
Date: Thu, 21 Jun 2001 16:53:50 -0400 (EDT)

Hello,

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

I consider this a pathologic case.  User/installer error always can cause
system crashes, and no amount of developer effort can prevent this. 

As counter examples of where dropping scheduled events might cause prob-
lems, suppose a scheduled event monitors a process for runaway consumption 
of processor, disk, or memory usage.  If the scheduled events are dropped,
the runaway process might consume all available system resources and crash
the system.  Or what about if the DISMAN-SCHEDULE-MIB is used to enable/
disable network interfaces.  Your customer will be pretty unhappy if his 
interface isn't turned on because a scheduled event was missed because of 
a clock warp or excessive system load.  (I had to toss these out 'cause you 
welcomed examples :-)

I believe these may be equally (un)likely counter-examples.  Thus, it 
becomes a matter of personal opinion or preference as to which equally 
(un)likely error you would rather have.

>Explaining the issue up front and encouraging and suggesting good handling
>techniques is good customer service, IMHO.

Agreed.  But not breaking backward compatibility, without providing sign-
ificant new functionality, is even better customer service.  Instead of 
changing the specification and breaking backward compatibility, why don't 
we just document the possibility of crashing the system if the event exec-
ution time is greater than the time between event activations?

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

I agree, situations regarding how the DISMAN-SCHEDULE-MIB agent handles 
the non-existant time/ambiguous time situations should be quite rare.

I've said my $0.02 worth.  I believe I've already said more about the 
time transition issue than the strength of my opinions warrant.  I can 
align with the consensus of the DISMAN WG on the time transition issue;
either that described in RFC 2591, or that described in <draft-ietf-
disman-schedule-mib-v2-04.txt>.  However, I would prefer to preserve 
compatibility for the installed user base.

Regards,
--Alan

 -----------------------------------------------------------------------------
 Alan Luchuk        SNMP Research, Inc.                Voice:  +1 865 573 1434
 Software Engineer  3001 Kimberlin Heights Road        FAX:    +1 865 573 9197
 [email-masked]    Knoxville, TN  37920-9716  U.S.A.  http://www.snmp.com/
 -----------------------------------------------------------------------------