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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 23 Oct 2003 15:27:03 +0200

> 
> Hi -
> 
> > From: "Sharon Chisholm" <[email-masked]>
> > To: "Disman (E-mail)" <[email-masked]>
> > Sent: Saturday, October 18, 2003 1:31 PM
> > Subject: RE: [Disman] unthrottleable alarm state change 
> notifications
> ...
> > 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.
> ...
> 
> 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.

Yes. In general the text in the security considerations should be more detailed in explaining the implications of performing write operations on the read-write or read-create objects. For example in this case:

'Changes values of alarmModelRowStatus as part of creating and deleting rows in the alarmModelTable result in adding new alarm models to the system or taking them out. These operations need to be carefully planned. Adding a new model should be made in a consistent manner to avoid the system overflow with alarms. Taking out a model should result in the deletion of all this model related alarms in the system.'

> Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 23 Oct 2003 10:47:36 -0700

Hi -

> From: "Romascanu, Dan (Dan)" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; "Disman (E-mail)" <[email-masked]>
> Sent: Thursday, October 23, 2003 6:27 AM
> Subject: RE: [Disman] unthrottleable alarm state change notifications
...
> Yes. In general the text in the security considerations should be
> more detailed in explaining the implications of performing write
> operations on the read-write or read-create objects. For example
> in this case:
>
> 'Changes values of alarmModelRowStatus as part of creating
> and deleting rows in the alarmModelTable result in adding new
> alarm models to the system or taking them out. These operations
> need to be carefully planned. Adding a new model should be made
> in a consistent manner to avoid the system overflow with alarms.
> Taking out a model should result in the deletion of all this model
> related alarms in the system.'

I like this a lot, though I think the last "should" should be a "MUST".
I expect Sharon will wordsmith it into shape, if no one objects to it.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 23 Oct 2003 10:47:36 -0700

Hi -

...

Randy