[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
The IF MIB is the MIb full of rule break (oops, I meant exceptions).
If a notification is allowed to be redefined to add extra variables,
then you could have ambiguous meanings. For example, I tack on
object instance x.y, and the updated definition would require
instance x.w. There would be no way to distingush the two notifications!
back to the orgiginal question...
If one wants to add on additional info to a notification, there
are two choices:
1) add extra varbines
2) define a new notification that has the additional info
There are costs with each approach. The first may confuse
poorly designed applications (or the poorly defined libraries
used by the applications). The second may result in events
to not be recognized. For example, say you really wanted to add
info to linkUp and linkDown, but you created new notifications,
and didn't send out linkUp or linkDown. Instead you sent out
linkUpV2 or linkDowV2. Well, you might break all of those apps
that were looking for linkUp and linkDown.
Life is full of difficult choices, which many do not have the
On Thu, 29 Jan 2004, C. M. Heard wrote:
> At 01:04 PM 1/29/2004, Sharon Chisholm wrote:
> > I've never viewed it as good practice. The problem is when that
> > the SMI cab be updated to add extra varbinds as happens with
> > linkUp and linkDown. So for the same varbind in some
> > implementations you see what is in the SMI and in others you see
> > random junk. Yeah, sure you get the OID of the variable but if
> > you are just looking at stuff in a dumb Notification viewer or
> > someone does not write their code terribly well, this can cause
> > confusion.
> If the SMI allowed extra varbinds to be added to notification
> definitions, then you would be right, but in fact it does not do so.
> See section 10.3 of RFC 2578. If such was done for the link up and
> link down traps then we broke out own rules.
/david t. perkins