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

From: Randy Presuhn <[email-masked]>
Date: Thu, 8 Nov 2001 16:41:14 -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]>
...
> 3) if an existence test row is turned from Enabled to Disabled to
>    Enabled, is state supposed to be kept such that previously existing
>    rows are remembered to have been in existence?  (I'd say no, simply
>    because it sort of implies starting over and similarly doing
>    thresholding based on delta values would probably trigger an event
>    when it was re-enabled since the delta is quite possibly going to
>    be large if a large time had elapsed).
...

I agree.  Do we need to add clarifying text?

 ------------------------------------------------------
 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: "Ram Kavasseri" <[email-masked]>
Date: Fri, 9 Nov 2001 19:49:08 -0800

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Randy Presuhn
> Sent: Thursday, November 08, 2001 4:41 PM
> Subject: Re: RFC 2981 (disman event MIB) Implementation Experience
> 
> 
> Hi -
> 

I suspect we're talking about the mteTriggerEntry?
It contains the mteTriggerEnabled object for enabling
or disabling triggers.

The DESCRIPTION for mteTriggerEntryStatus states:

mteTriggerEntryStatus OBJECT-TYPE
    SYNTAX      RowStatus
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "The control that allows creation and deletion of entries.
        Once made active an entry may not be modified except to
        delete it."
    ::= { mteTriggerEntry 15 }

Hence the scenario Wes highilghted will not arise.

Cisco's implementation does not permit modifications to the
row, as per the DESCRIPTION above.

Which brings up the next question - if you cannot modify a row,
why bother providing mteTriggerEnabled?

My 2 cents would be to change the above DESCRIPTION to permit
modifications ONLY to the mteTriggerEnabled object. If the
value of this object transitions from enabled to disabled, all
state information should be dropped for that trigger. 

Comments?

Ram

>  Tel: +1 408 546-1006   San Josi, California 95131  USA

---

From: "Dale Francisco" <[email-masked]>
Date: Mon, 12 Nov 2001 13:00:21 -0800

Some possible clarifying text for the DESCRIPTION
of 'mteTriggerEnabled':

> mteTriggerEnabled OBJECT-TYPE
>     SYNTAX      TruthValue
>     MAX-ACCESS  read-create
>     STATUS      current
>     DESCRIPTION
>         "A control to allow a trigger to be configured but not used.
>         When the value is 'false' the trigger is not sampled.
> 
>         Whenever the value goes from 'false' to 'true', the trigger
>         is treated as being initialized.  That is, no history is kept
>         of any trigger sample values from previous times when this
>         control may have been enabled."
>     DEFVAL { false }
>     ::= { mteTriggerEntry 14 }
>

---

From: "Ram Kavasseri" <[email-masked]>
Date: Mon, 12 Nov 2001 15:28:40 -0800

> [mailto:[email-masked]]On Behalf Of Dale Francisco
> Sent: Monday, November 12, 2001 1:00 PM
> To: Randy Presuhn; Ram Kavasseri; [email-masked]
> Subject: RE: RFC 2981 (disman event MIB) Implementation Experience
> 
> 

As a clarification, if an mteTrigger is of type threshold,
at the time its mteTriggerEnabled value is set to true, what
should the behavior be if the measured value is already above
the threshold (at the first reading)?

Also, when the mteTriggerEnabled value is set to true, what
should the behavior be if we set the value to true again, without
setting it to false? Should this be an implicit (true-false-true)
transition, or should this be rejected as an inconsistentValue (i.e.
once true, the only settable value is false) ?

Ram

---

From: Ramanathan Kavasseri <[email-masked]>
Date: Wed, 14 Nov 2001 00:33:47 -0800

> >         When the value is 'false' the trigger is not sampled.

FYI, the above two lines use the words "used" and
"sampled" for the same purpose. I chose to use "sampled"
consistently in both places. Please let me know if some other
wording should be used, or if I should use the original text as is.

Ram

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 20 Nov 2001 16:01:50 -0800

>>>>> On Mon, 12 Nov 2001 13:00:21 -0800, "Dale Francisco" <[email-masked]> said:

Dale> Some possible clarifying text for the DESCRIPTION
Dale> of 'mteTriggerEnabled':

>> Whenever the value goes from 'false' to 'true', the trigger is
>> treated as being initialized.  That is, no history is kept of any
>> trigger sample values from previous times when this control may
>> have been enabled."

I'd say "as being newly initialized"
                  ^^^^^

Just to add one more level of clarity.

-- 
Wes Hardaker
NAI Labs
Network Associates

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 20 Nov 2001 16:06:09 -0800

>>>>> On Fri, 9 Nov 2001 19:49:08 -0800, "Ram Kavasseri" <[email-masked]> said:

Ram> I suspect we're talking about the mteTriggerEntry?

Yep.

Ram> It contains the mteTriggerEnabled object for enabling
Ram> or disabling triggers.

Ram> The DESCRIPTION for mteTriggerEntryStatus states:

Ram> mteTriggerEntryStatus OBJECT-TYPE
Ram> SYNTAX      RowStatus
Ram> MAX-ACCESS  read-create
Ram> STATUS      current
Ram> DESCRIPTION
Ram> "The control that allows creation and deletion of entries.
Ram> Once made active an entry may not be modified except to
Ram> delete it."
Ram> ::= { mteTriggerEntry 15 }

Ram> Hence the scenario Wes highilghted will not arise.

Ram> Cisco's implementation does not permit modifications to the row,
Ram> as per the DESCRIPTION above.

Heh.  How useless.  Certainly it putting the row to active when it's
in a disabled state would be kind of silly if you couldn't enable it
in the future.

Anyway, I read that text as refering to the mteTriggerEntryStatus
object not the entire row, as it's what made sense to me when reading
it (I don't mind implementing modifications to rows already marked as
active, so I didn't translate the word "entry" to "row" in my mind
like I should have done).  Because of the text that said "except to
delete it" further locked the idea into my mind that the entire
sentence was referring to only that column.  Opps.

Ram> Which brings up the next question - if you cannot modify a row,
Ram> why bother providing mteTriggerEnabled?

Ram> My 2 cents would be to change the above DESCRIPTION to permit
Ram> modifications ONLY to the mteTriggerEnabled object. If the value
Ram> of this object transitions from enabled to disabled, all state
Ram> information should be dropped for that trigger.

I'd say this is certainly a bare minimum.

-- 
Wes Hardaker
NAI Labs
Network Associates

---

From: Ramanathan Kavasseri <[email-masked]>
Date: Wed, 21 Nov 2001 14:09:26 -0800

> in a disabled state would be kind of silly if you couldn't enable it

ROTFL - yes. Very useless. :-)
FYI the new draft of the event MIB modifies this DESCRIPTION
so as to permit the value of mteTriggerEnabled to be changed.

Ram

---

From: Ramanathan Kavasseri <[email-masked]>
Date: Wed, 21 Nov 2001 14:11:45 -0800

> Just to add one more level of clarity.

But doesn't "initialized" mean "from the beginning, as if it
were new"? So "newly initialized" would be redundant IMHO.
Do you still want this clarification added?

Ram