Subject: question about the event mib

From: Bram van der Waaij <[email-masked]>
Date: Fri, 16 Oct 1998 14:10:03 +0200

Hi,

In the past weeks our group has been studying the event mib (draft 5).
We found a number of issues that were not entirely clear to us.
Perhaps someone on the mailinglist can help us.

1) The semantics of the wildcarding mechanism are not completely clear. 
   Trigger table: 
      When does a trigger based on a group of wildcarded
      booleans fire? When all booleans are true, when at 
      least one of them is true, ...? 
   Event table: 
      What are the semantics of a wildcarded group of objects to 
      be set? What are the semantics of a wildcarded group of 
      contexts? 

2) Is the eventMIBNotificationObjectss with double s a typo? 
   What is the use of this object? 

3) The notifications defined in the event mib contain 'alarm' as 
   part of their names (mteTriggerSenseAlarm, mteTriggerFallingAlarm, 
   etc). Is this due to the fact that the event MIB evolved from RMON, 
   and should the term 'alarm' therefore be renamed into 'Trigger'?
   Or is a new concept of alarm introduced (if this is the case, the 
   term alarm should be properly introduced in the document). 
   
4) Why are the only global failure counters and not a failure 
   indication for each event individual?

5) There is a relation defined between Trigger and Object, suggesting 
   that a set of objects should be added to a notification resulting 
   from firing of the trigger. This seems superflous, since triggers 
   aren't supposed to generate notifications directly. Events generate 
   notifications, and the relation from event to objects is appropriate 
   and present in the event mib specification. 
   
6) The description of mteTriggerEvent says to invoke the event when
   the trigger fires. It is not clear how to address this event, 
   probably using the name specified in the mteEventName object.

-- 
Bram
         _          Bram van der Waaij           tel.: +31 53 4894664
    ----(_)----     <[email-masked]>      fax : +31 53 4894524
  ___  | | |                                    room : INF-4032
 /   \ | | |        Centre for Telematics and Information Technology
|      | | |        University of Twente
 \___/ | | |        P.O. Box 217   7500 AE Enschede  The Netherlands

---

From: Bob Stewart <[email-masked]>
Date: Fri, 30 Oct 1998 09:02:17 -0500

>Perhaps someone on the mailinglist can help us.

Here I am to go through these.  Thanks for the detailed review.  This MIB
is one of the key products of the DisMan working group.

>      be set? What are the semantics of a wildcarded group of 

I see the confusion.

Each instance of the wildcarded object is effectively a separate trigger,
in no way dependent on the other instances.  Think of the wildcard as the
part that you leave off when starting a GetNext.  You do the GetNext with
that left off and get an instance, check it for the trigger condition and
if it fires, trigger the event for that instance.  Then do a GetNext from
there for the next one and so on.

This should make the Set operation more clear.  An event is triggered for a
particular instance, and that instance is the one that fills in the Set
wildcard.

I'll see what I can do with the DESCRIPTIONs to make this more clear.

>   What is the use of this object? 

Oops.  That was a cut & paste edit that didn't get finished properly.  It
should have only one s on the end and was supposed to be used as the branch
for the notification objects.

I'll fix it.

>   term alarm should be properly introduced in the document). 

Looks vestigial to me.  I'll remove it in favor of more descriptive names
for notifications.

>   indication for each event individual?

The idea is to keep the counter burden minimal.  The explanation is in the
prose at the front of the MIB:

"Error handling is by notification, which at first thought violates the
principle that notifications may be lost or become a crippling burden, but
the intent is that such error notifications be enabled only for the
diagnosis of problems indicated by error counters and if the notifications
are being lost they be directed to the log as described in the Notification
Log MIB [19]."

My assumption is that once triggers and events are configured errors should
be few and far between.  A burst in the global counters probably indicates
a new configuration or a changed assumption.  You'd turn on the
notifications to find out the details then turn them off once you fix the
problem.  Given this approach lost notifications aren't likely to be a
problem, but having a general notification log covers that, too.

>   and present in the event mib specification. 

The idea here is that different triggers could cause the same event and
each trigger could have a different set of objects necessary to
apppropriately illuminate that event so the notifications can be distinguished.

>   probably using the name specified in the mteEventName object.

Would it help if I made it say "The name of the event to invoke"?

Thanks again for the detailed questions.  The MIB has been in the works for
a long time but hasn't gotten the review it should.  You're helping to
remedy that.

	Bob