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

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 8 Oct 2003 08:51:44 -0400

Hi

The following is the proposed resolution to Randy-55. Assuming no objection,
this item will is closed with no changes to the draft.

It was design intent to prevent the deletion of alarm models while there
were active alarms using that model.

Randy has indicated that he is OK with not specifying an amount of time
before entries are deleted.

Sharon

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

Hi -

> From: "Sharon Chisholm" <[email-masked]>
> To: "Disman (E-mail)" <[email-masked]>
> Cc: <[email-masked]>; "Randy Presuhn" 
> <[email-masked]>; "Romascanu, Dan (Dan)"
<[email-masked]>
> Sent: Monday, September 29, 2003 7:34 AM
> Subject: [Disman] RE: Comments on draft-ietf-disman-alarm-mib-14.txt
...
> 55) alarmModelRowStatus does not permit modification of a
>     model while active alarms exist.  This would seem to create
>     the possibility of "un-throttle-able" alarm storms, contrary
>     to the spirit of draft-ietf-ops-mib-review-guidelines-01.txt
>     section 4.7 last paragraph.
...

The updated text is still problematic. Specifically, this text remains:

       This row can not be modified or deleted while it is being
       referenced by a value of alarmActiveModelPointer. In these

As long as there is an active alarm referencing the model, one would not be
able to take action using this MIB to throttle it.

Also, the entry removal text doesn't specify a lifetime, and the famous five
minutes in 2579 are only a suggestion, so the current text really leaves it
up to the implementation.  This is OK with me, but I want to be sure it's
what is intended.

Randy

---

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 -

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

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

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