Subject: snmpconf Issue 1 - Use of the Script MIB

From: David Partain <[email-masked]>
Date: Tue, 26 Sep 2000 12:05:06 +0200

Greetings,

(In all of the issues mail that follows, I have tried to be
careful not to misrepresent anyone's views.  I'm sure I'll be
told if I do. :-))

A large source of discussion recently has been the extent
to which we should leverage the Script MIB in our work.
The issue basically is whether SNMPCONF should use its own
scripting infrastructure or whether it should use the Script
MIB instead.  My interpretation of this is whether to use a
specific or generic tool for the job.

This issue is related to issue #2 (Split of filter and action
into two objects), although I decided to make that a different
discussion.

Relevant pieces of mail have been:
http://www.escribe.com/computing/snmpconf/m275.html and those in
the same thread.

Juergen Schoenwaelder has been a proponent of using the Script
MIB within SNMPCONF.  The argument is that the DISMAN group has
tackled many of the issues that SNMPCONF is going to have to deal
with if they don't use the Script MIB and that the fit of the
Script MIB to SNMPCONF is fine.  He has argued that the
facilities needed as listed in the bullets below can be done
in other ways or are not necessarily valuable.

Steve Waldbusser has been a proponent of continuing to use
an environment specific to the SNMPCONF work.  Amongst other
things, he has argued that the Script MIB is not a good fit
since it is for generic scripted applications and the PM MIB
execution environment is purpose-built for processing policy
expressions.  Further, he says that the PM MIB requires
facilities that aren't in the Script MIB, allows things we
need to disallow, and there are differences in the way parameter
passing and scheduling need to be handled.

One question which might be useful to get a feel for is whether
readers believe it will make any difference in terms of
implementation of the SNMPCONF work.  That is, would use of the
Script MIB mean that vendors are either encouraged or discouraged
from implementing this?

Please consider this issue and respond to the mailing list, even
if it's just a "feeling".

Cheers,

David