Editor's Note:  These minutes have not been edited.


Minutes for Distributed Management meetings, April 7, 1997
Reported by David Levi
-------------------------------------------------------------------------

The meeting started with a couple of announcements.  First, the new
charter is close to being accepted by the IESG.  The schedule in the
new charter extends work though the Munich meeting.  Second, there
needs to be text written for all of the DISMAN IDs for security
requirements.

There were four technical presentations.  Andy Bierman gave a short
presentation about the document he recently submitted regarding
integration for trap filtering with the script MIB.  Juergen
Schoenwaelder presented the list of open issues in the script MIB,
and discussed his implementation of the script MIB.  Steve Waldbusser
gave a presentation about the DISMAN framework and services.
Bob Stewart presented the MIBs he recently posted, and went
through a detailed example of how one would use them.

There were two topics which were discussed throughout the presentations
and throughout the meetings, integration and security.


Integration
-----------

Currently there is very little integration between the various IDs related
to DISMAN.  For example, there isn't a mechanism in any of the framework
documents for executing a script defined in the script MIB when a trap
is received by a distributed manager.  The document that Andy Bierman
posted was intended to get discussion started on this topic.  There
is general agreement in the group that there needs to be integration
between the various documents.

There was also some discussion about how the various MIBs should be
split among multiple documents.  It might be useful to have the MIBs
related to different framework services be in separate documents in
order to make it easier for an implementation to only use the services
it needs.  Another was to accomplish this is to have different
conformance statements in the framework MIBs.  There was not complete
agreement on which approach should be used.

There is also some overlap in functionality between the various IDs.
Looking at where this overlap exists may help in determining how
documents should be split.


Security
--------

The DISMAN MIBs need to be designed in a way that can make use of (and
not conflict with) the SNMPv3 security mechanisms.  Of course, we are
anticipating that the SNMPv3 working group will be successful, and that
we'll have these security mechanisms available in the near future.

The security topic that received the most discussion was the issue of
how to have a management task which has been delegated to a subordinate
manager maintain the same access rights as the 'user' that delegated
the task.  For a specific example, a particular user might download
a script to an mlm and set the script to run every ten minutes.  When
the script runs and attempts to perform SNMP operations, the access it
has to other agents ought to be the same as the user who originally
downloaded the script.

There is probably also a need for the ability for one user to download
configuration info for a management task to an mlm, and for a different
user to be able to run that management task.  This is similar to a unix
program being 'setuid'.  A related question is whether such a management
task should have the privileges of the user who created it, the user who
ran it, or some combination.

The model that seems to be getting agreement for dealing with these
issues involves using careful indexing of MIB tables.  For example,
we might include the username of the user who creates a script in the
smScriptTable, and including both the username of the user who
created a script and the username of the user who runs a script
in the smRunTable.  This would allow the SNMPv3 access control
mechanisms to be used to control:
  - which users can create scripts,
  - which users can run scripts,
  - which users can run scripts that were created by another user (and
    which user's scripts they are allowed to run)

There is also the issue of determing SNMP version and community/key
information to be used by a management task that has been delegated
to an mlm.  There needs to be rather fine-grained control over which
community/key information is available to a particular
management task.  This is so that a user who configures a management
task (with the intent to allow another user to run that task) can
restrict which community/key information other user's can make use of
when running the task.

In order to accomplish this, there will need to be a way to download
a 'profile' to an mlm, and attach this to a management task (both when
it is configured and when it is executed).

There was discussion about whether IPsec would be useful to DISMAN.
While it might help with authentication, it will not help with
authorization (access control), or when using SNMP over other transports.


Framework Issues
----------------

There was more discussion about the services related to destinations,
or 'targets', of management tasks.  There are 2 parts to this:
    - keeping lists of all known systems
    - forming subsets of all known systems, i.e. the set of devices
      on which you want to perform an operation
Subsets of devices are selected by rules.  In the original framework
document, there were 2 'levels' of rules through which the list of known
systems would be run to get a subset.  This will probably be relaxed
so that there can be an arbitrary number of rules used.

There also must be some mechanism/language for expressing rules.  The
original document use a form of regular expressions.  It may be desirable
to use expressions or scripts as well.


Other
-----

Here are a few notes about Bob's presentation about his MIBs.  There
are 4 MIBs:

The expression MIB allows you to define a new object whose value is
determined by an expression involving other MIB variables.  There
are mechnisms for:
  - wildcarding the object involved in the expression
  - using delta values of objects involved in the expression
All objects in expressions are local to the agent in which the expression
runs.  One thing that needs to be fixed is that if you want an expression
to run in multiple contexts, you need to configure it in each context
(I think this means you currently cannot mix objects from multiple
contexts in a single expression).

The management target MIB is used to select a set of targets for a
management operation.  This MIB has some overlap with the framework
document.  It also provides SNMP version/community info for targets.
There are two kinds of targets, single systems, and groups of systems.

The notification MIB is intended to control where notifications are
sent, when they are sent, and to log/count notifications that have
been sent.  This MIB allows sending of notifications to be enabled
and disabled at three levels, per management target, per notification,
and per system.

The event MIB provides a mechanism for periodically checking a condition
and generating an event if the condition has been met.  The result of
generating an event is to take some action (sending a notification or
setting an object).