Subject: Re: RFC 2981 (disman event MIB) Implementation Experience

From: Randy Presuhn <[email-masked]>
Date: Thu, 8 Nov 2001 16:38:30 -0800 (PST)

Hi -

> To: [email-masked]
> Subject: event-mib issues/questions:
> From: Wes Hardaker <[email-masked]>
> Date: 29 Jan 2001 17:47:32 -0800
> Message-ID: <[email-masked]>
...
> 2) The odd combination of mteTriggerEnabled/mteTriggerEntryStatus
>    works, certainly, but seems counter-intuitive compared to other
>    MIBs I've seen.  Why is there a separate column for enabling a row
>    (as opposed to using notInService)?  Why can't a row be put into
>    notInService (the mib states that the only legal value after action
>    is destroy).
...

The reason for this is that setting the RowStatus to
notInService could cause the row to disappear after a
short time.  This is a recurring difficulty with RowStatus.
RFC 2579 is adamant; read down to the last sentence of this
excerpt from the definitions of RowStatus:

    If the management station is prevented from setting the
    status column to `active' (e.g., due to management station
    or network failure) the conceptual row will be left in the
    `notInService' or `notReady' state, consuming resources
    indefinitely.  The agent must detect conceptual rows that
    have been in either state for an abnormally long period of
    time and remove them.  It is the responsibility of the
    DESCRIPTION clause of the status column to indicate what an
    abnormally long period of time would be.  This period of
    time should be long enough to allow for human response time
    (including `think time') between the creation of the
    conceptual row and the setting of the status to `active'.
    In the absence of such information in the DESCRIPTION
    clause, it is suggested that this period be approximately 5
    minutes in length.  This removal action applies not only to
    newly-created rows, but also to previously active rows which
    are set to, and left in, the notInService state for a
    prolonged period exceeding that which is considered normal
    for such a conceptual row.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 9 Nov 2001 10:18:39 +0100

>>>>> Randy Presuhn writes:

Randy> The reason for this is that setting the RowStatus to
Randy> notInService could cause the row to disappear after a short
Randy> time.  This is a recurring difficulty with RowStatus.

RowStatus is "hack" to create/delete rows since we do not have proper
create/delete protocol operations and nothing more. I believe that
people who overload RowStatus with enable/disable semantics are making
a mistake. So this is not recurring difficulty is not RowStatus but
a recurring difficulty due to the "misuse" of RowStatus.

In other words, I believe that the DISMAN-EVENT-MIB (and the other
DISMAN MIBs I am familiar with) got it right.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 09 Nov 2001 09:40:06 -0800

>a recurring difficulty due to the "misuse" of RowStatus.

I agree completely about RowStatus. (I think SMIv2 tables
are a hack, but that's another thread. ;-)

Here's the text from RFC 2579 that prevents 'notInService'
from being used as a 'disable' mechanism:

    If the management station is prevented from setting the status column
    to `active' (e.g., due to management station or network failure) the 
    conceptual row will be left in the `notInService' or `notReady' state, 
    consuming resources indefinitely. The agent must detect conceptual rows 
    that have been in either state for an abnormally long period of time and
    remove them. 

>DISMAN MIBs I am familiar with) got it right.

Andy

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 20 Nov 2001 15:57:14 -0800

>>>>> On Thu, 8 Nov 2001 16:38:30 -0800 (PST), Randy Presuhn <[email-masked]> said:

>> notInService (the mib states that the only legal value after action
Randy> ...

Ahh.  *Grumble grumble*

We need a "notInServiceButNotDisappearing" state added to the
RowStatus TC.

I guess things as are do make sense then.

-- 
"Ninjas aren't dangerous.  They're more afraid of you than you are of them."