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 - event mib - expression mib - 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. table.entry.column. table.entry.column. 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 - . 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.