Subject: Re: ARC + COND

From: Randy Presuhn <[email-masked]>
Date: Thu, 22 Mar 2001 11:23:39 -0800 (PST)

Hi -

> Message-ID: <[email-masked]>
> Date: Thu, 22 Mar 2001 10:15:17 -0800
> From: Lauren Heintz <[email-masked]>
> To: Randy Presuhn <[email-masked]>
> CC: [email-masked]
> Subject: Re: ARC + COND
> References: <[email-masked]>
...
> 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.

We need to be very careful here.  The term "notification"
is used in three distinct senses in these discussions.
The first is in the sense of the NOTIFICATION-TYPE macro,
which defines the semantics and mandatory information payload.

The second is the sense used in the CMIP world, where a
notification is what is emitted by a managed object, not
the thing that appears in a log or on the wire.  Its closest
analog in the SNMP world is the agentx-Notify-PDU.

The third sense is where "notification" means the SNMP
PDU corresponding to an instance of the second sense.

Sooooo...

If a notification in the first or second sense is supressed,
it won't show up in the active alarm table.

Whether anything shows up on the wire (the third sense) is
controlled by the RFC 2573 filters.

The flow is something like:

     condition detection
        |
        V
        +----> condition tables
        |
        V
       ARC
        |
        *
        |
 +------+-------+
 |              |
 V              |
active          V
alarms - - - - >+
                |
                V
             filters ----> notification log mib
                |
                V
              targets ---> the wire

The implementor in me thinks that "*" would be a natural
place for the agent/subagent boundary IF one chose to use
that as an implementation strategy.  (Nothing that we do
should REQUIRE that implementation strategy.)

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

No, the condition MIB reports CONDITIONS, not alarms.

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

We should always be watchful for opportunities to eliminate
unnecessary duplication and complexity.  The documents in their
current form have lots of both, and part of the motivation
for this proposal is the belief that a proper functional
partitioning will result in a net simplification.

In particular, we hope we will be able to identify lots
of opportunities to employ common textual conventions.

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

I think conditions would normally be queried by <resource, time>,
while alarms probably would have <time> (or possibly severity)
as their primary key, but these points require more discussion,
in a separate thread.

> Please take this as a fuzzy idea as opposed to a specific
> design change proposal.

Fuzzy can be useful. The editors should take care in the
updates to the drafts to ensure that the concerns you raise
are properly addressed in the text.  Ok, editors?

>                          After all, fuzziness was good enough
> to get our good president elected! :-)

So the key difference between Fred Baker and Harald Alvestrand
is the beard?  :-)

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

We should always go into these things with our eyes open.
I personally think we're on the right track here, but as WG
chair I need to make sure that other perspectives are heard
and considered.

 -------------------------------------------------------
 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 12:23:35 -0800

Me again,

I'd like to modify your nice drawing.

> The flow is something like:
   |              |
   |              #
   |              |
   |              V
   |           filters ----> notification log mib
   V              |
   |              V
   |            targets ---> the wire
   +-------+
   |       |
  HTTP    CORBA
   |       |
   |       |
  WIRE    WIRE
 
> should REQUIRE that implementation strategy.)

You described earlier that the activeAlarm table
WOULD be cleared if you disabled alarm notifications,
so I thought that implied the "*" was actually part
of the ARC subsystem, which means the impl had no option
about where to put the "*".

The "*" valve shuts down all active alarms for
all consumers of the activeAlarm table (which
might be shared between SNMP, HTTP, Corba, or
any other data client.  If that's what's intended,
then a more clearer way of describing the "*" is to say
that it disables the activeAlarm table and any related
autonomous events that clients may have need of (as
opposed to saying it disables only SNMP notifications).

If you add a valve at the "#" then you're
only disabling SNMP notification delivery
but allowing other activeAlarmTable clients
to continue operating.  HTTP, Corba, etc,
could independantly choose to also sense on
the # scalarif needed.

I would prefer the # valve instead of the *,
but would not argue against both (or others).
 
> No, the condition MIB reports CONDITIONS, not alarms.

My original point was that the technician needs a way
of seeing which active alarms are on the device
even if the ARC and COND MIBs are not supported AND
alarm notifications are disabled. If by turning off
alarm notifications you also have a side effect of
clearing the activeAlarm table, well, seems to
me you've violated the precept that alarms are different
than notifications.  I think it's valuable to be able to
disable alarm notifications but have the activeAlarm table
still be populated.  If the WG disagrees, that's fine.
I think the points have been raised and understood.
They either spark a consensus for need/consideration or don't.

Thanks,
Lauren