NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.
Chair(s):
Randy Presuhn <rpresuhn@peer.com>
Operations and Management Area Director(s):
John Curran <jcurran@bbn.com>
Michael O''Dell <mo@uu.net>
Operations and Management Area Advisor:
John Curran <jcurran@bbn.com>
Technical Advisor(s):
Bob Stewart <bstewart@cisco.com>
Mailing Lists:
General Discussion: disman@nexen.com
To Subscribe: majordomo@nexen.com
In Body: subscribe disman your_email_address
Archive:
Description of Working Group:
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
· Define a Script MIB
· 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 o Topology discovery
Goals and Milestones:
May 96 |
|
Post Internet-Draft for Threshold Monitoring MIB. |
Jun 96 |
|
Meet at the Montreal IETF meeting to discuss charter and review the Threshold Monitoring MIB Internet-Draft. |
Jul 96 |
|
Post Internet-Draft for Framework document. |
Aug 96 |
|
Post Internet-Draft for Script MIB. |
Sep 96 |
|
Hold an interim meeting to discuss Internet-Drafts and issues that come up on the mailing list. |
Nov 96 |
|
Submit final version of Threshold Monitor MIB Internet-Draft for consideration as a Proposed Standard. Submit updated versions of Internet-Drafts for Script MIB and the Framework document. |
Dec 96 |
|
Meet at the IETF meeting to discuss Internet-Drafts and issues that come up on the mailing list. |
Feb 97 |
|
Submit final versions of Internet-Drafts for Script MIB and Framework document for consideration as Proposed Standards. |
Internet-Drafts:
· Definitions of Managed Objects for the Delegation of Management Scripts
· Distributed Management Framework
· Event MIB
· Expression MIB
· Management Target MIB
· Notification MIB
No Request For Comments
Minutes of the Disman Meeting
Reported by Steve Waldbusser
I. Agenda
1) Administrativia
2) Technical Presentations (none offered)
3) Discussion
- SNMPv3
- Framework
- Target MIB
- Expression MIB
- Script MIB
- Notification MIB
- Common Issues
4) Future Work
5) Closing
- Action Items
- Interim Meeting
- Next Meeting
II. Status of new Charter
It is ready to go forward through the IESG process. Note it was mentioned that there are new requirements for IETF specifications that the document editors need to conform to for our work (standard ops guide changes for security and internationalization)
III. Framework Issues
Due to SNMPv3, the framework document needs to change. Specifically much of the notification work has become part of the SNMPv3 framework. The Target MIB may also need to be updated or deleted. Andy Bierman will review the target MIB to see what changes might be warranted.
There was some discussion about the additional framework issue of delegation of authority. There were three options discussed:
1) Disman functions run with the authority of the disman system
2) Disman functions have security "tokens" downloaded along with the "script"
3) Disman functions have security "tokens" downloaded along with the "script," as well as the ability to have setuid privileges
The discussion that ensued preferred Option #2 to Option #1.
Filtering, transmission, and logging were identified as the three notification functions. Steve Waldbusser mentioned two event-related issues that Bob Stewart and David Levy agreed to bring up in the SNMPv3 group:
1) If the network duplicates a notification, there is no way for the receiving application to tell that 2 events did not occur.
2) If an application wants to send a notification that contains more varbinds than can fit in a PDU, there is no way to associate the multiple PDUs that result so it is clear that they are part of the same transaction.
There was some discussion about the conflict between our common usage of the term "application" and the new SNMPv3 usage of that term. This is particularly problematic in the DISMAN group because we talk about applications a lot.
Bob Stewart mentioned that Cisco is implementing the Expression MIB. The experience to date is that it is somewhat complicated. Bob will report back more experience and believes that in about two months he can revise the Expression MIB.
The Script MIB needs to be updated to deal with naming WRT the issue of delegation of authority. Other issues need to be handled as well. Juergen believes he can get a revised draft out in September (before the draft expires).
There was some discussion on the multiple ways of handling scheduling of DISMAN apps (e.g., event-driven, scheduled). This is still an unsolved issue.
There was a lot of discussion about the lack of a common language for the script MIB causing interoperability problems. Jon Curran suggested that if we can't choose one, maybe we can choose a language of last resort. The discussion of narrowing the list of potential languages to a short list (hopefully one) was deferred to informal discussions during the course of the IETF meeting.
There was some discussion about the fact that in the current framework that IPv6 addresses are not supported as targets. It was generally agreed that this needs to be fixed.
There was discussion about the use of IMPLIED in the framework MIB and the fact that v1 compilers will not understand it. Once it was recognized that this is not a problem for using SNMPv1 PDUs (only v1 MIB compilers), the group agreed to keep using IMPLIED where appropriate.
The group agreed to switch all DisplayStrings in the disman MIBs to UTF8 format.
IV. Futures
The group agreed to have an interim meeting, possibly combined with the SNMPv3 interim meeting, and also to reserve two slots at the next IETF meeting.
None Received