Subject: RE: ARC + COND

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

Hi -

> Message-ID: <[email-masked]>
> From: "Ayers, Mike" <[email-masked]>
> To: "'Lauren Heintz'" <[email-masked]>,
>         Randy Presuhn
> 	 <[email-masked]>
> Cc: [email-masked]
> Subject: RE: ARC + COND
> Date: Thu, 22 Mar 2001 17:18:06 -0600
...
> 	To put it more traditionally, ARC was proposed on the basis of
> M.3100 Amendment 3, which refers explicitly to supressing alarm (condition)
> raises at the source.  I'd like to request that those who have not already
> reviewed this document please do (it's available at the ITU document ftp
> site mentioned previously); it explains many technical details that we would
> wish to discuss, and would serve as a good common reference ground for
> discussions, so we can hopefully avoid some confusion.

We seem to have general agreement that we want the ARC capability.

> 
> 	What you two are talking about doesn't even remotely resemble this
> document.  The idea of M.3100 Amendment 3 is to turn off alarms to all
> managers, be they SNMP, CORBA, or (ugh!) HTTP. 

That is EXACTLY what happens if one uses ARC to supress the notifications
(in the agentx sense) at the level of the resource manager.  We want the
same thing.  Take a look at the data flow diagram.

> 	The last thing that we need is another way to control notifications.

There are no proposals on the table to change the way
the notification originator application (per 2573) is
structured.  I think we have  the same goals in mind.

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