NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
Randy Presuhn <rpresuhn@peer.com>
Operations and Management Area Director(s):
Scott Bradner <sob@harvard.edu>
Michael O'Dell <mo@uu.net>
Deirdre Kostick <kostick@qsun.att.com>
Bob Stewart <bstewart@cisco.com>
General Discussion:disman@nexen.com
To Subscribe: majordomo@nexen.com
In Body: subscribe disman your_email_address
Archive:
The Distributed Management Working Group is chartered to define an initial set of managed objects for specific distributed network management applications and a framework in which these applications and others can be consistently developed and deployed. A distributed network manager is an application that acts in a manager role to perform management functions and in an agent role so that it can be remotely controlled and observed.
Distributed network management is widely recognized as a requirement for dealing with today's growing internets. A manager application is a good candidate for distribution if it requires minimal user interaction, it would potentially consume a significant amount of network resources due to frequent polling or large data retrieval, or it requires close association with the device(s) being managed.
The working group will limit its work to distributed network management applications where the communication mechanism used between managers (or the components of the management application) is SNMP. Future work (and other working groups) may be chartered to investigate other distribution techniques such as CORBA or HTTP. The objects defined by the working group will be consistent with the SNMP framework. The working group will especially keep security considerations in mind when defining the interface to distributed management.
The working group will complete these tasks:
· Define a Threshold Monitoring MIB o Define a Script MIB o Define a Distribution Management Framework and MIB · This last MIB is required in order to keep distributed managers from adding to the management problem. This MIB will allow distributed managers of many types to be controlled in a consistent way including controlling their "management domain" (the set of devices upon which they act), the relationships between the management applications or components, and to some extent the scheduling of their operation. The working group will consider existing definitions, including: · RFC1451, The Manager to Manager MIB which was being considered by the SNMPv2 working group · The RMON working group's work in this area · The SNMP Mid-Level-Manager MIB which is now an expired Internet-Draft · The work of the Application MIB working group
It is recognized that the scope of this working group is narrow relative to the potential in the area of distributed network management. This is intentional in order to increase the likelihood of producing useful, quality specifications in a timely manner. However, we will keep in mind and account for potential related or future work when developing the framework including:
Event and alarm logging and distribution o Historical data collection/summarization Topology discoveryGoals and Milestones:
· Definitions of Managed Objects for the Delegation of Management Scripts
· Distributed Management Framework
Minutes for Distributed Management (DISMAN) Working Group MeetingReported by: David Levi
The meeting started with announcements. First, the new charter is close to being accepted by the IESG. The schedule in the new charter extends work through 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.
Two topics were discussed throughout the presentations and meetings, integration and security.
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 is 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 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 way 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 some overlap in functionality between the various IDs. Looking at where this overlap exists may help in determining how documents should be split.
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 a 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 a need for one user to have the ability to download configuration information for a management task to a 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 determining SNMP version and community/key information to be used by a management task that has been delegated to a 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 a 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.
III. 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 two '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 uses a form of regular expressions. It may be desirable to use expressions or scripts as well.
Here are a few notes about Bob's presentation about his MIBs. There are four MIBs:
The expression MIB allows you to define a new object whose value is determined by an expression involving other MIB variables. There are mechanisms 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).
1. 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 information for targets. There are two kinds of targets, single systems, and groups of systems.
2. 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.
3. 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).
2. Definitions of Managed Objects for the Delegation of Management Scripts