Subject: Ref: Event MIB

From: aseem sethi <[email-masked]>
Date: Fri, 19 Nov 1999 14:14:32 +0800

Can someone please take a look at the following proposed
changes in the Event MIB, to see if they make sense, and 
whether we should modify the MIB.

Thanks,
Aseem

>>Hi,
>>
>>I have 2 coments on the Event MIB authored by B. Stewart, dated 
>>29th October 1999. 
>>
>>1. )
>>I would like propose to change the Indicies of the 2 tables 
>>'mteEventNotificationTable' and 'mteEventSetTable' to be
>>the same as the mteEventTable, i.e. "mteOwner", and
>>"mteEventName".
>>These tables currently have their indices as 'mteOwner' and 
>>'mteTriggerName'.  I have given below 2 reasons, on why
>>i feel that the indices should be changed.
>> 
>>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.
>>
>>A second point, which leads me to believe the change should
>>be made is because of the description in the mteEventNotification 
>>and mteEventSetTable :
>>
>>"  Information about a single event's notification. Entries automatically 
>>   exist in this this table for each mteTriggerEntry that has 'notification' 
>>   set in mteEventAction." 
>>
>>If you notice, there is no mteEventAction in the mteTriggerEntry 
>>table. The entry mteEventAction exists in the mteEventTable.
>>
>>
>>However, there is a workaround...the user defines 3 triggers. In 
>>each of the triggers which are watching the same OID, he only 
>>uses 1 test type for each of them, i.e. bool for the first trigger, 
>>existenceTest for the 2nd trigger, and Threshold Test for the third 
>>trigger. Then he creates 3 different set/notifications to 
>>take action on each of the 3 trigger firings. And all this is 
>>due to the fact that we can only have 1 set/notification row 
>>for each triggerRow entry. But I feel that this is not the right way
>>to do it, and we should change the indices.
>>
>>
>>2) 
>>The second problem -
>>For the mteNotificationTable, the MIB says that we should use the
>>entry mteEventNotification as the - ( from the MIB description )
>>   "OID from the NOTIFICATION-TYPE for the notification to use if 
>>     mteEventActions has 'notification's set." 
>>
>>There are 5 notification-types in the Event MIB, i.e mteTriggerFired,
>>mteTriggerFalling etc. I feel that at run time, the code is in a much
>>better position to figure out the reason for the firing of the trigger, and
>>we should use that as the Notification-Type or enterprise-specific-trap
>>when sending out a Notification rather than indexing into the 
>>mteNotificationTable
>>to find out the reason. This makes the user's job easier, and less prone to
>>errors, since the run time code, would know the exact reason for firing of
>>the trigger. 
>>
>>A second doubt, i had here was that the MIB does not preclude NOTIFICATION
>>-TYPES from other mibs like linkUp trap to be set here. We should
>>probably modify the description to say that only the NOTIFICATION-TYPES
>>from the event mib would be used for this purpose. Or, better still, as 
>>mentioned
>>in the earlier paragraph, we should let the run time code figure out the
>nature
>>of the trap by itself.
>>

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 19 Nov 1999 10:43:48 +0100

>>>>> aseem sethi writes:

aseem> Can someone please take a look at the following proposed
aseem> changes in the Event MIB, to see if they make sense, and
aseem> whether we should modify the MIB.

I argued several times in the past that the indexing structure of the
tables in the Event MIB is, let me say ugly. Bob did not want to
discuss this and so I finally gave up on it. Sure, this does not mean
I changed my mind and hence I agree with comment 1 below (although
this addresses only one of the problems I see).

Regarding comment 2, I am not sure I understand what is suggested.
Currently, the mteEventNotification variable defines which
NOTIFICATION-TYPE is generated. I think this is OK and we should not
add any restrictions as what can be the value of mteEventNotification.
Perhaps it also makes sense to use suitable defaults notification
types in case the value of mteEventNotification is {0 0} - but I am
not sure if this is what has been suggested.

/js

>>> 1. ) I would like propose to change the Indicies of the 2 tables
>>> 'mteEventNotificationTable' and 'mteEventSetTable' to be the same
>>> as the mteEventTable, i.e. "mteOwner", and "mteEventName".  These
>>> tables currently have their indices as 'mteOwner' and
>>> 'mteTriggerName'.  I have given below 2 reasons, on why i feel
>>> that the indices should be changed.
>>> 
>>> of this, if the user creates a mteTiggerentry row, and uses all
>>> the 3 tests ( i.e. boolean/threshold/Exist ) on the watched OID
>>> (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.
>>> 
>>> A second point, which leads me to believe the change should be
>>> made is because of the description in the mteEventNotification and
>>> mteEventSetTable :
>>> 
>>> " Information about a single event's notification. Entries
>>> automatically exist in this this table for each mteTriggerEntry
>>> that has 'notification' set in mteEventAction."
>>> 
>>> each of the triggers which are watching the same OID, he only uses
>>> 1 test type for each of them, i.e. bool for the first trigger,
>>> existenceTest for the 2nd trigger, and Threshold Test for the
>>> third trigger. Then he creates 3 different set/notifications to
>>> take action on each of the 3 trigger firings. And all this is due
>>> to the fact that we can only have 1 set/notification row for each
>>> triggerRow entry. But I feel that this is not the right way to do
>>> it, and we should change the indices.
>>> 
>>> 
>>> 2) 
>>> The second problem - For the mteNotificationTable, the MIB says
>>> that we should use the entry mteEventNotification as the - ( from
>>> the MIB description ) "OID from the NOTIFICATION-TYPE for the
>>> notification to use if mteEventActions has 'notification's set."
>>> 
>>> There are 5 notification-types in the Event MIB, i.e
>>> mteTriggerFired, mteTriggerFalling etc. I feel that at run time,
>>> the code is in a much better position to figure out the reason for
>>> the firing of the trigger, and we should use that as the
>>> Notification-Type or enterprise-specific-trap when sending out a
>>> Notification rather than indexing into the mteNotificationTable to
>>> find out the reason. This makes the user's job easier, and less
>>> prone to errors, since the run time code, would know the exact
>>> reason for firing of the trigger.
>>> 
>>> A second doubt, i had here was that the MIB does not preclude
>>> NOTIFICATION -TYPES from other mibs like linkUp trap to be set
>>> here. We should probably modify the description to say that only
>>> the NOTIFICATION-TYPES from the event mib would be used for this
>>> purpose. Or, better still, as mentioned in the earlier paragraph,
>>> we should let the run time code figure out the
>> nature
>>> of the trap by itself.
>>> 

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

---

From: Ramanathan Kavasseri <[email-masked]>
Date: Fri, 19 Nov 1999 02:00:09 -0800

Aseem,

my comments are marked with a [*]...

>>>and mteNotification tables to be the same as mteEventTable.

[*] The currentMIB design allows a user to set three different actions
for the three different types of tests - he'll need to create
3 mteTriggerEntries for it.

The current MIB design also permits the user to define a single action
for all three tests, and he can do this using a single mteTriggerEntry.

You're proposing another way to do the same thing. I don't
see why it's better, or where the existing design is broken...

If you're suggesting that users will tend to prefer one method
over the other, then I would guess it is an issue we should solicit
user feedback on. But until then, I don't see why we should stop
the draft-process and rewrite the MIB, if it is simply another
way to do the same thing. Perhaps I'm missing the point,
and someone else can explain to me what I'm missing...?

>>>table. The entry mteEventAction exists in the mteEventTable.

I'm still not convinced - the MIB is not broken, as you mention below.
I do not think this is expressly inefficient either, but that's just my opinion.
I'd be interested in seeing what others think.

Ram

---

From: Ramanathan Kavasseri <[email-masked]>
Date: Fri, 19 Nov 1999 02:23:03 -0800

>this addresses only one of the problems I see).

FYYI, Aseem brought this issue up before last call to Bob
and myself...

I view this as two different ways to do the same thing - I don't
see one being particularly better than the other. But if there's
consensus that the change would be better than the current draft,
we can see if Randy/Bert will allow a change? My reticence
to change at this stage (and also when the issue was raised earlier)
is that the new way didn't seem to be significantly better,
and because any such change-action may
delay early implementation of this MIB for little gain...

>not sure if this is what has been suggested.

I don't follow your suggestion about a "suitable default notification".
Can you elaborate?

Thanks,

Ram

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 19 Nov 1999 11:56:21 +0100

>>>>> Ramanathan Kavasseri writes:

Ramanathan> I view this as two different ways to do the same thing - I
Ramanathan> don't see one being particularly better than the
Ramanathan> other. But if there's consensus that the change would be
Ramanathan> better than the current draft, we can see if Randy/Bert
Ramanathan> will allow a change? My reticence to change at this stage
Ramanathan> (and also when the issue was raised earlier) is that the
Ramanathan> new way didn't seem to be significantly better, and
Ramanathan> because any such change-action may delay early
Ramanathan> implementation of this MIB for little gain.

It is not my goal to stop things from moving forward. As I said, I
personally gave up on this indexing issue and I let the last call
pass. Sure, I am not a fan of the current solution but the little
input we actually got from the WG makes me believe that nobody really
cares. Hence it is stupid to waste more time on it. I have no problem
to publish this as Proposed. If the MIB gets implemented and we get
more reports that people are confused, then we will have another
chance to reconsider the design when this MIB is expected to move
forward.

Ramanathan> I don't follow your suggestion about a "suitable default
Ramanathan> notification".  Can you elaborate?

I prefer not to do that since I was already guessing what the original
comment was trying to say. The mteEventNotification is fine as far as
I am concerned.

/js

---

From: aseem sethi <[email-masked]>
Date: Fri, 19 Nov 1999 16:46:43 +0800

Juergen, Ram,

Comments below....

>chance to reconsider the design when this MIB is expected to move

I am looking into the implementation of this MIB, and during the
prototype, i noticed that, this will be a big limitation if the indices are
kept the way they are.

What is the issue in changing the indices  ?

Is it just the re-writing the MIB. I can help re-write the MIB with the
proposed change.

I am new to this. Is the change based on consensus ?  Or, based on
practical implementations. Because i am implementing it right now,
and feel that if the change does occur later on, it would involve a 
much bigger change both in the agent and the management side.

Regards,
Aseem

080-2289931, Ext. 5008