Subject: Re: Ref: Event MIB

From: Randy Presuhn <[email-masked]>
Date: Thu, 16 Dec 1999 08:55:49 -0800 (PST)

Hi -

> Date: Thu, 16 Dec 1999 10:52:49 +0800
> To: Randy Presuhn <[email-masked]>, [email-masked]
> From: aseem sethi <[email-masked]>
> Subject: Re: Ref: Event MIB
> List-Id: IETF disman Working Group mailing list <[email-masked]>
> 
> 
> Hi,
> 
> To follow up on this thread, what is the decision on the 
> following change -
> 
> INDEXes for mteEventSetTable and mteEventNotificationTable.
>  to { mteOwner, IMPLIED mteEventName }.

The decision was in the message you attached.
No one has objected; the typo should be fixed.
We're just waiting for the editor to do the work.

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

> Thanks,
> Aseem
> 
> >
> >Hi -
> >
> >> Date: Fri, 19 Nov 1999 02:23:03 -0800
> >> To: Juergen Schoenwaelder <[email-masked]>, [email-masked]
> >> From: Ramanathan Kavasseri <[email-masked]>
> >> Subject: Re: Ref: Event MIB
> >> Cc: [email-masked]
> >> References: <4.1.19991119141301.00a19320@cbinmail>
> >>  <4.1.19991119141301.00a19320@cbinmail>
> >> List-Id: IETF disman Working Group mailing list <[email-masked]>
> >...
> >> FYYI, Aseem brought this issue up before last call to Bob
> >> and myself...
> >
> >Too bad he didn't do it on the WG mailing list and save us some time.  :-)
> >
> >> 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...
> >
> >What's there now looks like an editorial error in the names of
> >the INDEXes for mteEventSetTable and mteEventNotificationTable.
> >The asymetry is so glaring, I think the burden in this case
> >should be on those wanting to keep the { mteOwner, IMPLIED
> >mteTriggerName } indexing rather than the { mteOwner, IMPLIED
> >mteEventName }, particularly since the DESCRIPTIONs of the
> >mteTrigger*Event objects are all in terms of mteEventName.
> >
> > -------------------------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.
> > ------------------------------------------------------------------------
> >
> 
> 
> 080-2289931, Ext. 5008
> [email-masked]
> 
>

---

From: Ramanathan Kavasseri <[email-masked]>
Date: Thu, 16 Dec 1999 17:59:35 -0800

>We're just waiting for the editor to do the work.

Actually, I'd objected. I'm not sure it's a typo.
I don't see a problem with the proposed change, but 
my argument was that I don't see
how it's better than the existing index choices either.

The new indices let you configure different notifications to
be sent for each mteTriggerTest. With the old indices, you
needed to specify three mteTriggerEntries, each with
a single mteTriggerTest, if you wanted to send different
notifications (or perform different sets) for each test.

The reverse argument is that when you want the same notification
to be sent irrespective of the test being performed, you'll
need three mteEventNotificationEntries which send the same notification.

Further, if two mteTriggerNames want to send different notifications
but share event-entries, it is no longer possible, since the new
indices restrict the notifications to be based on the mteEventName,
not mteTriggerName. 

If an index change is required, I suggest
INDEX {mteOwner, IMPLIED mteTriggerName, mteEventNotificationTestType}

where mteEventNotificationTestType would be an INTEGER with
the values { existence(1), value(2), threshold(3) }.

Now you can specify the notifications for each test type,
but still be able to share an event name across multiple mteOwners
(who want different notifications or sets for the same event entry).
This way, for example, you'd be able to trigger a common "link up" event 
whether a physical link is up, or a subinterface is up, and set
the different objects for the same event.

Ram

---

From: aseem sethi <[email-masked]>
Date: Fri, 17 Dec 1999 11:04:49 +0800

Please see comments below...

>need three mteEventNotificationEntries which send the same notification.

This is not correct. With the change indicated above, you would not
have to define 3 mteEventNotificationEntries. You will need only 1
mteEventNotificationEntries, which is indexed on 
 {mteOwner, IMPLIED mteEventName}. These same 2 indices will appear
in all the 3 different test types for boolean. threshold and existence.
i.e. mteTriggerBooleanEventOwner, mteTriggerBooleanEvent
     mteTriggerExistenceEventOwner, mteTriggerName
     mteTriggerThresholdRisingEventOwner,  mteTriggerThresholdRisingEvent

So, there will be only 1 mteEventNotificationEntry and 1 mteEventSetTableEntry,
if you wanted the same notification for all the 3 test types, for a particular
trigger entry.

>indices restrict the notifications to be based on the mteEventName,

If 2 mteTriggerNames want to send different notifications or perform
different SETS.....why would they want to point to the same row in the 
mteEventTable, mteEventNotificationEntry  or mteEventSetTableEntry. 

They SHOULD point it to a new entry in the mteEventTable, since they
want different notification or different SETs to occur.

Regards,
Aseem

080-2289931, Ext. 5008

---

From: Ramanathan Kavasseri <[email-masked]>
Date: Thu, 16 Dec 1999 22:31:36 -0800

My comments are marked by [*] below.

>if you wanted the same notification for all the 3 test types, for a particular

[*] Ok. I see what you mean...

>mteEventTable, mteEventNotificationEntry  or mteEventSetTableEntry. 

[*]  A common event like "link up" may mean different things for
subinterfaces and for physical interfaces, for example...
In fact, a "link up" event can mean different things based on the
type of physical/subinterface - will a user want to specify one
linkup event for each type of physical/subinterface, or just
one common event for the hundreds of intreface/subinterface types
on his device? Network devices with 10000 interfaces are around
the corner - how we choose the indices makes a lot of difference
in the efficiency a user can derive from the MIB.
 
A user may want to use a common pool of events for a variety
of reasons it could be to configure fewer entries (ease of configuration
and maintenance, the same reason for changing the indices above),
to save memory or because using a common event entry seems logical..

[begin soap]
If we're going to change indices, we should
give the user the maximum flexibility we can...
The original indices allowed the use of the same events with different
notifications - when making the index change, we shouldn't undo
a carefully thought of feature...
[slip...ouch...end soap]

Ram

---

From: aseem sethi <[email-masked]>
Date: Fri, 17 Dec 1999 14:06:15 +0800

Ram,

Please see my comments....

>in the efficiency a user can derive from the MIB.

If the user wants to define the same event ( as you explain above )
he can do it...by pointing the indices in his various "test" tables of
all the triggers ( all 10000 of them ) to the same index of mteEventEntry.
i.e.  {mteOwner, IMPLIED mteEventName}..by setting his respective 
test-table entries (shown below )

mteTriggerBooleanEventOwner, mteTriggerBooleanEvent
mteTriggerExistenceEventOwner, mteTriggerName
mteTriggerThresholdRisingEventOwner,  mteTriggerThresholdRisingEvent

So, he only has to define 1 mteEventTable entry with one entry each
in the mteSet and mteNotification tables.

>a carefully thought of feature...

I am not in agreement with the above statement.....the mteEventTable 
is where you specify the action to be performed..i.e. Notification or SETs. 
You cannot point to the same mteEventTable, and then wish to have 2 different
Notifications sent.

Regards,
Aseem

080-2289931, Ext. 5008

---

From: Ramanathan Kavasseri <[email-masked]>
Date: Fri, 17 Dec 1999 09:24:38 -0800

At 02:06 PM 12/17/99 +0800, aseem sethi wrote:

[...snip...]

>in the mteSet and mteNotification tables.

[*] Yes, the user can share the same event with the proposed index
change: { mteOwner, IMPLIED mteEventName}. The problem
is that this forces the user to use only one mteEventNotification or mteEventSet
entry for an event. 

Look at the event as specifying the type of action(s) to be performed.
The exact object that is used for the set, or the exact notification OID
that's sent depends not on the mteEventEntry, but on:
a. the trigger test applied,
b. what's being tested.

That's why the original indices for the mteEvenNotification table let you set
a notification per mteTriggerTest. You spotted what could be a drawback,
in that you couldn't apply separate notifications per trigger test. All along,
the issue has been matching notifications OIDs (or OIDs for objects being
set) to the tests applied, not tightly coupling notifications OIDs to events.

>is where you specify the action to be performed..i.e. Notification or SETs. 

The mteEventTable indicates the type of action. It does NOT
mention the exact action, i.e. notification OID. Else we can simply roll
everything into the same table. There's advantage to decoupling
the eventTable from the mteEventNotificationTable in systems
where there are a large number of tests/notifications, and you'd like to
share events to conserve resources.

>You cannot point to the same mteEventTable, and then wish to have 2 different

Again, the Notification OIDs sent should be based on the test performed
and the object-instance being tested, not the event that triggered them.

Here's an example of an existence test for watching
routes coming up/going down in a routing table. One implementation may
choose to have a generic "Route Deleted" event. It may then define
two TriggerTests, one to test for static route deletions, and the other for
dynamic route deletions. Based on the route type, the notification sent
may contain different varbinds...

So I definitely see reason for having two notifications for different
tests that use the same mteEventEntry.

Ram