Subject: Re: ARC + COND

From: Randy Presuhn <[email-masked]>
Date: Thu, 22 Mar 2001 09:47:02 -0800 (PST)

Hi -

> Message-ID: <[email-masked]>
> Date: Thu, 22 Mar 2001 09:28:28 -0800
> From: Lauren Heintz <[email-masked]>
> To: Randy Presuhn <[email-masked]>
> CC: [email-masked]
> Subject: Re: ARC + COND
> References: <[email-masked]>
...
> I also believe that typical implementations
> will choose to implement conditions and alarms
> that are a one-to-one mapping with each other,
> thereby making the need for both MIBs questionable.

The whole point of the ARC capability is to allow
an administration to say that a particular condition
should not trigger an alarm.  The folks who are
provisioning / repairing a resource need to know
the conditions, even if the high-level administrators
don't (and don't want to) see those conditions as
alarms.

> I would suggest prying out the unique aspects
> of the COND MIB and either a) add that to the alarm
> MIB if it needs to be, 

This would make the information paths far to complicated.
Notification supression is best implemented as close to
the resource / resource manager as possible.  The COND MIB
needs to reflect the information stream BEFORE notification
supression / deferral is applied.  From an implementor
perspective, the data flow if the two were combined would
be far too convoluted, and probably not even possible if one
were to attempt implementation using AgentX.

>                        b) eliminate it as a need, 

The ARC need is well documented in the form of individual
MIB objects that have been necessary over the years to
handle supression of a specific notification.

The COND MIB has support, though the WG chair would like to
see more documentation of that support on this mailing list.

>                                                   c)
> consider for later adoption (and making sure the alarm
> work does not design it out in the short term).

If we have the people willing to do the work now, the WG
chair does not see reason to defer it.

> Regarding the capability for temporarily disabling
> alarm notifications (perhaps during periods of installation
> and/or fault correction), I think typical users will want to
> at least have a VERY SIMPLE way of turning off alarms (i.e.
> a single TruthValue) that MUST be in the alarm MIB if
> they opt not to support the ARC and COND MIBs.  Furthermore,
> I haven't thought this one through -- nor the preceding
> comments :-) -- but I'm concerned with the idea that whether
> that TruthValue happens at the alarm MIB input or output
> may be important to consider.  Wasn't clear to me whether
> alarm notifiction disabling also meant the alarm tables
> would be empty as a result.  

They would.  That's actually one of the key differences
between "condition" and "active alarm".

>                              I'm wondering if disabling
> alarm notifications should NOT also clear the tables (perhaps
> the technician wants to walk the tables to see if the alarm
> she has tried to correct has been successfully cleared).
...

I think you just made the case for having both.  :-)
The technician will generally be the user of the condition
tables; the administrator will be much more interested
in the active alarms.

 -------------------------------------------------------
 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.
 -------------------------------------------------------

---

From: Lauren Heintz <[email-masked]>
Date: Thu, 22 Mar 2001 10:15:17 -0800

> I think you just made the case for having both.  :-)

Always happy to be of help -- even if by accident!

:-)

Seems that active alarms should always be reflected
in the activeAlarm table, even if notifications are
turned off.  Otherwise, it's not an activeAlarm table.

Also, if an impl chooses not to implement the cond MIB,
then I think you're saying the technician has no way of knowing
whether an alarm has been cleared except to reenable the
notifications and see what spews forth.  Seems kludgy!

I still feel there's a complexity issue,
which is my main concern.  The slides
on Monday left me with a feeling there
had to be ways of simplifying things
and eliminating redundancy.

Seems that alarms will be a subset of all possible
conditions, therefore, why not just add a
column in the cond table that indicates whether it
is also an alarm and get rid of the activeAlarm table.
Please take this as a fuzzy idea as opposed to a specific
design change proposal.  After all, fuzziness was good enough
to get our good president elected! :-)

That said, my attention is mainly turned elsewhere,
so maybe I'm alone in my opinions here.

Thanks,
Lauren

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 Mar 2001 00:22:05 +0100

>>>>> Lauren Heintz writes:

Lauren> I still feel there's a complexity issue, which is my main
Lauren> concern.  The slides on Monday left me with a feeling there
Lauren> had to be ways of simplifying things and eliminating
Lauren> redundancy.

I am also concerned about complexity. Are there any implemented and
deployed alarm MIBs that have the same degree of complexity in the
SNMP world? If not, then this is probably heading in the wrong
direction.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

---

From: Tammy Ferris <[email-masked]>
Date: Fri, 23 Mar 2001 10:24:00 -0600

Juergen and Lauren,
I have heard this complaint about complexity but have a hard time really
understanding the concern here.

What guidelines has the IETF laid out to determine the measure of complexity
of any SNMP MIB or table?  Or if none, what are your guidelines?

To me, ARC does not seem so complex.  ARC was not the result of a new idea
so much as a way to find a standard way to do what systems were basically
already doing but doing in slightly or not so slightly different ways.

In our discussions on the alarm and conditions MIBs we sort-of ended up with
the understanding that we would define them separately and functionally and
then collapse later where we see redundancy or more efficient ways to do
things.  In other words, the first goal being to come up with an initial
model that meets the needs/requirements for the functionality first.

I believe there are systems in the SNMP world that have this degree of
complexity in the real world as several telecom vendors are using SNMP.  And
I believe the application of this is not limited to telecom so is likely
even be more widely implemented.

Can you please be specific and clarify what it is that you think is complex?

Tammy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 Mar 2001 17:54:55 +0100

>>>>> Tammy Ferris writes:

Tammy> Juergen and Lauren, I have heard this complaint about
Tammy> complexity but have a hard time really understanding the
Tammy> concern here.

Tammy> What guidelines has the IETF laid out to determine the measure
Tammy> of complexity of any SNMP MIB or table?  Or if none, what are
Tammy> your guidelines?

My comment was just meant as a reminder to find a good balance between
generality and simplicity. You greatly increase the likelihood that
things are getting implemented and you achieve actual interoperation
between management apps and agents from different vendors if things
focus on the essential things.

Tammy> Can you please be specific and clarify what it is that you
Tammy> think is complex?

I did not follow the alarm discussions during this week closely so I
have lost track what is in the MIBs right now. I need to see the next
revision of the IDs before I can give specific comments. I just wanted
to remind us that it is sometimes better to reduce generality for the
sake of getting things implemented and actually widely deployed.

Lets close this thread for now - perhaps the next set of IDs is
already making me feel comfortable.

/js

---

From: Lauren Heintz <[email-masked]>
Date: Fri, 23 Mar 2001 09:16:59 -0800

Tammy,

> Can you please be specific and clarify what it is that you think is complex?

Well, I was trying to be general! :-)  To be specific
I'd have to study the MIBs more closely.

Whether or not an ARC and/or COND MIB is bolted into place seems
OK to me, as long as everyone (the non-IETF folks) understands they
are not REQUIRED for the alarm MIB to function properly.  I know
this is a goal, so that doesn't appear to be a big problem -- as
long as when they are bolted together there is no overlap of function.

Speaking from a high-level POV, it seems a basic alarm MIB needs an
active alarm table and a history table and a few lightweight notify
defs.
Column indicators could indicate whether a given fault/cond/whatever is
alarmed/reportable/etc or not.  Of course, there are other requirements
that dictate just how these defs are constructed.

Anything beyond that starts getting complex in my view.

I'm not convinced this effort is destined to be overly complex,
I am just whispering in your ears to please make sure it doesn't
end up there.

Thanks,
Lauren