Subject: RE: ARC + COND

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

> From: Randy Presuhn [mailto:[email-masked]]
> 
> We seem to have general agreement that we want the ARC capability.
> 

	WHEW!

> > 
> > 	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 one you wrote says that.  The one Lauren did, using the "#" as
ARC point, did not, and was my cause for concern.

/|/|ike

---

From: Lauren Heintz <[email-masked]>
Date: Thu, 22 Mar 2001 19:50:23 -0800

Hi Mike,

I think Randy eased my concern about
how a tech would disable notifications
without clearing the activeAlarmTable.

Answer: don't use the ARC MIB (if supported)
to disable alarms.  If it's not supported,
then it won't get cleared (unless of course
all faults are resolved).

And as you suggest, the notification
table probably is adequate to disable the
notifications, though depending on the way
it is configed, it might not be "easy" (i.e.
may require 1..N RowStatus objects to be
changed to NotInService -- NIS).  Getting really
nit-picky though (and I'll probably regret doing so),
the downside of disabling notifs this way is that
when you change the affected rows to NIS, those particular
row configs probably get removed from NV storage (depending
on impl strategy of StorageType) at that time.  Then while
your notifs are disabled, if you do something to the device
that inadvertently causes a reboot (perhaps easily done
depending on exactly which fault you are trying to solve),
you lose that part of your config, and the tech has yet
another config chore after the fault is resolved.  Even if
you don't cause a reboot, if your troubleshooting chore takes
more than a few minutes, the NIS rows may get automatically
destroyed by a row timer, which the RowStatus TC calls for to
happen (implementation defined time limit, if I recall correctly).
Suddenly, the idea of "easy way of disabling notifications" is no
longer as easy as one hoped for.

I sort of view the target/notify tables as static configurables
that you hope not to have to twiddle with very often, and that
you have a few other cute buttons and knobs that allow you to easily
do common tasks without always mucking with a proven/tested config.
But I realize I may not be speaking for the typical user.

Thanks, Lauren