Subject: IETF48 DISMAN Working Group Minutes

From: Steve Moulton <[email-masked]>
Date: Wed, 09 Aug 2000 09:22:13 -0400

The proposed minutes for the meeting of the DISMAN working group
at the 48th IETF (Pittsburgh) follow.  Please send any corrections
to [email-masked] by Tuesday, August 15..  I will submit the 
minutes with agreed-upon changes by the minutes deadline.

---
Steve Moulton        SNMP Research, Inc            voice: +1 865 573 1434
Sr Software Engineer 3001 Kimberlin Heights Rd.    fax: +1 865 573 9197
[email-masked]     Knoxville, TN 37920-9716 USA  http://www.snmp.com

----------------------------------------------------------------------

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 ([email-masked]).

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 consensus 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).  Consensus 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.

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 9 Aug 2000 22:31:20 +0200

Thanks Steve!!!!!

Bert