Subject: Re: Event MIB implementation questions

From: Randy Presuhn <[email-masked]>
Date: Mon, 13 Dec 1999 16:19:04 -0800 (PST)

Hi -

> Date: Fri, 3 Dec 1999 13:22:40 -0500 (EST)
> From: Alan Luchuk <[email-masked]>
> To: [email-masked]
> Subject: Event MIB implementation questions
> Cc: [email-masked]
> List-Id: IETF disman Working Group mailing list <[email-masked]>
...
> I have not been following the discussions of the DISMAN-EVENT-MIB.
> We currently have an implementation based upon a very old draft
> (maybe draft 4 or 5) done by another engineer.  Very recently, I 
> have been asked to review the latest draft, <draft-ietf-disman-
> event-mib-08.txt>.  I expect at some point we will be updating
> our DISMAN-EVENT-MIB implementation.

That's good to hear.  Given the tenor of the comments to date, I
think there is a fair chance that this material, after publication
as an RFC, might have to spin at "proposed".  The more feedback
we have from actual implementation and usage experience, the
better.

...
> Under mteTriggerSampleType, the text for 'deltaValue' says:
> 
>    "It is the difference between the two samples.  For unsigned 
>     values it is always positive, based on unsigned arithmetic."
> 
> What happens if two gauge-types are subtracted, and the result
> is a negative number?

I believe the intent is for the value to be
Value[N] = AbsoluteValue(Sample[N] - Sample[N-1])

....
> The last issue sort of leads to a larger question about how
> the DISMAN-EVENT-MIB handles thresholding or booleans on unsign-
> ed types in general, given that objects like  mteTriggerBoolean-
> Value, mteTriggerThresholdValue, mteTriggerThresholdRising, and 
> mteTriggerThresholdFalling, all are Integer32 values.

I think the MIB can only be expected to know that these
subtyped things are Integer32.

...
> I'm curious about the logic and usefulness of having the
> following MIB objects:
> 
>     mteTriggerObjectsOwner
>     mteTriggerExistenceObjectsOwner
>     mteTriggerBooleanObjectsOwner
>     mteTriggerThresholdObjectsOwner
>     mteEventNotificationObjectsOwner
> 
> As I understand these objects, they let the MIB user
> specify the owner of entries in the mteObjectsTable (so 
> additional MIB objects can be specified in notifications.)
> If I understand correctly, using these MIB objects means
> that trigger/event entries configured by one user can access
> entries in the mteObjectsTable configured by another user.

I think the DESCRIPTIONs of mteTriggerTargetTag (and mteEventSetTargetTag)
outline how it was supposed to work.  These would permit such access
in this way under two circumstances:
    1) mteTriggerTargetTag is zero-length  AND
       the credentials of the row's activator are sufficient to
       convince VACM to permit access to this other user's stuff in
       mteObjectsTable.
    2) mteTriggerTargetTag is not zero-length AND
       the security paraneters for that tag are sufficient.
To me, this means that only trusted users should be permitted to
write mteTriggerTargetTag.

> This implies that, if this capability is used, VACM cannot 
> be used to control access based upon the mteEventOwner as 
> described in the last paragraph on page 6.

That part is fine, I think.  The first level of indirection
also works, though it's a bit ugly.  The second level of
indirection, mteTriggerTargetTag length not equal to zero,
requires that the security administrator trust anyone permitted
to write that object about as much as he or she would trust
someone setting up the SNMP-TARGET-MIB.

Potentially cleaner ways of handling this have been discussed
both in WG meetings and among the editors of various disman
drafts, but did not make it into this document.  Personally,
I've been surprised at the lack of controversy surrounding
the formulation of some of these objects.

...
> Can someone help me understand the function of the 
> mteTriggerDeltaTable and how it works?   What is the
> definition of "discontinuity?"  This table _seems_ 
> to be intended either:
> 
> -  to catch situations where time stamps go backward; or
> -  record the time stamp when a discontinuity in another
>    MIB object was observed.
> 
> Catching situations where time stamps go backwards seems
> like a very useful idea.  But even sampling time stamps at
> N-second intervals will result in discrete (discontinous) 
> samples.  A bit of additional explanation of this table
> might help newbie implementors (like me) understand this
> table.

In SNMP-land, a "discontinuity" needs to be understood as an
event which renders meaningless deltas computed over a sample
taken before the event and a sample taken after the event.
Thus, counter wrap per se is NOT a discontinuity, but a
sysUpTime reset probably is.

When looking at clock samples, this means verifying that the clock:

    1) doesn't run backwards
    2) advances at a rate similar to that of one's own

...
> How is the mteTriggerExistenceStartup supposed to work?
> The mteTriggerExistenceTest describes the bit functions as:
> 
>   present  - MIB object transitions from present to absent
>   absent   - MIB object transitions from absent to present
>   changed  - MIB object value changes
> 
> The mteTriggerExistenceStartup specifies whether the trigger
> happens when the table row is first made active.  But the
> definition of 'present', 'absent', or 'changed' suggests
> the table was sampling the MIB object even before the table
> row is made active.  Either my understanding is incomplete,
> or this seems difficult, if not impossible, to implement.

There is no need to sample the monitored object before the
mteTriggerEntry goes active.  Once the mteTriggerEntry goes
active, think of it as though it were issuing local GETs
for the monitored object.  The transition from noSuchName to
getting a value in the response would be the absent->present
transition.

...
> What is the purpose of mteTriggerThresholdValue?

Good question.  Anyone?

...
> The DESCRIPTION clause of mteTriggerThresholdRising includes
> the following text:
> 
>    "After a rising event is generated, another such event is not
>     triggered until the sampled value falls below this threshold
>     and reaches mteTriggerThresholdFalling."
> 
> There is similar text for the mteTriggerThresholdFalling object.
> 
> As I read these two paragraphs, for a threshold event to be
> triggered twice, the sampled object's value must cross the 
> _other_ threshold first.  This suggests the sampled object's
> value cannot simply, for example:
> 
> -  cross the rising threshold and trigger an rising event;
> -  drop back into the deadband between the rising and falling
>    thresholds; then
> -  cross the rising threshold and trigger another rising event;
> 
> Was this intended?   

yes.

>                      Seems like deleting the requirement to
> cross the other threshold before re-triggering the same threshold
> would be more useful.

The reason for a "dead zone" like this is to provide some
hysteresis for control loops.  Until the value has gone to
the other side of the dead zone, it's all one incident.

> For example, it appears to me that as the MIB is currently 
> written, the behavior would be as follows.  Suppose the sampled
> MIB object measures the temperature of a machine room.  The
> mteTriggerThresholdRising object is set to 32 degrees C, and
> the mteTriggerThresholdFalling object is set to 22 degrees C.
> When the temperature rose above 32 degrees C, an mteTrigger
> ThresholdRisingEvent be triggered.  If the room temperature
> cooled to 25 degrees C (in the temperature deadband between
> 22 and 32 degrees C), then rose again to 32 degrees C, a
> second mteTriggerThresholdRisingEvent would *not* be triggered.
> Clearly, in this situation, not reporting a "too hot" condition 
> would be undersirable.

No, there was only one "too hot" event, not two.  Keep in mind that
the difference between the rising and falling objects is to prevent
oscillations, NOT to define two different events.

If the normal "noise level" of temperature measurements was one
degree, then a good value for the falling object might be 30.

> Was this behavior intended?

yes.

...
> What is the rationale for having the mteEventTable separate
> from the mteTriggerTable?   Or maybe the question is, why
> are the mteEventNotificationTable and mteEventSetTable 
> indexed the same as the mteTriggerTable, and not indexed the
> same as the mteEventTable?

I think it's because they don't necessarily exist in a 1:1
relationship.   Multiple triggers may reference the same
mteEventName.  It may make sense to subject mteEventEntries
to access control policies different than those appropriate
for triggers.

> As written, the mteEventNotificationTable and mteEventSetTable 
> are indexed by mteOwner and mteTriggerName.  This means the 
> "action items" are associated 1-to-1 with triggers, not with 
> events.  If the mteEventNotificationTable and mteEventSetTable 
> were indexed by mteOwner and mteEventName, and the mteTriggerTable 
> had references to the rows in the mteEventTable, then it would
> be possible to map many triggers to a single event.  But as it
> stands, it seems to me the mteEventActions object could have 
> been added to the mteTriggerTable, and the entire mteEventTable 
> could have been deleted.
...

This looks like a bug.  It does look like the indexes for
mteEventNotificationTable and mteEventSetTable should use
mteEventName.

...
> Notifications sent include the mteHotTrigger MIB object, which
> specifies the name of the trigger causing the notification.  If
> multiple owners have triggers with the same name, how can the
> management station tell which trigger caused the notification?

Good point.  Would it make more sense to just use mteTriggerName?

...
> Also, regarding notifications, the following pairs of MIB objects 
> specify lists of MIB objects to send in notifications:
> 
>    mteTriggerObjectsOwner/mteTriggerObjects
>    mteTriggerExistenceObjectsOwner/mteTriggerExistenceObjects
>    mteTriggerBooleanObjectsOwner/mteTriggerBooleanObjects
>    mteTriggerThresholdObjectsOwner/mteTriggerThresholdObjects
>    mteEventNotificationObjectsOwner/mteEventNotificationObjects
> 
> Given that mteTriggerTest can be set to '110', a single trigger
> could result in mteTriggerFired notifications with:
> 
> - the same mteHotTrigger, mteHotTargetName, mteHotContextName, 
>   mteHotOID, and mteHotValue; but
> - two different sets of "other" objects, as defined in the
>   mteObjectsTable.
> 
> This seems like it would be difficult for a management station 
> to parse.  What was the rationale behind this design decision?

I don't recall any discussion.

...
> For what it is worth, I noticed several typos.  The most significant 
> of these is at the bottom of page 1, where the text reads:
> 
>    "Please send comments to the Distributed Management 
>     Working Group, <[email-masked]>."
> 
> Unless requested, I will not bother the working group with the other typos.
...

Please forward these to the editor, [email-masked]

 -------------------------N-E-W---A-D-D-R-E-S-S--------------------------
 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: Alan Luchuk <[email-masked]>
Date: Tue, 14 Dec 1999 13:48:50 -0500 (EST)

Hello all,

The following E-mail is long, but I deleted some of the reply text 
(really I did!)

>Value[N] = AbsoluteValue(Sample[N] - Sample[N-1])

Adding this text to the next DISMAN-EVENT-MIB draft would be helpful.

>subtyped things are Integer32.

Only dealing with Integer32 things restricts the utility of the
DISMAN-EVENT-MIB.  I would suggest that in some way adding support
for Unsigned32 things would increase the utility of the DISMAN-
EVENT-MIB.

>the formulation of some of these objects.

I can align with this issue as it is. But it seems inconsistent
that the DISMAN-EVENT-MIB painstakingly indexes its tables with
owner strings so that VACM can be used to control table access, 
and then provides a way to reference objects with different owner
strings.  My preference would be to jettison these MIB objects:

     mteTriggerObjectsOwner

and allow the user access only to mteObjectsTable entries that
(s)he configured.  I am unclear on the utility of allowing one 
user to access mteObjectsTable entries created by another user.

>sysUpTime reset probably is.

Adding this text to the draft would be helpful.

>    2) advances at a rate similar to that of one's own

OK.  Makes sense.  But this still doesn't explain the function
of the mteTriggerDeltaTable.

>getting a value in the response would be the absent->present

OK.  Works for me.

>> Was this behavior intended?

OK.  I can align with this.  I believe this will have less utility
than letting the monitored MIB object drop into the deadband, then
re-cross the same threshold, and generating a second event of the
same type.

>Good point.  Would it make more sense to just use mteTriggerName?

Using the mteTriggerName instead of mteHotTrigger simplifies the
MIB a little.  But I believe it still doesn't resolve the notification
ambiguity if multiple mteOwners have the same mteTriggerName.  As
a solution, I suggest adding the mteOwner and mteTriggerName to the 
list of objects sent in notifications (and deleting the mteHotTrigger
from the list of objects sent in notifications.)

>I don't recall any discussion.

I can align with this.

My understanding of (most) commercial SNMP management stations is 
that they are decent about changing icon colors based upon the type 
of notification received, but they are not too good at parsing the 
notification contents and doing meaningful things (other than perhaps
printing the notification contents to a log file.)  Thus, having
notifications with different "payloads" makes it even more difficult
for SNMP management stations to do useful things with the payload.
My $0.02 worth.

>Please forward these to the editor, [email-masked]

Will do.

Regards,
--Alan
 
 -----------------------------------------------------------------------------
 Alan Luchuk       SNMP Research, Inc.                 Voice:  +1 865 573 1434
 Software Engineer 3001 Kimberlin Heights Road         FAX:    +1 865 573 9197
 [email-masked]   Knoxville, TN  37920-9716  U.S.A.   http://www.snmp.com/
 -----------------------------------------------------------------------------

   Please note that our telephone area code recently changed from 423 to 865. 
   Area 423 should countinue to work until it is phased out in April, 2000.