Subject: Fwd: IETF DISMAN notes, March 19, 01

From: Randy Presuhn <[email-masked]>
Date: Wed, 21 Mar 2001 07:55:05 -0800 (PST)

Hi -

I'm forwarding Sanjai Narain's notes from the first disman session on
Monday.  (I've added [email-masked] to the mailing
list's "posters" list so future postings won't be bounced.)

> Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117])
> 	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA09795
> 	for <[email-masked]>; Tue, 20 Mar 2001 15:02:35 -0800 (PST)
> Received: from fw-us-hou-9.bmc.com (localhost [127.0.0.1])
> 	by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f2KN0jD15842
> 	for <[email-masked]>; Tue, 20 Mar 2001 17:00:45 -0600 (CST)
> Received: from thumper.research.telcordia.com ([128.96.41.1]) by fw-us-hou-9.bmc.com; Tue, 20 Mar 2001 17:03:35 +0000 (CST)
> Received: from flash.research.telcordia.com (flash-18 [192.4.18.17])
> 	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f2KN3RO21383;
> 	Tue, 20 Mar 2001 18:03:27 -0500 (EST)
> Received: from research.telcordia.com (localhost [127.0.0.1])
> 	by flash.research.telcordia.com (8.8.8/8.8.8) with ESMTP id SAA14904;
> 	Tue, 20 Mar 2001 18:03:27 -0500 (EST)
> Message-Id: <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Subject: IETF DISMAN notes, March 19, 01
> Date: Tue, 20 Mar 2001 18:03:26 -0500
> From: Sanjai Narain <[email-masked]>
> 
> 
> DISMAN Meeting Minutes, March 19, 2000, IETF Minneapolis
> 
> Compiled by Sanjai Narain, [email-masked] 
> 
> There were three broad themes: MIBs for new alarms, Condition MIB
> (every condition is not an alarm), and Alarm Report Control MIB (how
> to suppress alarms from being reported). The purpose of today's
> meeting was how to reconcile these themes.
> 
> The following presentations were made:
> 
> By Sharon Chisholm: "Alarm MIB requirements", "Alarm MIB" and ITU
> Alarm MIB" and "Alarm MIB Slice and Dice".
> 
> By An-Ni Huynh: "Condition MIB". 
> 
> By Kam Lam: "Alarm Reporting Control (ARC) MIB". 
> 
> By Dan Romascanu: ??Exact title??
> 
> Randy: Do we care that other groups like Syslog, idwg are suspiciously
> alarm like. Do we care.
> 
> Dan Romascanu: yes we do. Distributed systems alarm.
> 
> First speaker. Sharon Chisholm. Alarm MIB requirements.  New proposals
> for alarm management on the mailing list. What is the problem we are
> trying to solve?
> 
> Compliance matrix is shown. Columns are Requirement Number,
> Description, Compliance.
> 
> Alam definition: 1.6, 1.7. Unambiguously tells you who detected the
> problem. 1.7: Means of obtaining ITU alarm information.
> 
> Randy: Don't want to make the subagents visible. 
> 
> Audience: Randy doesn't care which subagent generated the alarm. 
> 
> Randy: Not quite. I don't want to talk about subagents, ok to talk
> about subsystems. 
> 
> Dave Perkins: You can buy cheaply videocameras for your house for
> security. Alarm condition = movement in pool area. There is more value
> if for each camera there is an agent which
> 
> Randy: Does anyone have a problem with this requirement? No response.
> Strong maybe.
> 
> Sharon: Historical, requirement number .4 Condition management. 
> 
> Randy: Last night, things of historical interest have never been
> notifications. Hence they never appear in any notification log MIB.
> 
> Sharon: Turn this into a 'yes'. Going one, going twice. Next issue is
> alarm suppression (Requirement 5.1). Is anyone opposed? No response.
> Several show of hands.  5.2 Severity. How much alarm suppression. Who
> has a need for alarm suppression by severity? use make use of alarm
> notification in my mib? Could an alarm be automatically generated?
> 
> Sharon: Don't see why not. Another real-life example. 
> 
> Randy: So if I haven't built something into this implementation that
> recognizes clear condition, alarm will not clear. We need to be
> realistic. Is this a show stopper? We need to be confident that this
> approach is useful in enough number of cases. Have I stated your case
> fairly, Dave? You don't look too unhappy.
> 
> Randy: Judging by time, unless the assembled masses are desparate for
> more example, this is a good breaking point, let us discuss the
> Condition MIB.
> 
> An-Ni: An-Ni Huynh/Mark Stewart, Lucent. Condition MIB. Mainly for us
> to understand there is an abnormal state in which an entity exists. We
> want to know the current status of device. Is condition current,
> transition or retired? One type of notification for OK condition.
> Suppress alarm notification/reporting filtering based on level of
> security.  Alarm notification is relevant to condition. What kind of
> alarm type is it? We also need to know what type of device it is.
> Also, is it a circuit pack, or physical port? This looks like an ITU-T
> specification.
> 
> Randy: Replace alarm with "condition" on this screen. 
> 
> An-Ni: Cnditoin detection ? one of three lists: Current condition
> list, transient condtion list, retired condition list.
> 
> Randy: I believe that Sharon has a slide which will detail what An-Ni
> just described (slice/dice).
> 
> A more detailed example is a case where you suppress a particular
> notification if something is being provisioned.
> 
> Audience: What is an alarm profile?
> 
> An-Ni: For some cases alarm is critical, some minor.
> 
> Randy: For example, admin has declared that I care about LOS on T1 but
> not dialup. 
> 
> Randy: We've got suppression, degradation, filtering. I think that if
> it sounds like we want to look at this side of the problem, this would
> be a good question for the mailing list. First we want to look at
> slice/dice.
> 
> Randy: Next presentation from Kem Lam. 
> 
> Kam: ARC MIB. Needs for suppression of alarm reporting. Needs for
> automatic in service provisioning.
> 
> Randy: Is it fair to say that currently in several MIBs we have
> mechanisms for turning off notification of a particular type. This
> provides a generic mechanism for new MIBs.
> 
> Andy Berman: Delaying is a lot different that suppression. 
> 
> Randy: If it is cleared, you don't want it to go into the log. 
> 
> Kem: Once an entry transitions from ARC mode to ALM state, the entry
> will disappear from table.
> 
> Audience: How is this related with X.734? 
> 
> Randy: Closest to EFD is described in RFC 2574 where notification MIB
> provides a capability crudely equivalent to EFD.
> 
> Audience: EFD is shut at destination, whereas you are trying to shut
> it off at the source.  This is an important point.
> 
> Sharon: Alarm MIB requirements. Conditions MIB is solving a different
> problem than active alarm tables. Persistent vs. non-persistent
> indication of alarms.
> 
> Randy: Only SOME conditions are treated as alarms. 
> 
> Sharon: Initial slice: Separate MIBs for alarm definition and active
> alarm management.  Conditions and ARC.
> 
> Randy: I'd like to get a sense who believes we should continue working
> on the capability Active Alarm Table? Many raised hands. One
> objection: this is getting too complex, my requirements satisfied by
> notifications log mib.
> 
> Dave Perkins: Not all notifications are alarms. Does the objector
> understand this? 
> 
> Randy: The second chunk of work: defines condition detection. Is there
> any support? A few show of hands. Vehement opposition from same
> objector. To him this is too much burdensome.
> 
> Audience: Be careful in gauging broad consensus. Most people are in
> the middle between vehement opposition and support, but have no great
> suggestion. No response =/= assent.
> 
> Randy: ARC. Selectively throttle. What is consensus? A few show of
> hands. Strong opposition. None. Extrapoloating that, I believe this
> means we have at least one additional document that would have witin
> it the ARC, and the condtion mib. Is that acceptable as a strawman.
> Already, there are editors. Others welcome to contribute. Area
> director Bert said it is fine with him. Anything else on slice and
> dice?
> 
> Audience: Condition, alarm, ARC are closely related, so definition of
> docments should be coordinated. Moderators agreed.
> 
> Audience: If you are finishing with this framework, specify in the
> documents what relationship with other documents.
> 
> Randy. We will meet again on Tuesday. 
> 

 -------------------------------------------------------
 Randy Presuhn           [email-masked]
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
 Fax:   +1 408 965-0359  2141 North First Street
 http://www.bmc.com/     San José, California 95131  USA
 -------------------------------------------------------
 My opinions and BMC's are independent variables.
 -------------------------------------------------------