Subject: Event MIB implementation questions

From: Alan Luchuk <[email-masked]>
Date: Fri, 3 Dec 1999 13:22:40 -0500 (EST)

Hello all,

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.

I'm pretty excited about the DISMAN-EVENT-MIB because I believe 
it will be a useful addition to the network manager's toolbox.  
Overall, I believe it is implementable, and alot of it appears
pretty well thought-out.  But there are issues either that I'm 
trying to understand the operation of, or I'm trying to under-
stand the justification of.  Please forgive my ignorance;  I'm 
hoping those of you that have been actively involved with the 
design of the DISMAN-EVENT-MIB will help me understand.

That said, I'll launch into the things I'm having trouble with.

--------

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?

--------

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

Could someone help me understand this issue better?

--------

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.

--------

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.

--------

What is the purpose of mteTriggerThresholdValue?

--------

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?   Seems like deleting the requirement to
cross the other threshold before re-triggering the same threshold
would be more useful.

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.

Was this behavior intended?

--------

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?

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.

Please help me understand what I missing.

--------

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?

--------

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?

--------

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.

--------

Sorry to load everybody up with questions.  But after 3 readings
of the draft-ietf-disman-event-mib-08.txt, I really would like to 
understand these issues.

Thanks very much for your assistance!

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 423 to 865.
   Area 423 should countinue to work until it is phased out in April, 2000.

---

From: aseem sethi <[email-masked]>
Date: Mon, 06 Dec 1999 10:37:10 +0800

Alan,

Some comments below -

>What is the purpose of mteTriggerThresholdValue?

This has been discussed with the author, and he will remove it
in the next print.

>Was this behavior intended?

Yes. This is also how i understood it after discussing with the
original author. The value has to go below the mteTriggerThresholdFalling 
after going above the mteTriggerThresholdRising, for the trigger to be
fired.

>Please help me understand what I missing.

I also had this same problem when implementing this. 
With the indices of Set and Notification tables the way they are - 
we can only have one row in 'mteEventNotificationTable' and 
mteEventSetTable', for each row in the mteTriggerTable. Becuase 
of this, if the user creates a mteTiggerentry row, and uses all the 
3 tests ( i.e. boolean/threshold/Exist ) on the watched OID 
given in mteTriggerValueID, he can only have 1 mteEventAction 
(either Set or a Notification ) for all the 3 tests. I am sure that 
the user would want to dictate 3 different kinds of mteEventAction 
for 3 different types of trigger firing reasons. ( ie. bool/exist/thresh). 
This would only be possible, if we change the indices of the mteSet 
and mteNotification tables to be the same as mteEventTable.

There was one other person who thought this should be changed 
to way you suugest - i.e. change the indices to be the same as that
of the mteEventTable.

If there are a lot of folks who are having issues then maybe the author 
could change this.

Regards,
Aseem

080-2289931, Ext. 5008
[email-masked]