Index in MIB table

Question

I want to use a hierarchical table structure within a MIB for an SNMPv2-Trap similar to the one described within this answer https://stackoverflow.com/a/2510340/346899

However I do not really get the concept of the INDEX for entries in a MIB table. For instance in following excerpt of the quoted answer a childIndex for entries in the child table is used:

childEntry OBJECT-TYPE
SYNTAX       ChildEntry
MAX-ACCESS   not-accessible
STATUS       current
DESCRIPTION  "Entry in Child table"
INDEX        { parentIndex,
               childIndex }
::= { childTable 1 }

However my Trap receiver (by iReasoning) also works if I do not specify a special childIndex within the used Trap-MIB it uses. What is the purpose of the index then?

Answer 1

This index is only used for table retrieval, where you use GET NEXT or GET BULK messages to query all objects in the table. Only based on the INDEX information, you can tell how the received objects should be formatted as a proper table.

"However my Trap receiver (by iReasoning) also works if I do not specify a special childIndex within the used Trap-MIB it uses."

Edited: For a trap receiver, it depends on the MIB documents to understand how to interpret the incoming notifications. Luckily in almost every standard MIB documents, for NOTIFICATION-TYPE objects, the definitions are clear. For example, in RFC 4898

https://www.rfc-editor.org/rfc/rfc4898

tcpEStatsEstablishNotification NOTIFICATION-TYPE
   OBJECTS     {
                 tcpEStatsConnectIndex
               }
   STATUS      current
   DESCRIPTION
       "The indicated connection has been accepted
       (or alternatively entered the established state)."
   ::= { tcpEStatsNotifications 1 }

The OBJECTS section shows how to interpret the objects.

Thus, there is indeed no need for the trap receiver to go back and check whether you have incorrectly define the tables (at the beginning of this MIB).

Your change to the table will only be a problem, when this MIB document is used to interpret GET NEXT or GET BULK result of the table, because at that time the utility will find out the some index items are missing.