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

snmpconf Interim Meeting Notes Day One




The following are the interim meeting notes for day one of the
SNMPCONF working group interim meeting that took place in Pittsburgh
PA on August 4 and 5, 2000.

If you have comments or clarifications, please send them to
moulton@snmp.com.  Please submit any changes you have by
end of the day Wednesday September 6.  I will merge changes and
submit the minutes to the IETF on Thursday September 7, and resubmit
them to this list if there are significant changes.

I have received no slides for the first day of the interim meeting,
and only Thippana Hongal's slides for the second day.  If you have
slides to include, please submit them as soon as convenient.


---
Steve Moulton        SNMP Research, Inc            voice: +1 865 573 1434
Sr Software Engineer 3001 Kimberlin Heights Rd.    fax: +1 865 573 9197
moulton@snmp.com     Knoxville, TN 37920-9716 USA  http://www.snmp.com


SNMPCONF Interim Working Group Meeting Summary
Pittsburgh, PA, USA
August 4th and 5th, 2000

This set of notes is for the part of the meeting that took place
on August 4, 2000.


The Configuration Management with SNMP (SNMPCONF) working group
met during an interim session on Friday and Saturday, August 4 and 5,
2000.  The purpose of this meeting was to continue making forward
progress while parties were present for the 48th IETF.

The note takers for this session were Shawn Routhier and Steve Moulton.


The first topic for discussion was which language might be used
to express policy to the SNMPCONF policy.  A subset of C that
might be used has been laid out in draft-ietf-snmpconf-pm-02.txt.
This discussion was moderated by Steve Waldbusser, and is a
continuation of the discussion started in the second meeting
of the SNMPCONF Working Group during the 48th IETF.


Item 4: Language Extensibility.

The first question on the floor is whether or not we should state
that we permit vendor-specific language subsetting.  In
particular:

Issue 1:  Do we allow vendor specific subsetting of the language

There is general agreement that as a working group we can't stop
producers from behaving in various fashions, but we can specify
what is compliant with the specification and what isn't.  There was 
some discussion about what level of extensibility we can and should 
provide.   The options included trying to trying to limit 
extensibility, allowing it but frowning on it, attempting
to provide for it directly, and allowing unknown extensions to be
handled gracefully.  There were the usual interoperability
concerns and the concern that limiting growth of the language
will limit its deployment. 

Specifically on the issue of subsetting the language,  the
statement was made that not allowing subsetting may drive us to 
reduce the number of functions included in the specification in 
order to get as wide deployment as possible of the required
functionality set.  The observation was also made that we can
expand the requirements of the language in a second version.

On putting the question, there was general agreement that we
should not permit vendor specific subsetting of the language in
the first version.

Issue 2:  Do we allow vendor specific subsetting of the accessor functions?

The first concern had to do with systems that do not have the
concept of time.  The sense of the room from this morning's
session is that we will not mandate time of day clocks.

Is the current set of accessor functions sufficient?  It does not
allow many possible options such as getting an entire row.  It is
generally agreed that the current set is not sufficient and more will 
be required.

But how should they be presented?  As one example if we include
accessor functions for SNMPv3 then what should happen if the 
agent doesn't support v3.  In such a case we might want to have 
something similar to libraries such that different sets can be included.

For the first revision we may want to keep the list short and
simple and add new ones after we gain some experience with the scheme.  
Some of the experience can be gathered from other similar areas.

But if the current list is not the final one then attempting to
discuss this issue may be premature.  Until we have a reasonable list 
we can't be specific.

One probably will not have a good handle on which accessor functions 
are needed until one has built a set of applications.  There are 
expression evaluators that have been in the industry for a few 
years, from which we can draw lessons.

.  Can we have a statement of direction that we should attempt to
   define the minimum mandatory set such that everybody can implement it?

The suggestion was made that we have containers of functions - the 
equivalent of libraries and that the minimum compliance object would 
be those groups.  So some of the libraries would be conditionally 
required but we would not end up with a constantly growing list.  
The libraries might be viewed as putting some hierarchy into the naming,
instead of having one flat name space have a two level name space.

Steve Waldbusser proposed a set of classes of things that
might not be implemented on a given system:

.  Can't do (turnOffPower())
.  Too Complex (code size/cpu speed limitations)
.  Convenience Functions: too many functions specified

One proposal that rather than follow this approach we
will specify a minimal set of functions so that no one will
have a good excuse not to implement the entire set of functions
in version one of this language.   

Another proposal is that we have two classes of accessor
functions, one which must be implemented, and one that
should, but that without which one may still claim compliance.
Functions to do RMON-specific things are one such example quoted.

One participant expressed a wish to have date and time functions
split off into a separate group for compliance purposes.  Another
suggested that there be three classes of accessor functions:

.   mandatory
.   MIB-related (i.e. RMON support)
.   device-related (power on/off, date and time).

Furthermore we need a way for the managed element to tell
a manager what subsets of functions a device supports.

When put to the group, there was general agreement that we need
groups of accessor functions for compliance purposes.
Furthermore there was general agreement that we were going
to be very rigorous in adding functions to the various
groups.

Discussion then shifted to how one indicates whether a
particular group is supported in an agent.   One proposal was
to specify using a bit string object, the other using a table of
supported groups (an agent capabilities table).  The first
proposal would require less agent resources, the second may be
easier to implement on run-time extensible agents.

A concern was made that we are departing from the policy model,
where we send a policy to all boxes and have the boxes decide for
themselves how to implement that policy.  This would require that
the policy-issuing entity know capabilities of each device.  One
way to handle this would be to bind accessor groups to MIBs being
accessed by a particular policy.

A smaller team was chartered to discuss this outside of the group
and report tomorrow.  The group consisted of Jeff Case, Steve
Waldbusser, David Harrington and Walter Weiss.

[break]

Jon Saperia asked the subgroup to study issues of collapsing
capabilities table information also.  What is the best way to
advertise availability of accessor libraries?

The next set of language and accessor issues:

Issue 3: Do we allow vendor extension of the language
Issue 4: Do we allow vendor extension of the accessor functions
Issue 5: Do we recognize vendor extensions of the accessor functions

Walter Weiss made the point that the premise of policy is that we 
are trying to work across devices to make management a simpler
world.  He suggests no to c and yes to d.  Bert Wijnen made
the opposing point that this working group was formed because of 
concern from the SNMP community about two management protocols.   
This group was tasked to do both policy-based management and
configuration management.  He was concerned that in the interest
of simplicity and adherence to the policy model we may remove too
much functionality for configuration via SNMP.

Jon Saperia made the point that we need to difference between policy 
based configuration (across systems) and configuration of policy 
(diffserv).  It is also true that we need to know a bunch of 
capabilities of the machine before we send policy to it.  This is 
very valuable configuration management.  In the charter we two have
goals.  I don't think they conflict with each other, so we need to 
do both.  We haven't excluded one or the other at this point.

After a considerable discussion the question was called on issue
c, and there was fairly strong consensus that we did not want
to allow vendor extension of the language.  There was general
agreement that we do want to allow vendor extension of the 
accessor functions (issue 4).

There were three different proposals for determining the presence
of vendor extensions.  One was to have a
accessorExists(accessorFunction) function, another to have a BITS
construct for enumerating what functionality is present, and the
third was to use the capabilities mechanism already familiar.
In response to a concern about name space conflicts, 
a suggestion was made to use part of the company's DNS name as
part of the function name to guarantee uniqueness (like is done
in Java).  The observation was also made that if we can do this
within the SMI, we already know how to deal with it.

Issue 5 is being deferred to the smaller group.

Issue 6: How do we handle versioning issues, is being sent to the
small group.

Issue 7: Changes in OID issue is also being sent to the small group.

Issue 8: How do we specify attributes of an element?  Can
there be multiple instances?  As discussed this morning [
IETF48 SNMPCONF Working Group Meeting -ed], multiple
instances can be specified as name.$1.$2.$3.

Issue 9: deferred (not available in notetaker's notes)

Issue 10: How big can an expression be?  An arbitrary
limit of 64K was mentioned; there is no real limit.  This
was discussed in the morning session.  The point was made that
we need to pay special attention into buffer overflow problems since 
this is a script issue.  Good programming practice should be
adequate.

Issue 11:  Temporary Variables: do we want them?  How do we
dispose of them?

There was strong sentiment that temporary variables are needed.
Questions were raised about the scope and lifetime of temporary
variables.  Possibilities such as the use of a global scratch pad
and emulating MIB variables were raised.  The use of temporary
variables for lag variables and trending was discussed, as well
as for generally saving state in a loop.  It is necessary that
any global variables created have some indexing to prevent access
anomalies across different scripts.  The requirement that each
policy has to have a local temporary variable space was
mentioned.

The issue of short-circuiting loop execution arose.  Once again the 
discussion arose whether we are taking the policy view (all devices) 
or configuration view (one or more devices).  

It was suggested that this topic be taken away and discussed
further tomorrow.

Jon Saperia reviewed the working assumptions again:

1)  We cannot invent a new language

2)  We want to use something that is as familiar as possible to as many 
    people as possible.  We settled on Java, Perl, and C as
    possibilities.   What is currently in the document
    is a subset of the intersection of C and PERL.
3)  We are not saying that different languages can be used
    in different evaluations.

    We are discussing the concept of a break statement in a loop
    construct, the storage of temporary variables, and the ability to 
    preserve information across executions.

    We need to have a side discussion on this issue.

[break]

Issue 12: Debug-able execution environment.  Issues include
  .  Memory leak detection
  .  ability to find and fix bugs
  .  find looping and iterators

The suggestion was made that we may need to have watchdog timers
to break out of iterations, or perhaps to set a limit on the
number of times to iterate.  If using a timer scheme, one needs
to be able to match timeout information to restart information.

The ability to trace execution through a script is very
important.  One might use a log table to log output from the
script for debugging purposes.  Implementing a trace function as
an accessor function was suggested.

Issue 13:  Do we permit comments?  We need to explicitly say so.

There was a general feeling in the room that comments should not
disappear from scripts.   Gets on the script should retrieve the
same contents that sets put with respect to comments.  

A more general issue about string length arose at this point.  
There was concern about string length being limited by PDU size.  
The question was put as to whether we should modify the policy table 
and add a new table to allow for longer strings.  There was strong 
agreement for this change.

David Harrington mentioned that some script interpreter code was
in use at Enterasys, and that he might be able to contribute this
interpreter to the community at large.   The possibility of using
bc (the unix binary calculator) was also mentioned, as was PHP
(from the Apache world).

Script re-usability was also discussed at this point; specifically
whether a script can refer to another script already in the
device.  Currently this is not a capability of the MIB.  The
following MIBlet was put on screen

PmPolicyEntry ::= SEQUENCE {
   pmPolicyIndex Integer32,
   pmPolicyFilter  OCTET STRING,
   pmPolicyAction  OCTET STRING
   ...
}

The suggestion was made to replace the pmPolicyFilter with a
script MIB entry.  The opposing view was that we should not pull
in the script MIB, but add multiple lines of text to the
pmPolicyTable.

The suggestion was made to change the pmPolicyFilter and the pmPolicyAction
octet strings into integers.  The clear sense of the room was to split
out the pmPolicyTable now, and replace these objects with integer
indices.

At this point, a brief review of issues for tomorrow's meeting
was made.