Subject: RE: [Disman] "table wrapping" in alarm MIB -15-

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 10 Oct 2003 14:18:12 -0400

Hi

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

In the definition of alarmActiveEntry is
"
          "Entries appear in this table when alarms are raised.  They
          are removed when the alarm is cleared."

One of the indices into this table is DataAndTime object. This table
therefore will not wrap, so discussing what happens when the table wraps
does not make sense. The statement that indicates that entries are removed
when the alarm is cleared implies that entries stay in the table while they
are active. End of story.

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Friday, October 03, 2003 1:31 AM
To: Disman (E-mail)
Subject: [Disman] "table wrapping" in alarm MIB -15-

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

...
> 75-4) I missed anything like an "alarmActiveMaximum", yet the document 
> doesn't seem to describe what should happen if there are too many 
> active alarms, as might happen if there are lots of instances of a 
> particular type of resource, and an administrator inadvertently 
> specifies a frequent, innocuous event as being of interest.
>
> Sharon->The design was normal table wrapping
...

What is "normal table wrapping"?  This is a new one for me.
The document still needs to specify what happens.  For example, if the alarm
raise is lost, will the clear also be siletly suppressed? Even with
frequency throttling in place, if alarms are sufficiently long lived there
may still accumulate a very large number of them.

Randy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Sat, 18 Oct 2003 19:21:04 -0400

Hi

Ok. I don't understand your issue. There is no maximum because alarms MUST
stay in the table while they are active. There is no wrapping because one of
the indices is DataAndTime so therefore always increasing (unless I'm
missing something).

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Saturday, October 11, 2003 12:03 AM
To: Disman (E-mail)
Subject: Re: [Disman] "table wrapping" in alarm MIB -15-

Hi -

> Sent: Friday, October 10, 2003 11:18 AM
> Subject: RE: [Disman] "table wrapping" in alarm MIB -15-
...
> therefore will not wrap, so discussing what happens when the table 
> wraps does not make sense. The statement that indicates that entries 
> are removed when the alarm is cleared implies that entries stay in the 
> table while they are active. End of story.
...

Sorry, it's not.  Please re-read my original comment:

> > 75-4) I missed anything like an "alarmActiveMaximum", yet the 
> > document doesn't seem to describe what should happen if there are 
> > too many active alarms, as might happen if there are lots of 
> > instances of a particular type of resource, and an administrator 
> > inadvertently specifies a frequent, innocuous event as being of 
> > interest.
...

The issue still stands.

Randy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 21 Oct 2003 22:30:23 -0400

Hi

I think we are in danger of fundamentally changing the architecture of this
'active alarm' list for the sake of a corner case. It's not like we didn't
think of this, but rather that we didn't want an architecture that
encouraged partial active alarm lists.

What exactly is the wg chair looking for with this?

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Tuesday, October 21, 2003 9:45 PM
To: Disman (E-mail)
Subject: Re: [Disman] "table wrapping" in alarm MIB -15-

Hi -

> Sent: Saturday, October 18, 2003 4:21 PM

> Hi
>
> Ok. I don't understand your issue. There is no maximum because alarms 
> MUST stay in the table while they are active. There is no wrapping 
> because one of the indices is DataAndTime so therefore always 
> increasing (unless I'm missing something).
...

Now let's finish the thought:

Storage is finite.  When the number of active alarms would cause available
storage to be exceeded, X happens.  What is X?

Randy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 22 Oct 2003 19:55:38 +0200

> My personal opinion is that creating no entry, and recording 
> that fact in a counter is probably
> a reasonable solution, but am open to other possibilities.  

This looks like a solution I can agree with. I guess that this happens in a zillion of other MIBs that do not happen to go through such a intensive scrutiny, but it is a good thing to document the behavior, and explicitly expose it through a Counter object. 

Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 22 Oct 2003 19:55:38 +0200

Regards,

Dan