NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 18-Mar-98
Chair(s):
Randy Presuhn <rpresuhn@bmc.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:
o 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:
o RFC1451, The Manager to Manager MIB which was being considered by the SNMPv2 working group
o the RMON working group's work in this area
o the SNMP Mid-Level-Manager MIB which is now an expired Internet-Draft
o 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:
o 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
· Definitions of Managed Objects for Scheduling Management Operations
No Request For Comments
Minutes of the Distributed Management (disman) Working Group
Reported By Steve Waldbusser
Agenda Revisions
None
1) Common issues remaining for security/access control and delegation
a) common indexing description in framework. There was a short discussion about the need for intelligent design of the indexing of certain tables so that they can be used with the view-based access control mechanism.
b) security considerations sections. It was brought up that security considerations sections have not been prepared for each of the MIBs, nor are they consistent. It was also brought up that until some of the delegation control issues are resolved, it will be difficult to fully describe all security considerations. This was identified as work to be completed to advance the documents. (There are now IESG standards for what is required for the security considerations).
2) Finishing up current projects
a) is script mib ready for WG last call?
i) representation of delegation
ii) restriction of delegated rights
The WG discussed how to solve the unresolved issue of delegating rights to scripts. This is complicated by the fact that scripts use not just SNMP rights, but also local-system rights. There was general consensus that a mapping table is required to map which rights are available to which script invocation instances.
There was a long discussion about how important it is to provide for description of access rights while considering the potential complexity of the solution. There was no consensus of this discussion, however many agreed that the solution is probably not too complicated. A strawman was proposed that the group define a mapping table for SNMP access rights, but to defer a mapping mechanism for local-system access rights.
It was suggested that when a request is received for a script to be invoked, after determining that access to the request is valid, that it will then check that the invoker of the request also has read access to the script (as if it issued a get request for the script contents).
The WG reached consensus that script interpreters should be identified by three objects: an OID for the language, the enterprise OID for the vendor, and a string for the version.
The WG reached consensus that when downloading scripts, resource problems with creating a new script would be signaled through an inconsistent Value error in the set response, while scripts with correctness issues provide noError in the set response but indicate the error in the results table.
b) is schedule mib ready for WG last call?
The WG reached consensus that when a schedule entry is only partially set up, its default behavior is to do nothing. Note that this is different than changing the DEFVAL clause.
The WG reached no consensus as to whether the schedule MIB should be expanded to work on remote systems.
c) is expression mib ready for WG last call?
d) is event mib ready for WG last call?
e) is notification log mib ready for WG last call?
It was suggested that some explanatory text be added to describe the operations of the expression, event, and notification mibs. Some members expressed that they could not perform a viable review of the MIB until this happens.
3) Issues raised on mailing list that have not been discussed:
a) what more needs to be done to get the framework ready for WG last call?
The consensus is that the near-term framework document should include the framework overview as well as the access-control mapping tables (a.k.a. delegation control services).
b) any interest in WBEM?
The consensus is that there is little overlap and that WBEM ties would make little sense.
c) A brainstorming session then ensued regarding how to ensure greater market acceptance of disman technology.
None Received