Subject: Sched/Script MIB issues

From: Alan Luchuk <[email-masked]>
Date: Wed, 29 Dec 1999 14:53:01 -0500 (EST)

Hello all,

I have a couple of questions and comments about open issues related
to the DISMAN-SCHEDULE-MIB and DISMAN-SCRIPT-MIB.  From Juergen's 
list of 8-Oct-1999, here are the open issues that I'm aware of:

Issue Schedule-01:
>   o Sets on arbitrary objects triggered by the scheduler

Further explanation, please.  Does this mean that the scheduler
will be able to set:

     A.  MIB objects of type other than Integer32; and/or
     B.  Several MIB objects with a single trigger;

at the trigger time?

Issue Script-02:
>   o Restartable scripts

What does this mean?   (A cut-and-paste from archived discussion of
this topic would be fine.)

Issue Script-03:
>   o Error message during script retrieval or compilation (smScriptError)

We have solved this problem by adding such an object to a proprietary 
MIB that extends the DISMAN-SCRIPT-MIB.  But this kind of object is
something that many implementations probably have use for, so extending
the DISMAN-SCRIPT-MIB makes sense.

Issue Script-04:
>   o Scripts that can run forever without having to reset smRunLifeTime

Eamonn solved this very simply and elegantly in his implementation.
I forget the exact details, but conceptually it works like this:  If 
smRunLifeTime is set to its maximum allowed value (2147483647), the 
smRunLifeTime is never decremented.  We have added Eamonn's solution 
to our implementation of the DISMAN-SCRIPT-MIB.

Issue Script-05:
>   o Index smLangTable and smExtsnTable by name rather than Integer32

No opinion on this one.  I can align with whatever the DISMAN WG decides.

Issue Script-06:
>   o Dependencies between scripts and script versioning (Eamonn)

Issue Script-07:
>   o Storage type of script code versus storage type of script meta
>     information

What does this mean?   (A cut-and-paste from archived discussion of
this topic would be fine.)

Also, as time allows, I'll re-read RFC 2592 and make additional notes 
and comments about issues I recall.  I've slept since I last read RFC 
2592, so I can't remember the issues without looking at the RFC  :-)

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

   Please note that our telephone area code recently changed from 423 to 865. 
   Area 423 should countinue to work until it is phased out in April, 2000.