Current Meeting Report
2.3.5 Distributed Management (disman)
NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It
may now be out-of-date. Last Modified:
Randy Presuhn <firstname.lastname@example.org>
Operations and Management Area Director(s):
Randy Bush <email@example.com>
Bert Wijnen <firstname.lastname@example.org>
Operations and Management Area Advisor:
Bert Wijnen <email@example.com>
To Subscribe: firstname.lastname@example.org
In Body: subscribe disman your_email_address
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 which can be consistently developed and
deployed. A distributed network manager is an applicaton 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 main communication mechanism for monitoring
and control 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 architecture defined in RFC 2571. 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 Scheduling MIB
Define a Script MIB
Define a Remote Operations MIB
Define an Expression and Event MIB to support Threshold Monitoring
Define a Notification Log MIB
Define an Alarm MIB
The working group will consider existing definitions, including:
o the RMON working group's work in this area
o the Application MIB (RFC 2564), SysAppl MIB (RFC 2287) and
The work on the Alarm MIB will take into consideration existing
standards and practices, such as ITU-T X.733. Whether any mappings to
these other standards appear in the Alarm MIB or in separate documents
will be decided by the WG. The WG will actively seek participation
from ITU participants to make ensure that the ITU work is correctly
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:
|Done||  || Post Internet-Draft for Threshold Monitoring MIB.|
|Done||  || Meet at the Montreal IETF meeting to discuss charter and review the Threshold Monitoring MIB Internet-Draft.|
|Done||  || Post Internet-Draft for Framework document.|
|Done||  || Post Internet-Draft for Script MIB.|
|Done||  || Submit final version of Threshold Monitor MIB Internet-Draft for consideration as a Proposed Standard. Submit updated versions of Internet-Drafts for Script MIB.|
|Done||  || Meet at the IETF meeting to discuss Internet-Drafts and issues that come up on the mailing list.|
|Done||  || Submit final versions of Internet-Drafts for Script MIB and Schedule MIB document for consideration as Proposed Standards.|
|Done||  || Agree on charter revisions for future work.|
|Done||  || Submit final versions of Internet-Drafts for Expression, Event and Notification MIB documents for consideration as Proposed Standards.|
|Done||  || Submit final version of Internet-Draft for Remote Ping, Traceroute, and Lookup Operations Using SMIv2|
|Done||  || Meeting in Oslo to discuss implementation and deployment experience with Schedule and Script mibs, identify any updates needed to these documents.|
|Done||  || WG agreement on direction regarding mappings to / from other alarm frameworks|
|Done||  || Submit updated Script and Schedule MIBs for consideration as Draft Standard (or recycle at Proposed).|
|Mar 01||  || decision on question of whether recycle the Log MIB.|
|Done||  || Submit updated draft of Alarm MIB for IETF meeting|
|Done||  || Submit updated draft of Alarm MIB for IETF meeting.|
|Oct 01||  || call for implementation experience and updates to the remote operations MIB.|
|Oct 01||  || call for implementation experience and updates to the Event and Expression MIBs.|
|Dec 01||  || WG last call on Alarm Management MIB.|
|Jan 02||  || Alarm Management MIB delivered to IESG for consideration as a Proposed Standard.|
Request For Comments:
|RFC2591||PS||Definitions of Managed Objects for Scheduling
|RFC2925||PS||Definitions of Managed Objects for Remote Ping,
Traceroute, and Lookup Operations
|RFC2982||PS||Distributed Management Expression MIB
|RFC3014||PS||Notification Log MIB
|RFC3165||PS||Definitions of Managed Objects for the Delegation of
Current Meeting Report
Minutes for the meeting of the disman working group session at the fifty-second IETF meeting in Salt Lake City were reported by Dan Romascanu and fleshed out by Randy Presuhn.
No changes to the posted agenda were required.
The working group reviewed the status of its current documents. Ram Kavasseri gave a report on Cisco's implementation of the Expression MIB. Their implementation first shipped in December 1998, and was based on first draft of DISMAN expression MIB, rather than on RFC 2892.
Ram reported on Cisco's implementation of the Event MIB. They have implemented it on several platforms, and one customer is working to deploy it in a production network. The clarification questions that have arisen so far do not seem to require special clarifications in the MIB text. One difficulty that has arisen is that it doesn't provide a convenient way to apply thresholding for a range of ports. Ram took the action item to provide an example to the WG mailing list.
Ram also gave an implementation report for Notification Log MIB (RFC 3014). Cisco finished implementation two moths ago, product is not yet in the hands of customers. They only needed support for default log.
Named logs are supported in code but not enabled due to question regarding access restrictions. The chair clarified that only ordinary VACM access control needs to be taken into account when the log is polled. Ram took the action item to clarify this in the text.
The group reviewed issues from the mailing list regarding the Notification Log MIB. The sense of the room on the following issues was that:
- inform resends, if detected as such, are not added to a log;
- the question of whether adding a column to the nlmLogTable to report how many variable bindings are stored in nlmLogVariableType in order to reduce the number of queries needed for retrieval was deferred so that Sharon Chisholm could do the math so that the mailing list could discuss the cost/benefit ratio with numbers in hand;
- the question of adding a variable to indicate the current log index for each named log was deferred in the same manner;
- it was agreed that text be added to indicate that no access checks beyond those required by VACM need be done when log is polled;
- access efficiency of notification logs was discussed at length. Ram and Dave Perkins will get together to create an alternate MIB proposal for more efficient retrieval, prototype it, and test it in real life scenarios. If the result implies changes that prevent advancement, the priority is on providing the right solution;
- finally, the question was raised whether we should add an nlmLogConfigAgeout for each log? Since this is a new question, this will be discussed further on the mailing list.
The group spent a few minutes looking at new and related work from other working groups. The first was the question of persistancy and the use of the StorageType textual convention. This is not handled consistently in the Event, Expression, and Log MIBs, and needs to be fixed. Ram will develop specific proposals. The second point was that the DMTF event work, originally based on X.733, has added more probably causes. Andrea Westerinen was reported to have offered to forward these additions to the disman group.
Sharon Schisholm presented the status of the Alarm MIB work and reviewed the remaining open issues. A few questions arose during the discussion:
- does the new index in the Clear table indicate clear time? answer yes, keeps the index for correlation with original.
- do we want to add an example to illustrate the relationship to the event MIB? no.
- the discussion of EngineId vs. ContextEngineId was revisited, and agreed that although it might be relevant for the proxy case, the disctinction was ultimately more trouble than it was worth, and was consequently taken out of the MIB
- Discussion of the Telecordia model was tabled until information becomes available;
- Detecting Change of state - clarification of activeAlarmModelPointer is to be changed in 04 version of the document.
- Editors will do their best to issue the draft-04 next week, a Last Call will be issued for a longer period than usual, taking into account the holidays;
- Ram and Dave P. committed to read and review
- Randy will ask on the list for positive and negative feedback as well
Kam Lam led the discussion of the Condition MIB and ARC MIB draft.
He reviewed the changes from version 00 to version 01. The open issues include:
- terminology for condition to be taken on the mailing list, with Kam to initiate the thread;
- Alarm Raised and Clear should point to the Alarm MIB;
- Alarm type definition: it was agreed to delete section 3.2;
- Section 4.1 readability: text needs fixing, diagram should be taken out
- change 'clarification' in Section 5 that says that when a resource is in ARC mode active alarm information SHALL be available for retrieval by the managing system - change active alarm with condition information;
- section 5.1 - ARC impact on alarm notifications - needs to be further work on the mailing list;
- relationship with Alarm MIB - Sharon to propose text on the mailing list
Glenn Keni gave a brief review of the work on A Clustering Architecture for Replicating Managed Objects, a replication MIB for fault tolerance. Further discussion is invited on the working group mailing list.
The meeting concluded by agreeing that there was not yet sufficient implementation or deployment feedback to merit advancement of the Expression, Log, or Event MIBs at this time. The mailing list will need to discuss the progress of the ARC/Condition MIB to determine what to do about its target date.
A Clustering Architecture for Replicating Managed Objects
Alarm MIB (Generic & ITU)
RFC 2981 (Event MIB) Implementation Report
RFC 2982 (Expression MIB) Implementation Report
RFC 3014 (Notification Log MIB) Implementation Report