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

From: Randy Presuhn <[email-masked]>
Date: Tue, 21 Dec 1999 11:21:07 -0800 (PST)

Hi -

> From: Ram Kavasseri <[email-masked]>
> Subject: List of edits applied to the Event MIB
> To: [email-masked]
> Date: Tue, 21 Dec 1999 10:50:47 -0800 (PST)
...
> 2. Disman issue Event-02: Adding a "health warning":
>  "It MAY not be possible to meaningfully monitor Counter64 objects
> using an SMIv1 version of the MIB". 
> 
> Where should I add the above warning, and is the above text ok?

The "MAY" should be "may" in this case, since we're using the word
in its English sense, rather than as a conformance requirement.
I'd put the text at the very end of clause 2.

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

...
> > Page 48 Acknowledgements should be Acknowledgments
> 
> I think it should be "Acknowledgements" - checked rfc2571 and rfc2575
> to confirm this. So I haven't made this change.

It depends on which dictionary you use.  Webster's gives 
"acknowledgments" as the preferred spelling.

...
> 16. Corrected the typo "[email-masked]" to "[email-masked]".

Should be [email-masked]

(Yes, I know [email-masked] works.  This is a feature.
 Yes, I know it's showing up as [email-masked] in email
 headers.  This is a bug, and our IS people assure me it will
 soon be fixed.  (It was fixed a long time ago, but has since
 become un-fixed.)

...
> 18. All occurrences of rfc2119 words were capitalized.
...

They should only be capitalized when they are being used to
state a conformance requirement.

 ------------------------------------------------------------------------
 Randy Presuhn           [email-masked]       http://www.bmc.com/
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141  2141 N. First Street
 Fax:   +1 408 965-0359  San Jose, California 95131  USA
 ------------------------------------------------------------------------
 Any relationship between my opinions and BMC's should be coincidental.
 ------------------------------------------------------------------------

---

From: Ramanathan Kavasseri <[email-masked]>
Date: Tue, 21 Dec 1999 17:06:19 -0800

>I'd put the text at the very end of clause 2.

Done.

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

>state a conformance requirement.

red-faced again...Addressed it. 

Ram