2.4.3 Distributed Management (disman)

NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 01-Mar-99


Randy Presuhn <rpresuhn@bmc.com>

Operations and Management Area Director(s):

Harald Alvestrand <Harald.Alvestrand@maxware.no>
Bert Wijnen <wijnen@vnet.ibm.com>

Operations and Management Area Advisor:

Bert Wijnen <wijnen@vnet.ibm.com>

Technical Advisor(s):

Bob Stewart <bstewart@cisco.com>

Mailing Lists:

General Discussion:disman@dorothy.bmc.com
To Subscribe: disman-request@dorothy.bmc.com
In Body: subscribe disman your_email_address
Archive: ftp://ftp.peer.com/pub/disman/archives

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 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 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 Script MIB

Define a Scheduling MIB

Define a Threshold Monitoring 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:

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:



Post Internet-Draft for Threshold Monitoring MIB.



Meet at the Montreal IETF meeting to discuss charter and review the Threshold Monitoring MIB Internet-Draft.



Post Internet-Draft for Framework document.



Post Internet-Draft for Script MIB.



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.



Meet at the IETF meeting to discuss Internet-Drafts and issues that come up on the mailing list.



Submit final versions of Internet-Drafts for Script MIB and Schedule MIB document for consideration as Proposed Standards.

Jul 98


Submit final versions of Internet-Drafts for Expression, Event and Notification MIB documents for consideration as Proposed Standards.

Aug 98


Agree on charter revisions for future work.

Sep 98


Submit final version of Internet-Draft for Framework document for consideration as Proposed Standard.


No Request For Comments

Current Meeting Report

Minneapolis, 03/19/1999
Chair: Randy Preshun
Reported by: Rob Frye
Charter: http://www.ietf.org/html.charters/disman-charter.html

- Welcome, Introduction, Charter URL
- Administrative issues
- Status of current documents
- Technical presentations
- Wrapup

The disman working group met at 13:00 CST on 1999-03-18 at the 44th IETF meeting in Minneapolis, Minnesota. Rob Frye recorded the meeting minutes. Official count was 46 attendees, unofficial was about 50. The group briefly discussed the three DisMan drafts which are currently in working group last call, and spent most of the time working through issues with the remote operations draft, trying to focus on getting this document to last call. Although several possible additions or extensions to this work were discussed, the current path forward will be to complete this document without further significant embellishment.

The Working Group chair, Randy Preshun, took care of Administrative matters quickly. Rob Frye agreed to be the minutes taker, signup sheets were distributed, and it was stated that there should be no time allocation restrictions as the time was not expected to run over.

Randy provided the status of the current documents. The Script (draft-ietf-disman-script-mib-08) and Schedule (draft-ietf-disman-schedule-mib-06) MIBs have been approved by the WG and IESG and should be assigned RFC numbers soon. The Notify and Log MIB (draft-ietf-disman-notif-log-mib-09), Event MIB (draft-ietf-disman-event-mib-06), and Expression MIB (draft-ietf-disman-express-mib-08) are currently in WG last call. The Remote Operations MIB (draft-ietf-disman-remops-mib-03) was last released in December 1998 and needs to be updated for WG Last Call.

The Notify and Log MIB was the first draft discussed. Only five participants in the meeting had already read the draft. The chair pointed out an asymmetry of events placed in the Log MIB. Local events are filtered to check permissions of the log owner before writing an event to the log. Remote events have no filtering done (due mostly to VACM considerations with [stateless] proxy implementations). The group was comfortable with this reported asymmetry and expects no problem with approval by the IESG.

The Event MIB has one week remaining for WG last call. One question was raised by the chair regarding the "strange limits" of object mteResourceSampleMinimum (-1 | 1..600). Bob Stewart agreed that since he was the one who created it that he would investigate and document why those particular limits. If no good reason is found then the architectural constraints will be lifted. If no other concerns are raised, the draft will complete WG last call.

The Expression MIB has also had review by very few readers. The topic of interactions between owner indexes and VACM group configurations was initially discussed within the context of the Expression MIB. It was brought up then because the Expression MIB would be the logical place to gather results of remote actions such as pings, and the complexities of proper configuration of VACM, target addresses and owners impact the use of the Expression MIB to gather and report on the results of ping. Because the owner index issue pertains more to the Remote Operations MIB, it is described in these minutes as a Remote Operations document discussion topic.

The next discussion for the Expression MIB was about distribution analysis, particularly as applied to ping capabilities provided by the Remote Operations MIB. This turned into a more general discussion about "binning" capabilities. The chair suggested that we ask another WG to define general-purpose distribution analysis functions and requirements. The group consensus was that simple delay distribution is important and helpful, and could easily be defined by the DisMan WG. There were several concerns raised regarding what the cutoff should be between what statistics we should build in now vs follow-on work, considering that distribution analysis is a very rich field. It was generally agreed that Min/max/average calculations should be provided in basic MIBs, and that results in the Expression MIB can capture more complex items. There were concerns about performance issues of retrieving the results in the Expression MIB and shuffling that data to some other summary statistics MIB, and how timeouts should be accounted for. The group consensus was clearly that we have to define a cutoff on the complexity that the group would undertake at this time, particularly considering that user customization can add significant complexity to binning algorithms. Other examples of the use of binning methods (eg TN3270, ARPMIB) were given, and in those cases the complexity is limited. The final group decision was to keep discussion open on the mailing list, for Bob Stewart, Carl Kalbfleisch and Russell Dietz to add basic binning for ping delay distributions to the Remote Operations MIB, that it is important now to make sure that MIBs record their results in a manner that would accommodate binning and analysis, and that the A-D will consider where an appropriate place would be for general purpose binning and distribution analysis. The A-D was asked to consider whether RMON or DisMan was the right place for some related general application work currently being done in the RMON group (although it was also noted that it really didn't matter much considering the overlap in participation between the groups). During the Remote Operations MIB discussion, Bob Stewart and Bob Moore were asked to contribute a strawman for generic data gathering capabilities with wildcarding similar to wildcard capabilities defined for the Expression MIB.

The Remote Operations draft was next discussed. A general policy question on addressing was raised, whether to allow Domain Names vs IP Addresses of target systems. The consensus on the list was to allow Domain Names. Problems were noted between INS, DNS, etc being out of sync and that not all resolvers tell how names are resolved or what precedence was used for resolution. Both of these are deemed useful for operations and end users. The chair requested Jon Saperia to summarize RFC 1612 (DNS Resolver MIB Extensions) and other standards for this. Bert Wijnen, A-D, noted that if we do include name resolver feedback now, we can easily drop it later when going to DRAFT status but that it is harder to add it later if it is not in the document initially. There was no strong feeling to change the document for now. When Jon Saperia posts more information to the list, further resolver information could be added when other changes are made to the document.

There was further concern when discussing the Lookup MIB that adding an extra DNS response time would be a "slippery slope": how far do we go with putting in response timers, and where do we stop? After considerable discussion, it was decided that a response time object should be added to the resolver part of the Lookup MIB unless it extends the WG time.

Another "slippery slope" was the area of other implementations, tests and tools like ping, particularly for non-IP protocols. After agreeing on the usefulness of this, it was decided that the addition of control objects and a list of IANA-provided numbers for various protocols to make it generic would not solve the problem -- the capability to do ping-like operations in other protocols would take considerable effort to understand and document. The final consensus was to not undertake this work at this time.

As indicated above, the topic of indexing to support VACM (owner indexes) was initially brought up during the discussion of the Expression MIB. The implications of the remote operations MIB using owner indices defined as VACM groups was explained better while discussing the Remote Operations document. The problem is that an owner (as defined by pingOwnerIndex) can only have one outstanding ping at a time to a particular destination (pingHostAddress). If an owner is a VACM groupName, then all individuals defined in the VACM group together can share a single outstanding ping to a particular destination. The final group decision on this matter was that it needed further discussion on the list, but that indexing of the form "table.owner.dest.testid" was probably the right approach. The additional "testid" index could be specified as either testAndIncrement or RowStatus objects. The reason for "dest" as an index is to limit access to certain tests for certain destinations.

The meeting concluded with a reminder to sign and turn in the blue attendance sheets and to send minutes to the disman list and minutes@ietf.org.