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

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 11 Nov 2003 14:23:41 -0500

Hi

The following is the proposed resolution to Randy-55. Assuming no objection,
this item will be considered closed conditional on the proposed edit being
done.

In the description of alarmModelRowStatus replace

"      This row can not be modified or deleted while it is being
       referenced by a value of alarmActiveModelPointer. In these
       cases, an error of `inconsistentValue' will be returned to
       the manager."

With

"      This row can not be modified while it is being
       referenced by a value of alarmActiveModelPointer. In these
       cases, an error of `inconsistentValue' will be returned to
       the manager.

       This entry may be deleted while it is being
       referenced by a value of alarmActiveModelPointer. This results
       in the deletion of this entry and entries in the active alarms
       referencing this entry via a alarmActiveModelPointer."

Add the following text to the security considerations section

"Changing 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 respectively. 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."

Which I guess results in the following change to the text proposed to
resolve Randy-75-2

Replace
" Setting these objects may have disruptive effects on network
  operation by the flooding of unwanted alarm notifications 
  from the network. It is possible to define multiple alarm that
  are triggered from the same frequently occurring internal stimulus and
  uses the alarmActiveState notification to inform interested managers.
  Since it is not possible to delete alarm models when it has active alarms,
  and the defined alarm throttling mechanism is limited to a single alarm,
  this could result in a continuous stream alarm notifications that there
  is no mechanism defined within this memo to control."

With

" Note that the alarm throttling mechanism associated with the
alarmActiveState and alarmActiveClear notifications only applies to a given
alarm. Defining multiple alarms from the same internal stimulus may then
still result in a flood of alarms into the network."

Sharon

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

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: "Sharon Chisholm" <[email-masked]>
Date: Tue, 11 Nov 2003 14:23:41 -0500

Hi

With

Replace

With

Sharon

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

Hi -

...

Randy

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 12 Nov 2003 09:31:05 -0600 (GMT-06:00)

Hi -

This looks fine to me.  However, it's not fully consistent with the proposed
security considerations text, since permitting this deletion provides
a way to stop runaway or oscillating configurations.  I think the proposed
text about it being possible to create runaways should remain, but this
change provides a way to stop them.

Randy

-----Original Message-----
From: Sharon Chisholm <[email-masked]>
Sent: Nov 11, 2003 1:23 PM
To: "Disman (E-mail)" <[email-masked]>
Subject: RE: [Disman] unthrottleable alarm state change notifications

Hi

With

Replace

With

Sharon

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

Hi -

...

Randy

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 12 Nov 2003 09:31:05 -0600 (GMT-06:00)

Hi -

Randy

-----Original Message-----
From: Sharon Chisholm <[email-masked]>
Sent: Nov 11, 2003 1:23 PM
To: "Disman (E-mail)" <[email-masked]>
Subject: RE: [Disman] unthrottleable alarm state change notifications

Hi

With

Replace

With

Sharon

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

Hi -

...

Randy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 12 Nov 2003 10:35:00 -0500

Hi

The last item of this proposed change is to go back and replace the proposed
text for Randy-75-2. I think it says what you indicate it should say.

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Wednesday, November 12, 2003 10:31 AM
To: [email-masked]
Subject: RE: [Disman] unthrottleable alarm state change notifications

Hi -

This looks fine to me.  However, it's not fully consistent with the proposed
security considerations text, since permitting this deletion provides a way
to stop runaway or oscillating configurations.  I think the proposed text
about it being possible to create runaways should remain, but this change
provides a way to stop them.

Randy

-----Original Message-----
From: Sharon Chisholm <[email-masked]>
Sent: Nov 11, 2003 1:23 PM
To: "Disman (E-mail)" <[email-masked]>
Subject: RE: [Disman] unthrottleable alarm state change notifications

Hi

With

Replace

With

Sharon

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

Hi -

...

Randy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 12 Nov 2003 10:35:00 -0500

Hi

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Wednesday, November 12, 2003 10:31 AM
To: [email-masked]
Subject: RE: [Disman] unthrottleable alarm state change notifications

Hi -

Randy

-----Original Message-----
From: Sharon Chisholm <[email-masked]>
Sent: Nov 11, 2003 1:23 PM
To: "Disman (E-mail)" <[email-masked]>
Subject: RE: [Disman] unthrottleable alarm state change notifications

Hi

With

Replace

With

Sharon

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

Hi -

...

Randy

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 12 Nov 2003 09:44:10 -0600 (GMT-06:00)

Hi -

Ah.  I missed that.  Downside of trying to do email via a webpage.  :-(
I'm now happy with the proposed (combined) resolution of the items.
(though it wouldn't hurt to mention in the security considerations that
such a cascade can be stopped by deleting the offending alarm model.)

Randy

-----Original Message-----
From: Sharon Chisholm <[email-masked]>
Sent: Nov 12, 2003 9:35 AM
To: [email-masked]
Subject: RE: [Disman] unthrottleable alarm state change notifications

Hi

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Wednesday, November 12, 2003 10:31 AM
To: [email-masked]
Subject: RE: [Disman] unthrottleable alarm state change notifications

Hi -

Randy

-----Original Message-----
From: Sharon Chisholm <[email-masked]>
Sent: Nov 11, 2003 1:23 PM
To: "Disman (E-mail)" <[email-masked]>
Subject: RE: [Disman] unthrottleable alarm state change notifications

Hi

With

Replace

With

Sharon

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

Hi -

...

Randy

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 12 Nov 2003 09:44:10 -0600 (GMT-06:00)

Hi -

Randy

-----Original Message-----
From: Sharon Chisholm <[email-masked]>
Sent: Nov 12, 2003 9:35 AM
To: [email-masked]
Subject: RE: [Disman] unthrottleable alarm state change notifications

Hi

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Wednesday, November 12, 2003 10:31 AM
To: [email-masked]
Subject: RE: [Disman] unthrottleable alarm state change notifications

Hi -

Randy

-----Original Message-----
From: Sharon Chisholm <[email-masked]>
Sent: Nov 11, 2003 1:23 PM
To: "Disman (E-mail)" <[email-masked]>
Subject: RE: [Disman] unthrottleable alarm state change notifications

Hi

With

Replace

With

Sharon

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

Hi -

...

Randy