Subject: RE: ARC + COND

From: "Ayers, Mike" <[email-masked]>
Date: Thu, 22 Mar 2001 17:18:06 -0600

Not only could I not go to Minneapolis, but I also barely have
enough time to read this, much less input!   *SIGH*

	However...

> From: Lauren Heintz [mailto:[email-masked]]
> 
> Randy Presuhn wrote:
> > 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.
> 
> 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.
> 

	WHOAH NELLY!!!!

	Can we say "NotifyFilterProfileTable"?  Altogether now...

	"NotifyFilterProfileTable"

	Good!  Now can someone explain to me why we need another one?

	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.

	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. 

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

/|/|ike