Subject: snmpconf Proposed agenda for interim meeting

From: David Partain <[email-masked]>
Date: Mon, 16 Oct 2000 14:12:26 +0200

Hello all,

Jon and I have spent some time hashing over the agenda for the
interim meeting.  Please find our suggestion below.

We'd be grateful for your feedback, in particular regarding
things that we might have left off.  Please let me know as soon
as possible, since the final agenda will be finished by Friday.

  Script MIB discussion (Partain/Waldbusser)

    * show me the commercial implementations in boxes
    * are the semantic differences important and valid
    * it's a general tool but we may want a specific tool
    * is it too much of a good thing

    Necessary reading:  rfc2592 and policy management mib

  Language discussion (Waldbusser)

    Proposal:  we use the language that is specified in the
    policy module.  What do we need to change to make it
    work better?

    Necessary reading:  policy management mib

  Execution environment discussion (Waldbusser)

    Proposal:  we use the environment that is specified in the
    policy module.  Given this, what do we need to change to
    make it work better?

    Necessary reading:  policy management mib
    
  Scheduling module discussion (Hongal/Saperia)

    Proposal:  scheduling will be done with the scheduling MIB,
    and we need to discuss what needs to be done to make this
    work well.

    Necessary reading:  RFC 2591 (scheduling MIB) and policy
    management mib

  Policy grouping, precedence, and termination (Saperia)

  Status of the diffserv MIB (Hazewinkel)

    * what's been done
    * what's still to be done
    * whether or not our MIB disappears/how it's changed
    * outlook for progress

  Implementations? (Partain)

  What to do about Jon Saperia's ID (Partain)

    Necessary reading: draft-saperia-policysnmp-00.txt

  Status of the IPSec Policy WG cooperation (partain)

Cheers,

David Partain

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 17 Oct 2000 12:09:06 +0200

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

FYI: We decided to work on a policy runtime system which is based on
existing implemented MIBs. 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.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  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/>

---

From: David Partain <[email-masked]>
Date: Wed, 18 Oct 2000 15:26:19 +0200

Greetings Jürgen and all the rest of you,

Thank you for your mail.

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

A second reason for using the Script MIB is the claim that
they match SNMPCONF needs semantically.  Hence bullet number 2.

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.

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

Is there anyone going to the interim that you would be willing
to entrust with communicating your viewpoint?

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

> So if we continue to disagree about the

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)

---

From: David Harrington <[email-masked]>
Date: Wed, 18 Oct 2000 12:31:03 -0400

Hi David,

> interesting - although by no means critical.  Hence the
Enterasys is considering implementing the DISMAN mibs, including the
Script MIB.
It would be good not to have multiple interpreters in each device. 

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

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

> 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

-- 
---
David Harrington            Network Management Standards Architect
[email-masked]           Office of the CTO
+1 603 337 2614 - voice     Enterasys Networks
+1 603 332 1524 - fax       Rochester NH, USA

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 18 Oct 2000 13:55:05 -0400

In the paragraphs I have excerpted, you raise two questions I would like to 
comment on:
1) "The operator / implementor can choose the policy expression language 
they prefer".  This actually seems counter-productive.  If I am trying to 
epxress policies across devices, and different device implementors have 
implements different expression languages, I do not get close to what I 
want.  I do note that later you suggest we might use the script MIB 
technology, but remove the language choice.

2) You express concern about the iteration implicitr in the current 
environment.  There seem to be two sides to this coin.  One side says taht 
magic iteration is usually dangers.  The other side says that writing 
scripts which control the iteration, and explicitly specify the 
rescheduling of the operation of the scripts, and additional the validity 
time windows of the scripts, and the scratchpads for the scripts, etc... is 
prone to significant complication.  It seems to me that it is important to 
provide some easy way to get the common cases of iteration and repetition 
of policy checking.  But I am not sure where the line falls on this.

Yours,
Joel M. Halpern

---

From: Steve Waldbusser <[email-masked]>
Date: Wed, 18 Oct 2000 10:27:59 -0700

> It would be good not to have multiple interpreters in each device.

The script MIB doesn't dictate any language - it is independent of the
language, and thus the interpreter. So a script MIB implementation could
use only the PM language - it's up to the implementation.

Also keep in mind the requirements analysis for the language and the
execution environment: the language for the PM MIB is being designed so
that it can run on every managed device in an organization (spanning a
wide range of device capabilities). Disman's script MIB, on the other
hand, was designed to be run on those systems large enough to be given
mid-level manager characteristics (and burdens).

> need to rely on some level of magic for the thing to work.

The "magic" has been eliminated with the addition of the
elementTypeRegistrationTable. This enabled very explicit instructions in
the spec on how the iteration works.

> If we make our
> DISMAN environment;

Because of the design of disman's script MIB, a script MIB
implementation is able to use the PM language. They can do this today
regardless of the compatability of script mib objects with PM mib
objects.

> if they'd rather do policy using perl or javascript,
> they could use that within a disman environment; 

This is also something implementors have had the capability to do for
some time, well before the existence of the snmconf group.

Steve

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 Oct 2000 15:10:20 +0200

>> 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
implementation.

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
productive).

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

/js

---

From: David Partain <[email-masked]>
Date: Thu, 19 Oct 2000 15:46:44 +0200

Greetings Jürgen,

> that is why we read this mailing list. ;-) 

Thank you for your information and the questions you raise.  I
look forward to seeing your work progress and hope it will
include an implementation of our work (for comparison, of
course ;-)) in Jasmin.

Cheers,

--
David Partain                  [email-masked]
Ericsson Radio Systems AB      Tel: +46 13 28 41 44
Research and Innovation        Fax: +46 13 28 75 67
P.O. Box 1248
SE-581 12  Linköping, Sweden