NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98
Chair(s):
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@nexen.com
To Subscribe: majordomo@nexen.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:
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 and the Framework document. |
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. |
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. |
Internet-Drafts:
· Definitions of Managed Objects for the Delegation of Management Scripts
· Distributed Management Framework
· Definitions of Managed Objects for Scheduling Management Operations
· Definitions of Managed Objects for Remote Operations Using SMIv2
No Request For Comments
DISMAN
Orlando, 12/7/1998
Chair: Randy Presuhn
Reported by: Shawn A. Routhier
Charter: http://www.ietf.org/html.charets/disman-charter.html
The script and schedule MIBs are currently in WG last call and the chair asks for any comments on them. There were no comments on the schedule MIB and it can be sent to the IESG for last call.
The script MIB includes a line that limits the object identifiers that can be used to specify a language provider to be below 1.3.6.1.4.1 (section 4.1.3) and the description of smLaunchOwner is unclear. After the limitation is removed and the description is clarified (the editors understand the edits) the document will be declared to have gone through working group last call and will be forwarded to the IESG for last call.
Bob Stewart has been working on three documents: notification log mib - <draft-ietf-disman-notif-log-mib-04.txt> event mib - <draft-ietf-disman-event-mib-05.txt> expression mib - <draft-ietf-disman-express-mib-05.txt>
So far there has been a lack of comments on them as well as few people seeming to have read the current versions though several people had read the previous versions. Several people volunteered to read the current versions. Originally there were about 6, when the chair asked about specific documents he got 10 for the notification log document, 10 for the event document and 5 for the expression document.
There ensued a dicussion about what the working group should do with them. The options were drop them, move them to informational or continue on towards the standard track. The discussion revolved around whether it was worth the effort to start something on the standards track if it would never get enough implementations to progress. On the other hand there has been some interest in the documents and many companies won't start thinking seriously about a document until it has become a proposed standard. It is also pointed out that these documents describe infrastructure and what is interesting is what can be built on top of them. To gauge interest the chair asks for a show of hands as to who might implement them. 4-5 people express interest in the notification log and event mibs while only 1-2 are interested in the expression mib. No complaints were expressed about all three continuing into the standards track, with the AD requesting them to move faster.
Bob Stewert lead a technical discussion about several open questions in the three mibs on which he is working. Several of the questions are global in scope and affect how future MIBs might be designed.
The first question is about error handling. Most previous MIBs would maintain information about the last error whether or not they sent a notification about the error. These MIBs don't maintain state about the last error though they do maintain a counter of the number of traps emitted. This can be accomplished by defining the state objects as being notification-only and allows the MIB designer to avoid the need for any history table type objects. Not all traps would be good candidates for this behavior.
The ensuing discussion includes the point that this feature would affect the code more than the MIB. The MIB would have a similar number of objects, but the trap-sender would not be required to supply stable storage for those objects. The discussion also touches on the fact that this idea ties in well with the notification log MIB. The n/l MIB is a common history mechanism and other MIBs can use it or not as necessary. There are no objections to MIBs using this strategy, though there could be some problems if one system doesn't accept the notifies and the sender doesn't implement the logging mib. This is not considered a major issue. Using this feature in the MIBs Bob is working on is something of an experiment to see how well it might work.
Part of the discussion started as a concern about the number of traps a "notify without saving" feature might generate and expanded into a more global discussion about throttling and trap handling capabilities. For the "notify without saving" feature in the above MIBs throttling may be accomplished by including an object to turn the traps off and on and only using the traps when necessary. A more general scheme might allow for throttling the traps being generated by a system at several points - when generated, when stored, when emitted etc. Applications could perform functions such as aggregation, saving or other processing of traps, hopefully such applications (or protocols) would include some form of loop detection. There seems to be general agreement that a general throttle mechanism is useful but beyond the scope of these MIBs, it might be a SNMPv3 type of tool. Andy Bierman volunteers to look into such a mechanism, one place to start might be RFC1224 - "Techniques for Managing Asynchronously Generated Alerts".
One other note from this discussion is that these MIBs are tools, and that while we may not get any immediate use from them we should continue to deploy them piecemeal rather than to wait until we reach some critical mass as that direction may result in never releasing anything.
The second question was about using names instead of integers as indexes. There are three parts to this discussion:
1) use of names instead of integers
2) use of names that probably match the group names
3) use of appropriate names allows a hierarchy of names to be set up.
An example of (3) would be
table.entry.column.<accting>
table.entry.column.<accting_sales>
table.entry.column.<accting_purch>
A different approach for (3) would be to split the information into two indexes, one to name the owner and one to name the objects. This makes the security policy more explicit and is the model used for the script and schedule MIBs
Using a single index requires that the indexs be chosen somewhat carefully in order to avoid accidently creating two names with the same prefix. For example, with owners "A" and "AB" we might have table.entry.column.*.A table.entry.column.*.AB if "A" creates an entry with a leading B such as "ABook" table.entry.column.*.Abook it becomes difficult to differentiate this from something by "AB".
This class of problems could be solved by careful use of punctuation or by the proper addition of entries denying access to certain names but in general the one index case is more complicated to use than the two index case. The working group is also against specifying a standard style for of punctuation.
Another issue is that the single index style makes part of the security implicit in how the indexes are constructed. This is generally frowned on in the security area.
The non-binding consensus is for the two index approach but to move the discussion to the mailing list. If we do adopt/allow the single index approach it will require a fair amount of descriptive text to clarify its use to the manager.
The discussion also included a more general question if this demonstrates a problem with security such that we will need an owner string for the first index of all mibs - or how do we tell which objects or MIBs would require them. One comment is that this will only occur for certain classes of entities such as logical entities that may come and go while other items might have security based on specific attributes.
and that other items such as if entries will have security based on its more "physical" attributes. There was some disagreement about
Question three was to replace the DisplayString with the SnmpAdminString, the consensus was to do so.
Question four was if the objects in a MIB should include the MIB module name, in this case "disman", as part of their names. A majority of the people who cared prefered having the mib module name included. This was passed to the mailing list for further discussion.
Question five was what rule should be followed to decide if an object of storage type be included in a table, or should all tables have storage type objects. This was passed off to the SNMP futures meeting, with Bob Stewart getting the action item to bring it up there. The specific case of these tables was passed off to the mailing list.
Question six was about changing the model for the event MIB, to have a simple version rather than the full expression MIB. Currently it only includes booleans and threshholds, a different option would be to specify the test, operator object and operand object. This question was passed off to the mailing list.
There were no comments on the remote operations document - <draft-ietf-disman-remops-mib-01.txt>. Work will continue and the working group will try to get it done shortly.
As the working group agrees that there really isn't a framework to the current set of documents the chair is planning to ask the ADs to let the framework document be dropped.
There was no discussion of interaction with other groups and no proposed charter updates.
The working group decided to wait and see what other groups do with the bulk transfer ideas and how the rest of the current DISMAN work goes. If this isn't accepted as a protocol issue by the SNMP futures group then it probably should be absorbed by DISMAN.
None received.