[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmpconf Proposed agenda for interim meeting



Hi David,

David Partain wrote:
> 
> Greetings Jürgen and all the rest of you,
> 
> Thank you for your mail.
> 
> > >>>>> David Partain writes:
> >
> > David>   Script MIB discussion (Partain/Waldbusser)
> >
> > David>     * show me the commercial implementations in boxes * are the
> > David> semantic differences important and valid * it's a general tool
> > David> but we may want a specific tool * is it too much of a good
> > David> thing
> >
> > The * items sound like (a biased) list of answers rather than an
> > agenda item.
> 
> That wasn't what I was trying to do.  Let me see if I can
> elaborate.
> 
> I believe that one argument for using the Script MIB might be
> that it already has an installed base amongst the vendors that
> are implementing/considering implementing the SNMPCONF work.
> The existence or lack thereof of implementations is therefore
> interesting - although by no means critical.  Hence the
> first bullet.
> 
Enterasys is considering implementing the DISMAN mibs, including the
Script MIB.
It would be good not to have multiple interpreters in each device. 

> A second reason for using the Script MIB is the claim that
> they match SNMPCONF needs semantically.  Hence bullet number 2.
> 
I think it might be more accurate to say that the Script MIB offers an
environment which could provide the semantic support required - i.e. the
SNMPCONF requirements could be met as a subset of the Script MIB
functionality.

> The third and fourth bullet are asking a valid question
> (really the same one), in my view:  do we want to use the
> general tool of the Script MIB or do we want to use a tool
> created specifically for the task.

I think snmpconf policy-based configuration could be viewed as requiring
a mechanism for expressing policies, a mechanisms for transporting
policies, and an application for applying/enforcing policies at the
managed device.

SNMP can be used to distribute either a Script MIB approach or an
SNMPCONF-specific expression.

Using the Script MIB, the operator/implementor can choose the policy
expression language they prefer, that is supported by the managed
device. The application is a general purpose interpreter, so the
expression of the policy (the script) must then be more explicit and
contain more of the logic, such as the iteration across the managed
elements.

One concern I have about the snmpconf language is the dependence on
"magic" for the iteration; somehow the snmpconf engine "knows" how to
iterate across the possible managed elements. It has been my experience
as a programmer that computers are very poor at "knowing" what I intend;
they only "know" what I tell them explicitly. I think it will become
necessary to include iterator statements in our policies, or we will
need to rely on some level of magic for the thing to work.

It would be helpful to standardize the expression formats that can be
used for policy. Snmpconf WG could design a "language" for policy
expressions (as we are currently doing). Those expressions could be put
into scripts that could be downloaded to the device by disman, then
executed within an snmpconf runtime environment. The only differences
here are using combination statements rather than separate conditions
and actions, and the method of downloading the policy to the managed
device. If we work at it, we could make the snmpconf approach compatible
with the Script MIB rather than reinventing the wheel. If we make our
design caompatible with disman, then users who like our
policy-expression language and runtime environment can use it within a
DISMAN environment; if they'd rather do policy using perl or javascript,
they could use that within a disman environment; maybe they'd use a
combination of perl and javascript and snmpconf-expressions to best meet
their needs.

I personally would like to see us use an approach that is compatible
with the DISMAN work, so Enterasys and other vendors don't need to have
our engineering departments build support for two different scheduling
mibs, and two different expression interpreters, and two different
interfaces to the SNMP core, etc. for all our devices and management
applications that are involved in doing distributed policy and
configuration management.

> 
> So, while you interpret this as biased, we're genuinely trying
> to determine what the right course is for the working group.
> The agenda items represent the current work thus far and
> the draft that's been published.  We don't think there has
> been consensus on the mailing list for your counter-proposal
> to the current approach. Until we determine a consensus to
> do otherwise, we will continue to work on configuration and
> policy-based management based on the Policy Module and the
> elements it contains.
> 
> > I am not able to be at the interim, but I guess I already
> > disagree with the outcome. ;-) Seriously: I think you still do not
> > really understand my critique. I believe that you are trying to model
> > internals of a policy interpreter as granular MIB objects. And I
> > believe this approach is flawed.
> 
> Is there anyone going to the interim that you would be willing
> to entrust with communicating your viewpoint?
> 
> > FYI: We decided to work on a policy runtime system which is based on
> > existing implemented MIBs.
> 
> That's very interesting.  Perhaps you could tell us who "we"
> is?  Are you interested in external input to what you are
> doing?  I must admit, though, that I would prefer that efforts
> be concentrated on implementing what the IETF working group is
> doing, regardless of whether you agree with the concensus of
> the working group or not.
> 
I must admit that I would prefer that efforts be concentrated on
implementing what the IETF is already doing toward standardizing a
scheduling mib and a script mib and an SNMP expression mib, and that new
working groups not spend time reinventing the same wheels and providing
competing approaches to achieve similar ends.

I understand that the schedule mib may not exactly fit our needs, but I
think we could augment it or submit modifications to it to make it meet
our needs. I understand the disman expression mib is considered a dog;
maybe we should work to fix it rather than chuckle and design yet
another. I understand the standards-track script mib may be more general
purpose than we need, but we could try to work with it by proposing a
standardized subset for snmpconf use rather than designing a new
language which requires separate conditions and actions, which as a
result will not be compatible with the disman standards-track efforts of
the IETF.

It is hard to sell people on the merits of using standards when the
working groups of the IETF refuse to use each other's standards, and
would rather reinvent the same wheels.

If you're checking consensus, I'm also in favor of looking harder at the
disman work, plus work done by other working groups, to reduce the
amount of reinventing we do.

dbh

> > So if we continue to disagree about the
> > general approach, then we can just see who comes up with a working
> > solution plus implementation first.
> 
> It is sometimes the case that people will disagree, as is
> apparently the case here. Thanks for your contributions, we
> hope you will continue to contribute even if you believe the
> working group is wrong about something.
> 
> Cheers,
> 
> David (and Jon)

-- 
---
David Harrington            Network Management Standards Architect
dbh@enterasys.com           Office of the CTO
+1 603 337 2614 - voice     Enterasys Networks
+1 603 332 1524 - fax       Rochester NH, USA