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: "Randy Presuhn" <[email-masked]>
Date: Wed, 8 Oct 2003 10:42:40 -0700

Hi -

> Cc: "Randy Presuhn" <[email-masked]>
> Sent: Wednesday, October 08, 2003 5:51 AM
> Subject: RE: [Disman] unthrottleable alarm state change notifications
...
...

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: Wed, 8 Oct 2003 10:42:40 -0700

Hi -

...
...

Randy