The DISMAN (Distributed Management) working group met on Monday, July 31, during the 48th IETF. This working group meeting was chaired by Randy Presuhn. There were approximately 80 people present. The agenda slides are available at ftp://amethyst.bmc.com/pub/disman/ietf48/ietf48-disman-agenda.ppt This working group meeting was reported by Steve Moulton. The first major item on the agenda was the usual administrivia. Juergen Schoenwaelder was recognized by the chair. Steve Moulton agreed to take minutes. Attendees were asked to sign the blue sheets. The agenda was reviewed, and no changes were requested. During the allocation of time, Sharon Chisholm requested 1/2 hour, Juergen Schoenwaelder requested 1/2 hour and Bob Cole requested some time to make a report from the RMONMIB working group. The second major item on the agenda was the Status of Current Work. There are updates pending to the script and schedule MIBs, which were discussed later in this meeting. The notification/log MIB, event MIB, and expression MIB have completed IETF last call. The remote operations MIB is in the RFC editor's queue. The third major item on the agenda was other work in progress related to DISMAN. There was a brief report on the RPERFMON BOF at the 47th IETF in Adelaide, where the idea of using synthetic sources for performance measurement was discussed. This work is now being examined in the RMONMIB working group. Bob Cole made a presentation (summarized below) on the SSPM framework. The SNMPCONF presentation was omitted; those interested were referred to the SNMPCONF Working Group meeting to take place later in the week. Bob Cole made a presentation on SSPM (slides are available as ftp://amethyst.bmc.com/pub/disman/ietf48/sspm_pitts.ppt). The basic concept revolves around using synthetic data sources for performance measurement. Mention was made of the SSPM framework document (draft-cole-sspm-00.txt) and Carl Kalbfleisch's MIB document discussing how you might set up the probes (draft-kalbfleisch-sspmmib-00.txt). Mention was made (with out explanation of the acronyms) of several activities taking place in the RMONMIB working group, specifically, SSPM, APM/TPM, the use of the schedule MIB, and PMCAPS. Bob presented presented several slides, including a fairly complex slide showing performance measurement architecture. In Adelaide, there were several issues presented using this architecture slide, including measurement and control protocols. The IPPM (IP Performance Metrics) folks will talk about producing a new protocols for measurement and control. No attempt is made to reproduce the slides here. One comment was made, whereby the full protocol stack requirement for SSPM has been declared a non-issue. Dan Romascanu discussed the Indexing and Distributing aggregation issues. The fourth major agenda area was discussions on technical issues. The first item, closing remaining RFC2591 (schedule MIB) and RFC2592 (script MIB) issues, was presented by Juergen Schoenwaelder. The associated documents are draft-ietf-disman-schedule-mib-v2-01.txt and draft-ietf-disman-script-mib-v2-01.txt. The slides are in ftp://amethyst.bmc.com/pub/disman/ietf48/disman-issues.ps. No attempt to replicate the slides is made here. Juergen Schoenwaelder made the presentation. Issue 04 (schedule MIB): the proposal to automatically disable failing schedules. [Names are given when the minute taker recognized the person asking questions. The dialogue has been edited some to reduce length.] Russell Dietz: When does the script get turned back on? Juergen: I don't know, probably never. Russell: Will it be the default behavior to turn off the script after a certain number of failures? Juergen:: No. The default will be to do nothing. David Harrington: My feeling is that it should be a separate piece, as not everyone will want it. This may be a policy issue and therefore belongs in SNMPCONF. Randy Presuhn: You have to appeal to a higher intelligence to both turn stuff off and to turn stuff back on. Any vendors have any comments? Russell: There are a couple of products out there that have some combination of reporting the failure and stopping the script. You should probably report the failure and let a higher authority shut off the script. Randy: is this a major or minor issue? David H: this is a minor issue. Parts can be handled elsewhere. Randy: Lets break this down. Should this capability be in the schedule MIB or in another special MIB? (floor): we could do all of this in the script or event MIBs. The general purpose mechanisms are in place. Do we need to build special purpose mechanisms into the script MIB to do this? David H: There are several issues that will come up on this that have not come up yet. How do you handle various success/failure patterns? There may be a lot more work in this than is apparent. Russ Mundy: are people deploying this with nothing around it that can deal with failure? (no response) randy: Does anyone strongly believe we need to add this to this MIB? (no response) Bert: Should we recycle this document at proposed? Randy: If we do not make this change, we can proceed to draft status. We will ask on the mailing list if there is any support for this. If not, then we will not do it. Issue 05 (script MIB) is to replace the indices on the smLangTable and smExtsnTable with textual indices (by name). This would require the deprecation of these tables. Are the benefits worth the cost of the change? The chair asked if anyone be upset if we did not change? (no response). This validates the consensus from the working group mailing list. Issue 06 (script MIB): Dependencies between scripts and scripts versioning. The MIB does not model inter-script dependencies (script b requires that script a is present and enabled) nor does it provide explicit support for multiple versions of a script. The comment was made that this problem probably belongs in the management station, not in the agent. David Harrington raised the point that some sort of version control can be done in the script naming, i.e. "script_1.1_for_IOS_v2.3" The agreement was to not change the tables. Issue 07 (script MIB): Storage type of script code vs. script meta information. Is there a difference between the script storage type and the storage type of the script meta information? Juergen: This is probably a documentation issue in the MIB. Randy: There may be an association between the script table storage type and the persistence of the script itself. Clear as mud? (yes). Juergen: we don't think this is a problem in the MIB definition, but in the documentation. OK with group? (no response). General agreement is that it is OK. Issue 10 (script MIB): Script editing in the smCodeTable. The script MIB provides basic script editing capabilities via SNMP set operations. Implementation of the feature adds costs while the utility of this feature is questionable. [this is an enumerated value of the smScriptAdminStatus object -ed]. Should we try to simplify by taking this feature out? There are known cases where this prevented implementation of the smCodeTable. Randy: We should make the "editing" enumerated value of this object not necessary to claim conformance in the compliance statement. In other words, we would make the editing function optional. This wording will get set out to the mailing list for comment and approval. Issue 11 (script MIB): Resource consumption indication in smRunTable. It would be nice to have some sort of indication of this (cpu consumption or memory consumption). Is it possible to define metrics that are semantically meaningful and generally implementable. Among other problems, this will require OS support and will be very implementation dependent. In particular, implementations that have all scripts executed by one script engine makes this information not available. All possible solutions can be pursued without requiring modifications to the current document. (floor): are you suggesting we have a script resource MIB later and let this document continue? (there was no disagreement to this proposal). Steve Moulton: When discussing this new MIB, we need to bear in mind that the unit of granularity may be the entire MIB engine. Randy Presuhn: Yes. Issue 16 (script MIB): Suspend/resume on runtime engines that do not support it. The current specification says that the running script remains in the suspending (resuming) state when the runtime is not capable to suspend (resume) a script. This makes it impossible to determine on the manager side whether the suspend (resume) just takes a long time to complete or is not supported. A solution would be to go from transient suspending state back into the running state when the runtime can not suspend a script. Randy Presuhn: The issue is to disambiguate between something that takes a long time to suspend and the case where the script engine just cannot suspend the script. The suspend object needs to have a way to return the "can't suspend" case. Disambiguating into three cases 1) Engine just can't suspend script. Return error value to set. We can do this, no big deal. 2) Script just won't be suspended. Is this a real problem? No. This is a engine debugging issue. 3) Someone else reawakens script. (use access control, multiple manager-type solutions). This item was brought to the working group's attention as the input from the mailing list was inconclusive. The sense of the room is that no action need be taken, but the question needs to be put to the mailing list for any final comment. The next technical discussion item was a discussion of distributed active alarms by Sharon Chisholm. The slides are available as ftp://amethyst.bmc.com/pub/disman/ietf48/IETF48_DISMAN_presentation.ppt. No attempt to summarize the slides has been made here. A draft of this work has been posted to the DISMAN mailing list. One issue driving this work is that due to a trap storm or other events, alarms may be pushed off of the end of the notification/log MIB. The following questions were asked: (floor): Are alarms associated with physical entities? Sharon: Not necessarily. Alarms can come from logical devices, too. An alarm is anything you want to fix. Randy: How do you decide what is interesting? Sharon: There is currently no way to determine/filter. (floor): How do you determine what alarms the device supports, and how do you determine what alarms you register for? Sharon: This depends on the site. There are several questions about deciding what notifications are active alarms. (floor): Why is this in DISMAN? Sharon: There is a industry requirement for this type of functionality, and we need a standard framework to deal with it. The fifth agenda items have to do with working group business. A charter update removing Bob Stewart [who has retired -ed] has been requested, as well as updating target dates for script and schedule MIBs. A working group last call for these MIBs starting September 14, 2000 was proposed without objection. The issue of script MIB extensibility (RFC2593, experimental) was brought to the working group's attention to see if it required any action, such as moving onto the standards track. There were no comments, indicating that no action need be taken. The question was raised about whether we take on alarms (cf. Sharon Chisholm's work). At least on person requests that we do. The issue of intellectual property in this work was raised. Sharon asserted that Nortel is working on releasing IP claims on the alarm MIB. David Harrington asked whether this is a DISMAN or a SNMPv3 issue? Russ Mundy responded that he was not sure, but that it looked like a general SNMP issue. David Perkins observed that there is a CMIP framework model that handles this problem, and, since this problem comes up so often, we ought to look into it. Randy Presuhn stated that this will be taken to the mailing list, and advised Bert Wijnen to be prepared for a charter update for an additional work item. Bert stated that we need to decide whether this should go into DISMAN or SNMPv3. Dan Romascanu expressed interest in taking on this work. Upon request for a list of additional work items Dan Romascanu requested we look into synchronization with remote performance management, and a resource consumption MIB. The final agenda item was Working Group meeting wrap up. A review of action items included: . mailing list: add item regarding self killing schedules. . Sharon Chisholm's work will be discussed as a possible charter update. . mailing list: submit compliance text for smCodeTable, schedule working group last call for September. Randy reminded note takers to follow the guidelines and presenters to submit their slides, and all participants to sign the blue sheets and return them.