Subject: Re: List of edits applied to the Event MIB

From: Ramanathan Kavasseri <[email-masked]>
Date: Fri, 07 Jan 2000 12:51:10 -0800

I'm down to the last issue for the Event MIB (*gasp*), issue Event-09.
I'd sent this mail out on the 21st of December, but haven't seen any
comments on the DESCRIPTIONS for the two objects being added.
So I'll wait one more day, and if I don't hear anything, I'll assume the
objects are ok as is, and will wind up the edits (for this stage) on the
event MIB...

(I've snipped out the parts that were agreed upon from the original mail).

At 05:06 PM 12/21/99 -0800, Ramanathan Kavasseri wrote:
>
>At 11:21 AM 12/21/99 -0800, Randy Presuhn wrote:
>>
>>> 9. For Disman issue Event-09:
>>> 
>>> The following is an extract from the disman issue Event-09 discussion:
>>> 
>>> > > Page 26:
>>> > > 
>>> > > This is a general coment about the Trigger Threshold Table.  Rising and
>>> > > Falling and combination objects are specified.  What is absent is the
>>> > > rate of change which is often in values (not talking about delta
>>> > > discontinuity here).  For example an object such as
>>> > > mteTriggerThresholdRisingDelat could be added (would require mod of
>>> > > mteTriggerThresholdStartup) which rahter than an absolute value
would be
>>> > > measured at each interval so that if the change exceeded the value the
>>> > > trigger threshold would be thought to have been exceeded.  If this was
>>> > > already discussed and dismissed, OK but I think from an operational
>>> > > perspective this is of value.
>>> 
>>> > Proposed resolution: add the suggested objects.
>>> > 
>>> > Objections?  Alternatives?
>>> 
>>> You would also need mteTriggerRisingDeltaInterval and 
>mteTriggerFallingDeltaInterval,
>>> since you need both the range and the time to calculate a 
>rate-of-climb/fall.
>>> Comments?
>>
>>The additional *Interval objects would not be needed, since
>>the MIB already has a notion of sampling frequencies.
>
>Heh...Now I'm red-faced...
>:-)
>
>I added the two objects "mteTriggerThresholdDeltaRising" and
>"mteTriggerDeltaFalling", and they're pasted below...The
>DESCRIPTION needs a little work, so I'll let folks comment away.
>
>I was going to modify mteTriggerThresholdStartup, and then
>realized that since we're talking about "deltaRising" and "deltaFalling",
>we need two samples, and hence we shouldn't modify
>mteTriggerThresholdStartup...Comments?
>
>mteTriggerThresholdDeltaRising OBJECT-TYPE
>    SYNTAX      Integer32
>    MAX-ACCESS  read-write
>    STATUS      current
>    DESCRIPTION
>	"A threshold value to check against if mteTriggerType is
>	'threshold'.
>
>	When the delta value (difference) between the current sampled
>	value (value(n)) and the previous sampled value (value(n-1))
>	is greater than or equal to this threshold,
>	and the delta value calculated at the last sampling interval
>	(i.e. value(n-1) - value(n-2)) was less than this threshold,
>	one mteTriggerThresholdRisingEvent is triggered. That event is
>	also triggered if the first delta value calculated after this
>	entry becomes active, i.e. value(2) - value(1), where value(1)
>	is the first sample taken of that instance, is greater than or
>	equal to this threshold.
> 
>	After a rising event is generated, another such event is not
>	triggered until the delta value falls below this threshold and
>	reaches mteTriggerThresholdDeltaFalling."
>    DEFVAL { 0 }
>    ::= { mteTriggerThresholdEntry 4 }
>
>mteTriggerThresholdDeltaFalling OBJECT-TYPE
>    SYNTAX      Integer32
>    MAX-ACCESS  read-write
>    STATUS      current
>    DESCRIPTION
>	"A threshold value to check against if mteTriggerType is
>	'threshold'.
>
>	When the delta value (difference) between the current sampled
>	value (value(n)) and the previous sampled value (value(n-1))
>	is less than or equal to this threshold,
>	and the delta value calculated at the last sampling interval
>	(i.e. value(n-1) - value(n-2)) was greater than this threshold,
>	one mteTriggerThresholdFallingEvent is triggered. That event is
>	also triggered if the first delta value calculated after this
>	entry becomes active, i.e. value(2) - value(1), where value(1)
>	is the first sample taken of that instance, is less than or
>	equal to this threshold.
> 
>	After a falling event is generated, another such event is not
>	triggered until the delta value rises above this threshold and
>	reaches mteTriggerThresholdDeltaRising."
>    DEFVAL { 0 }
>    ::= { mteTriggerThresholdEntry 5 }
>

---

From: Jon Saperia <[email-masked]>
Date: Sun, 09 Jan 2000 12:29:11 -0500

Ram,

Yes, these are the types of objects with the semantics I was thinking
about when I made the suggestion for the additions. After we get some
additional implementation experience we may find that mods or additions
are necessary. For now I am happy.

/jon

---

From: "Ramanathan R. Kavasseri" <[email-masked]>
Date: Mon, 10 Jan 2000 00:49:31 -0800

>are necessary. For now I am happy.

Jon,

thanks for the feedback. I'll have the latest EVENT-MIB draft posted today...

Ram