Subject: Re: [Disman] Event MIB object handling - Issue 2

From: Benoit Claise <[email-masked]>
Date: Tue, 19 Jul 2005 11:54:53 +0200

Dear all,

>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.
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-masked]> dated 02 Dec 1998)
>commenting on draft #05 which seems to suggest the same thing.
>  
>
It makes sense to me.
For everybody interest, see also 
http://www1.ietf.org/mail-archive/web/disman/current/msg00647.html for 
some clarifications.

>  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?
>  
>
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?
I'm sure some old timers on the list will object is this is completely 
wrong :)

Regards, Benoit.

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 19 Jul 2005 09:03:18 -0700

>>>>> On Tue, 19 Jul 2005 11:54:53 +0200, Benoit Claise <[email-masked]> said:

Benoit> As an editor, shall I simply modify the last sentence of the
Benoit> mteObjectsEntry from "Those associated with a trigger come
Benoit> first, then trigger test, then event." to "Those associated
Benoit> with an event come first, then a trigger , then trigger
Benoit> test."?  Feedback?  I'm sure some old timers on the list will
Benoit> object is this is completely wrong :)

I agree with Dave's analysis that the existing functionality is broken
and needs to be fixed.  Thus I think this change is required.

However, since it's likely a major change in functionality it will
have to recycle at proposed?  However, I think it's worth doing in
this case because the alternative is letting it go forward in a broken
state that renders half the purpose of the MIB unusable in the way it
should be used.

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 26 Jul 2005 19:09:21 -0700

Hi -

> From: "Benoit Claise" <[email-masked]>
> To: "Dave Shield" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, July 19, 2005 2:54 AM
> Subject: Re: [Disman] Event MIB object handling - Issue 2
..
> ifIndex, ifAdminStatus, ifOperStatus } yourself.

This seems reasonable to me.

> >commenting on draft #05 which seems to suggest the same thing.

This seems reasonable to me.

> http://www1.ietf.org/mail-archive/web/disman/current/msg00647.html for

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.

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

> first, then a trigger , then trigger test."?

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

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 26 Jul 2005 21:20:25 -0700

Hi -

> From: "Wes Hardaker" <[email-masked]>
> To: "Benoit Claise" <[email-masked]>
> Cc: <[email-masked]>; "Dave Shield" <[email-masked]>
> Sent: Tuesday, July 19, 2005 9:03 AM
...

Where there is contradictory text, and we reconcile it so that one of the
interpretations still holds true without causing interoperability problems
for deployed implementations, in my opinion it's not a major change.

Where there is ambiguous text, and we remove the ambiguities
without causing interoperability problems for deployed implementations,
in my opinion it's not a major change.

It looks like the motivation was to make things more deterministic, but
that the added text was not sufficiently clear / precise / consistent.
Let's get it right, and then decide whether the fix requires cycling.

Randy