Subject: RE: ARC + COND

From: "Thomas, Steven C (Steve)" <[email-masked]>
Date: Thu, 22 Mar 2001 15:37:04 -0500

Hey,  Responses, clarifications below...

> -----Original Message-----
> From: Randy Presuhn [mailto:[email-masked]]
> Sent: Thursday, March 22, 2001 2:38 PM
> 
> Hi -
> 
>> Message-ID: <76B2C11F0337D3118A670008C7F9DBC703BB4FC0@OH0012EXCH002U>
>> From: "Thomas, Steven C (Steve)" <[email-masked]>
>
> ...
>> Lauren wrote:
>> 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.
>> 
>> My comments:
>> I agree.  I see a need for a very simple mechanism for turning off  or
>> screening alarm reports.  The needs that I have seen have largely been
>> driven by the manager side, and so doesn't know/care about the sub-agent
>> setup.  
>
> There is NO proposal to make subagent structure visible here.
> The whole point of the subagent technologies is that management
> systems do not need to be aware of them.

OK
> The requirement that I have heard is that the control is
> closely associated with the managed resource in some way.
> Current MIBs do this with a dedicated object in the specific
> MIB.

I wouldn't dispute that requirement, but I would add the idea that
sometimes the control is wanted at the system level.  We could get
the same effect if I regard the entire system or application that I
am managing as the managed resource.  I will have to consider that 
idea more.

>      For ARC, the proposal is to use a table with generic
> objects.  If the indexing is done correctly, such objects could
> be implemented in both monolithic and subagent environments.
>
>>         Their solution has been to have a single value (representing
>> severity level) that indicates which alarms to report on and which to not
>> report on.  
>
> What is meant here by "report on"?
>  1 Make entries in an active alarm table?
>  2 Generate Log records?
>  3 Issue INFORM / TRAP Pdus?
>
>>             The implementations have kept the alarms in the active alarm
>> list and alarm logs, but haven't reported them.  
> 
> ok, I'll assume you mean (3) from above...

Yep,  I was trying to dance around and avoid the semantics/definition
problems that keep occurring between alarms, alarm reports, notifications,
logs, etc.  Obviously I failed... Live and learn :-)

> This depends on how the RFC 2573 filters are configured.
> If a filter can be set up to log a particular kind of
> notification, it should be possible to configuration of a
> target to which a corresponding TRAP or INFORM might be sent.

True, if we structure our alarms and the notifications for those alarms
correctly, we would be able to use the 2573 Notify Filters.  However,
this has been perceived as "too complicated" by the development teams.

>>                                                  When the manager
requests
>> the agent to scale back alarm reporting, then they have started/increased
>> polling on the alarm table.
>> 
>> I would like to have a very simple mechanism that I can recommend and
push
>> with our agent and management development efforts.
> ...
>
> And the proposal is?
We have some teams that have implemented a single value somewhat like the 
condNotificationSelection bits element in the condition MIB.  More often the
teams have gone even cruder with an integer signifying send this level
severity and higher, don't send anything lower.

I am not putting a proposal on the table now, just trying to describe my 
need for a very simple base mechanism.  As the ground underneath the alarm
definitions and active alarm table stops shaking I might add a proposal to
that.

Cheers,
Steve