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

From: "Ayers, Mike" <[email-masked]>
Date: Thu, 21 Jun 2001 16:33:12 -0500

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

	(rolling up sleeves)

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

	Whoa, Nelly!  Scripts running longer than anticipated is a
pathological case?  Ever heard of the halting problem?  No, this is a
routine problem, although the case of a script which consistently takes
longer than expected to run should not be so common.  I'm thinking of
scripts that parse logfiles or other accumulating output.  When first
scheduled, they may finish quickly enough, but as the log grows, they may
take more and more time.

	None of this changes the fact that system designers have an
obligation to minimize the impact of any such errors.  The proposed change
fulfills that responsibility.

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

	I think not.  Specifically, the instances of the monitor that will
not be run under the new rules are the instances which would occur
*immediately after a prior instance*.  The real window of opportunity for
trouble in this example is the time when the checks aren't happening, and
changing the time transition model doesn't alter this.  The point: checking
ten times in a row does not make up for going nine minutes without checking
at all.

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

	Two thoughts:

	1.)  Schedule the interface on script for 8:00, 8:02, and 8:05.

	2.)  Schedule a script to run every ten minutes that checks all your
interfaces and verifies that they are in the proper state.

	The two combined would make a good example of properly robust
scheduled scripting.

>  (I had to toss these 
> out 'cause you 
> welcomed examples :-)

	Good.  I welcome more.  I'd really prefer if you could see why I
think the new model is technically superior, or if you could show me why
it's not.

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

	Again, I think the consequences are highly unequal.

	I'm not trying to type you to death, but I do feel that there is
real reason for a change.

/|/|ike