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

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 -

> From: "Sharon Chisholm" <[email-masked]>
> To: "Disman (E-mail)" <[email-masked]>
> Sent: Saturday, October 18, 2003 4:21 PM
> Subject: RE: [Disman] "table wrapping" in alarm MIB -15-
>

> 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: "Randy Presuhn" <[email-masked]>
Date: Tue, 21 Oct 2003 20:13:35 -0700

Hi -

> Sent: Tuesday, October 21, 2003 7:30 PM
...
...

The chair wants the guy the AD asked to review the document to be happy.

He'd like text that says what happens when an alarm model entry matches a
notification delivered to the alarm inrastructure, and there is not sufficient storage (or
other resources) available to create a new alarm entry.  Possibilities:

    - no alarm entry is created
    - some alarm entry is deleted or cleared to make room (algorithm needs to be spelled out)
    - something records that this has happened

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.  We went through the design issues
in the log MIB.  I suspect the tradeoffs are very similar here. This reviewer will be happy as long
as the MIB is explicit about what happens; I think this MIB's proponents will figure out what
the best thing would be to do when storage is exhausted.

I agree that it's desirable to not encourage partial active alarm lists, but I also
want *realistic* standards, i.e., no assumptions that storage is infinite.

Randy (In all his roles.  :-)

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 21 Oct 2003 20:13:35 -0700

Hi -

...
...