Subject: Re: Script MIB implementation question

From: [email-masked]
Date: Tue, 30 Mar 1999 10:07:34 -0500 (EST)

>The question is whether we want a general (and thus more expensive)
>solution or if we prefer a special purpose solution for the coldStart
>event, which can be done a bit easier.

I see the advantages of this generalization and agree that it's 
a useful idea.  I can align with this idea.

The disadvantage of the particular MIB described, and the scheduling 
MIB, is that both MIBs can only press a trigger button -- neither 
have facilities to set other parameters (like script arguments) before
pressing the trigger button.  This doesn't limit the usefulness of 
these two MIBs when used with the DISMAN-SCRIPT-MIB (because of the 
DISMAN-SCRIPT-MIB's ability to use the same script with different 
arguments) but may somewhat limit their usefulness to trigger actions 
in MIBs other than the DISMAN-SCRIPT-MIB.

>I think this is a much cleaner solution than having the manager to
>look into some "discriminated union" tables where the result instances
>are most likely indexed by the running script (where the instance
>identifier may have different lifetime constraints than the
>semantically meaningful instance identifer, ifIndex in the example).

I agree -- I rather like the idea of having the running script provide
its results as a specific MIB instead of as a "discriminated union".
It's just that it's not clear to me how this would work in practice.
(I've seen code to do the discriminated union way, so I'm more familiar
with it.)  Like:

-  How does the script tell the agent what MIB objects it wishes to
   return?   Does the script provide a list of all of the OIDs of
   all of the MIB objects, or a subtree?

-  How does the script populate the MIB?

-  What agent mechanism gets control to get the results from
   the dynamically-added MIB?

-  What happens with sets?

-  How are read-create objects and tables in general handled?

>Sure, a full blown implementation may need some ressources. However,
>it is possible to strip the resource usage down. In the extreme case,
>you do not support dynamic installation of scripts at all and you use
>the script MIB only to call pre-installed 'hard-wired' scripts.

I believe the issue of embedded systems should be given thought when
designing these MIBs because DIStributed MANagement is often done
with embedded boxes like RMON probes.

My boss assigned the project to implement the DISMAN-SCRIPT-MIB to
me in part because I was a completely independent reviewer -- I had 
not been involved in developing the standard.  My comments are based 
strictly upon my experiences implementing and using it. 

Please do not construe my comments as criticisms -- I'm merely 
attempting to address what I'm experiencing as limitations.  
Whether or not what I'm experiencing as limitations are resolved 
in the standards-track documents makes no difference to me personally.

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Mar 1999 18:11:00 +0200

>>>>> luchuk  writes:

luchuk> The disadvantage of the particular MIB described, and the
luchuk> scheduling MIB, is that both MIBs can only press a trigger
luchuk> button -- neither have facilities to set other parameters
luchuk> (like script arguments) before pressing the trigger button.
luchuk> This doesn't limit the usefulness of these two MIBs when used
luchuk> with the DISMAN-SCRIPT-MIB (because of the DISMAN-SCRIPT-MIB's
luchuk> ability to use the same script with different arguments) but
luchuk> may somewhat limit their usefulness to trigger actions in MIBs
luchuk> other than the DISMAN-SCRIPT-MIB.

I agree wrt. the binding MIB. The question is indeed whether we need a
standard way to pass event details (the varbind list in the case of a
notification) to the event consuming thing. In the case of the
scheduling MIB, there is not much to pass (except perhaps the current
date, but this may be accessible to the script via other mechanisms as
well).

The question is whether the event details are passed via a MIB (which
may lead to complicated solutions) or via implementation or runtime
system specific mechanisms.

luchuk> I agree -- I rather like the idea of having the running script
luchuk> provide its results as a specific MIB instead of as a
luchuk> "discriminated union".  It's just that it's not clear to me
luchuk> how this would work in practice.  (I've seen code to do the
luchuk> discriminated union way, so I'm more familiar with it.)  Like:

luchuk> - How does the script tell the agent what MIB objects it
luchuk> wishes to return?  Does the script provide a list of all of
luchuk> the OIDs of all of the MIB objects, or a subtree?

luchuk> - How does the script populate the MIB?

luchuk> - What agent mechanism gets control to get the results from
luchuk> the dynamically-added MIB?

luchuk> - What happens with sets?

luchuk> - How are read-create objects and tables in general handled?

In our implementation, the runtime systems run as separate operating
system processes. We plan to implement an AgentX runtime system
extension which can be used by a script to export MIB objects via
AgentX:

	+--------+  AgentX  +---------+
	|  SNMP  |<-------->|  Java   |
	| Engine |<-------->| Runtime |
	+--------+   SMX    +---------+

Our primary runtime system is a Java VM. We already have an extension
(a small class library) to allow running scripts to export smResult
values and to trigger smScriptResult notifications. Adding support for
AgentX will result in another class library/extension on the runtime
to export MIB objects via AgentX. The mechanism used by a script to
export MIB objects only depends on the features provided by AgentX and
the class library which makes those features accessible to a running
script. In our implementation approach, all the questions you ask
above actually belong to the Java AgentX class library, not the Script
MIB or our SMX protocol.

(It might be worthwhile in the scenario described above to work on
standard "client" APIs for AgentX. But this really belongs into the
AgentX WG.)

luchuk> Please do not construe my comments as criticisms -- I'm merely
luchuk> attempting to address what I'm experiencing as limitations.
luchuk> Whether or not what I'm experiencing as limitations are
luchuk> resolved in the standards-track documents makes no difference
luchuk> to me personally.

You comments are very welcome since they help to identify "rough
spots" in the MIB definition and we can work towards solving them here
without having to resort to proprietary extensions. I am also pleased
to hear that you managed to implement the MIB without running into
serious problems with the spec.
							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)