2009/3/4 McGowen, Wendy <wen...@pivot3.com>:
>                      Do I have to include the index
> value in the OID for the vmName object in the trap

I believe so, yes.
>From RFC 2578:

8.1.  Mapping of the OBJECTS clause

   The OBJECTS clause, which need not be present, defines an ordered
   sequence of MIB object types.  One and only one object ==>instance<== for
   each occurrence of each object type must be present...

and

7.  Mapping of the OBJECT-TYPE macro
    :
   For leaf objects which are not columnar objects....
         .... instances of the object are identified by
   appending a sub-identifier of zero to the name of that object.
   Otherwise, the INDEX clause of the conceptual row object superior to
   a columnar object defines instance identification information.


So yes, the OID of an _instance_ of vmName should include an index value.

Although if this is a private implementation, solely used within your
own organisation, then you can take whatever shortcuts you feel appropriate
(as long as everyone knows what's expected).

I would suggest that you stick as closely as possible to the spirit of
the specs above.   For example, you're probably better off using a dummy
index value ('vmName.0', assuming simple integer indexes) in the trap
varbind OID rather than omitting it altogether ('vmName').


Alternatively, if definition of the MIB table isn't fixed in stone as yet,
then why not use vmName as the index?
So the trap would then be sent containing a varbind such as:

    vmStatus."rowName" = onFire(5)

and you're reported both the name and the status in one go!

Dave

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users

Reply via email to