Subject: RE: [Disman] unthrottleable alarm state change notifications

From: "Sharon Chisholm" <[email-masked]>
Date: Sat, 18 Oct 2003 16:31:48 -0400

Hi

Again, this is the trade-off that made sense when we last discussed the
problem. Allowing deletion of models with active alarm instances leaves
orphaned active alarms. Not allowing it makes it more difficult to delete
the alarm models.

There would be three possible ways to address the concern
	- Add new instrumentation to manage emergency killing of alarms
	- Allow deletion of alarm models at any time, but force the clean up
of any of their active alarms
	- Keep exactly as is and make a note in the security considerations.

I'd like to take the first one off the table as both over engineering and
too big of a change to make at this point. The second one makes me a bit
nervous but I think I could live with it. I suspect one or more of Randy's
hats would object to the third.

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Wednesday, October 08, 2003 1:43 PM
To: Disman (E-mail)
Subject: Re: [Disman] unthrottleable alarm state change notifications

Hi -

> From: "Sharon Chisholm" <[email-masked]>
> To: "Disman (E-mail)" <[email-masked]>
> Cc: "Randy Presuhn" <[email-masked]>
> Sent: Wednesday, October 08, 2003 5:51 AM
> Subject: RE: [Disman] unthrottleable alarm state change notifications
...
> It was design intent to prevent the deletion of alarm models while 
> there were active alarms using that model.
...

Is no one else bothered by the behavior this design produces?
    - manager (mistakenly) creates alarm model that matches some frequent
event
       from a large number of sources (e.g., process creation or connection
attempt)
    - zillions of alarms are created
    - manager, realizing mistake, can't shut it down:
         - cannot modify alarmModelEntry attributes to correct mistake
         - cannot delete alarmModelEntry
    - the alarm model entry persists, so even re-booting the system won't
fix
       the problem

There's an even simpler failure mode:
    - manager creates an alarm model, but the "clear" entry refers to an
event
       that will never happen, perhaps due to a typo, or perhaps due to the
       way the managed system works
    - one (or more alarms) created
    - there is no way to clear these alarms
    - there is no way to get rid of the erroneous alarm model

If this is really what the WG wants, the chair will let it go, but this
technical contributor thinks its a big mistake. If there's an error in my
reasoning here, please elucidate.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 21 Oct 2003 17:39:19 -0700

Hi -

> Sent: Saturday, October 18, 2003 1:31 PM
...
...

I agree that the first option would be too drastic, and you were right about
my reaction to the third.  :-)

I could live with the second one, but would want some text added to the
security considerations section as part of the rationale explaining why the
alarmModelRowStatus is considered sensitive, and in discussion of its
value in recovering from what could otherwise be pathological misconfigurations.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 21 Oct 2003 17:39:19 -0700

Hi -

...
...

Randy