Re: Event MIB object handling - Issue 2

Hi -

> From: "Benoit Claise" <[email protected]>
> To: "Dave Shield" <[email protected]>
> Cc: <[email protected]>
> Sent: Tuesday, July 19, 2005 2:54 AM
> Subject: Re: [Disman] Event MIB object handling - Issue 2
..
> >I've got another question relating to the Event-MIB, in particular
> >the handling of the objects to be added to a notification payload.
> >
> >Should the objects listed in the mteObjectsTable cover *all*
> >the varbinds for a particular notification, or just the "extra"
> >ones not included in the NOTIFICATION-TYPE definition (with those
> >being inserted automatically) ?
> >
> >
> There is not mention of in the draft. So If you set mteEventNotification
> to the OID of the linkDown, then I guess you will have to specify the {
> ifIndex, ifAdminStatus, ifOperStatus } yourself.

This seems reasonable to me.

> However, some more text would clarify the situation. The new text could
> take place in the mteEventNotification and/or "Operation" section.
>
> >I've been assuming that this table should list everything
> >(since the agent might not have access to the MIB definition).
> >In which case I'm a little puzzled about the order in which
> >the three mte{Trigger,TriggerXxx,EventNotification}Objects
> >tags are applied.
>
> >Naively, I'd expect that the mandatory notification objects
> >would be closely linked with the notification itself, and hence
> >be specified via the mteEventNotificationObjects tag, with the
> >two trigger tags being used to add extra non-standard varbinds.
> >Which would imply that the mteENObjects tag would have to be
> >applied first.  And there's a note in the archives from Mike
> >Daniele (<[email protected]> dated 02 Dec 1998)
> >commenting on draft #05 which seems to suggest the same thing.

This seems reasonable to me.

> >
> It makes sense to me.
> For everybody interest, see also
> http://www1.ietf.org/mail-archive/web/disman/current/msg00647.html for
> some clarifications.

It looks like the diagram (pages 4/5) isn't quite right.  It describes the
relationship between mteTriggerEntry and mteObjectsEntry
(via mteTriggerObjects and mteTriggerObjectsOwner) well enough,
but not the relationships for mteTriggerDeltaEntry,
mteTriggerExistenceEntry, mteTriggerBooleanEntry
and mteTriggerThresholdEntry to mteObjectsEntry.

> >  But draft #06 introduces text in the mteObjectsIndex
> >description which says:
> >
> >   Groups are placed in the notification in the order of the
> >   selections for overall trigger, trigger test, and event.
> >
> >and this seems to have remained the same through into RFC
> >2981 and the latest IDraft.  But I wasn't able to find an
> >explanation of why this particular order was used, or any
> >further discussion of this.
> >
> >Am I missing something obvious?

Putting the "overall trigger" stuff first seems common sense.
As for the others, I think it's just a case of "pick something" to
make it deterministic.

It would be good to be really explicit, saying something like:

For a given trigger, variable bindings specified in the
mteObjectsTable are appended in the following order:
   First, any identified by by the trigger's mteTriggerObjectsOwner
   and mteTriggerObjects, in order of mteObjectsIndex.
   Next, any identified by a mteTriggerExistenceObjectsOwner
   and mteTriggerExistenceObjects corresponding to the trigger,
   in order of mteObjectsIndex.
   Next, any identified by a  mteTriggerBooleanObjectsOwner and
   mteTriggerBooleanObjects  corresponding to the trigger,
   in order of mteObjectsIndex.
   Next, any identified by a  mteTriggerThresholdObjectsOwner
   and mteTriggerThresholdObjects  corresponding to the trigger,
   in order of mteObjectsIndex.

and so on, going through the event stuff.

> >
> As an editor, shall I simply modify the last sentence of the
> mteObjectsEntry from "Those associated with a trigger come first, then
> trigger test, then event." to "Those associated with an event come
> first, then a trigger , then trigger test."?
> Feedback?

There can be multiple tests, so I suppose we need to spell out that order.
Likewise if there are multiple ways to kick events tracing through this.

> I'm sure some old timers on the list will object is this is completely
> wrong :)
...

This old timer thinks this is more complicated that it probably needs to be,
particularly when this was supposed to be a simple alternative to scripting.

Randy