Subject: Re: ARC + COND

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

Hi -

> Message-ID: <[email-masked]>
> Date: Thu, 22 Mar 2001 12:23:35 -0800
> From: Lauren Heintz <[email-masked]>
> To: Randy Presuhn <[email-masked]>
> CC: [email-masked]
> Subject: Re: ARC + COND
> References: <[email-masked]>
> 
> Me again,
> 
> I'd like to modify your nice drawing.
> 
> Randy Presuhn wrote:
> > The flow is something like:
> > 
> >      condition detection
> >         |
> >         V
> >         +----> condition tables
> >         |
> >         V
> >        ARC
> >         |
> >         *
> >         |
> >  +------+-------+
> >  |              |
> >  V              |
> > active          V
> > alarms - - - - >+
>    |              |
>    |              #
>    |              |
>    |              V
>    |           filters ----> notification log mib
>    V              |
>    |              V
>    |            targets ---> the wire
>    +-------+
>    |       |
>   HTTP    CORBA
>    |       |
>    |       |
>   WIRE    WIRE

Interesting.  No argument from me.  Yet.  :-)

> > 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.)
> 
> You described earlier that the activeAlarm table
> WOULD be cleared if you disabled alarm notifications,

I apologize if my reply read that way.  I understood
that the table would be "clear" in the sense of *empty*
because nothing would have been put into it, NOT
that supressing notifications at the resource manager
would magically cause alarms that had already be raised
to be magically cleared.

> 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
 
"*" wasn't meant to be a valve.  It was just meant
to show where the information flow could be realized
in AgentX protocol if one were to use that implementation
strategy.  This was only intended to show that the model
could peacefully coexist with subagent technology.

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

No.  Consider that there may be many different resources
in a system which support alarm report control.  The
ARC tables would give the ability to supress alarm notifications
(in the agentx sense) at the level of the resource granularity.

Supressing notifications for one interface should have no effect on
the notifications reporting conditions on another interface.  I think
that it should have no effect on the set of active alarms recorded
for that resource.

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

"*" is not a valve.  I think "#" (unless you mean the
alarm description capability from the active alarm i-d)
view as a scalar would be too coarse in granularity to
be useful for systems where this kind of infrastructure
would make sense.

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

One more time, take a look at the data flow, consider
that "notifications" at the "*" point are in the
agentx sense, that the data flow allows the RFC 2573
filters to steer information to the log, the notification
originator application, neither or both.  

Notifications in the agentx sense are inputs into
the process that delineates the lifecycle of active
alarms.  Notifications in the SNMP wire protocol
sense are a result of the notification originator
application doing its thing, based on its target
and filter configuration.  

If there is no ARC-like capability, then the notifications
in the agentx sense cannot be turned off.  The alarm
description table and the notification originator filters
would determine what shows up in the active alarm table
and on the wire as SNMP INFORM/TRAPs, respectively.

>                      I think it's valuable to be able to
> disable alarm notifications but have the activeAlarm table
> still be populated.  

If you mean disable the SNMP INFORMS/TRAPs on the wire, while
having alarms in the active alarm table, I agree 100%, and
believe that the architecture here will support it.

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

I'm hoping that we actually have the same requirements and
that it's just a matter of understanding the words we're
using.

 -------------------------------------------------------
 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 13:58:09 -0800

> believe that the architecture here will support it.

Cool!  That's what I was trying to express
in my first email (I think).  Sorry if I
used wrong words or misinterpreted your responses.

Thanks Randy.

Lauren