Question about additional fields in traps.

[Frank Fock]

Hi Paresh,

Sending additional objects with dummy OIDs
is not a good idea:

* How should the management software developers
know about the additional object?
* Who tells them that the object with the dummy
OID is an error string?
* Who pays the management software developers for
searching MIB Depot and other Internet resources
for the dummy OID?

As a conclusion, it is *required* that the additional
objects are described in a MIB module (which does not
necessarily need to be the same as where the
notification has been defined).

In your case, I would recommend to write a MIB module
where you define an OBJECT-TYPE named, for example,
"myCompanyErrorDescr" with MAX-ACCESS
"accessible-for-notify" and syntax "DisplayString".

Best regards,
Frank


Paresh Borkar wrote:
> Hi,
> 
> RFC 2578 mentions that the OBJECTS clause defines an ordered sequence of
> MIB object types for a NOTIFICATION-TYPE. It also mentions that an agent
> is allowed to append as many additional objects as it considers useful
> to the end of the notification (i.e. objects defined by the OBJECTS
> clause).
> My question is regarding these additional objects. Do they have to come
> from the MIB only? For example is it possible for an agent to send an
> error string as an additional object along with the trap?
> 
> The generate method in the NotificationOriginator class takes "Vbx *"
> i.e. pointer to the variable bindings array. And every variable binding
> has to have an OID and value. Thus implying that the value is picked
> from some place in the MIB. For example in my case I want to send an
> error message (not in the MIB) with the trap, hence do I need to set a
> dummy oid along with the message in the variable binding?
> 
> Thanks,
> Paresh.
> 
>