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

Re: snmpconf Proposed agenda for interim meeting

>>>>> David Partain writes:

>> FYI: We decided to work on a policy runtime system which is based
>> on existing implemented MIBs.

David> That's very interesting.  Perhaps you could tell us who "we"
David> is?  Are you interested in external input to what you are
David> doing?

The people behind "we" are basically the guys involved in the Jasmin
project.  Of course, we are always interested in external input -
that is why we read this mailing list. ;-) 

As I said previously, I do believe that the language approach is a
good one. In fact, I do believe that getting the language right is
crucial - the way you distribute or schedule policy enforcing scripts
is IMHO of secondary importance. And that is why I argue that it is
better to reuse existing technology rather to reinvent the wheels. I
also believe that the assumption that each device under policy control
needs to be able to execute the language is wrong (but it seems that
the language in the latest ID seems to reflect this as it looks like
you can operate via SNMP on remote systems - but the details are
still unclear for me).

I also believe that it is important to build on experiences with
existing (scripting) languages, even though the requirements for a
policy language are somewhat different. As some of you may know, I
have done quite a bit of SNMP scripting in the past and this may help
to get some language tradeoffs right. (Do not mis-read this as Tcl is
what I propose. For those interested, I have actually written a paper
about being "Married with Tcl" [1] which summarizes my experiences
made with Tcl over the years.) Looking at the latest ID, I am still
wondering what the concepts behind the proposed language are. What is
the data typing model? What are the scoping rules? Why are there
pointers in function declaration although there are not pointer types?
And should there be pointers at all? So what is the parameter passing
model? What is the error handling model? How minimalistic is the
language? Does a concept of statically globally numbered varbind lists
make sense in the 21st century? What is the flow control logic? What
about an asynchronous event-driven or threaded execution model? ...

David> I must admit, though, that I would prefer that efforts be
David> concentrated on implementing what the IETF working group is
David> doing, regardless of whether you agree with the concensus of
David> the working group or not.

The snmpconf WG is IMHO the typical example of a WG which tries to
solve a problem by creating a standard (the language) from scratch. I
generally believe that it is much more efficient to build from
concrete proposals rather then trying to achieve concensus too early
in the design phase. In that sense, I expect that much more time is
needed to finalize the snmpconf drafts. Since the Jasmin project is a
research project, we have the freedom to figure out what we believe a
good solution should look like. Perhaps we will fail. Perhaps we will
be too late for snmpconf.  But this does not really matter since we do
not do products and we do not have to do standards. We just do applied
research, usually backed up by an open source proof of concept

David> It is sometimes the case that people will disagree, as is
David> apparently the case here. Thanks for your contributions, we
David> hope you will continue to contribute even if you believe the
David> working group is wrong about something.

Just to be clear: I am not in any way negative or upset and I
certainly do not want to hold this WG off from making progress. I just
believe that there are better ways to address the problem. And the
most efficient way at this point in time is IMHO to try to come up
with a concrete proposal about what we have in mind, rather then
spending too much time in email discussions (which are not really that

[1] http://www.ibr.cs.tu-bs.de/vs/papers/tcltk-eu-2000.ps.gz


Juergen Schoenwaelder      Technical University Braunschweig
<schoenw@ibr.cs.tu-bs.de>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>