The INDEX clause, which may be present only if that object type corresponds to a conceptual row, defines instance identification information for that object type. (Historically, each MIB definition contained a section entitled "Identification of OBJECT instances for use with the SNMP". By using the INDEX clause, this section need no longer occur as this clause concisely captures the precise semantics needed for instance identification.)
If the INDEX clause is not present, and the object type corresponds to a non-columnar object, then instances of the object are identified by appending a sub-identifier of zero to the name of that object. Further, note that if the MIB module does not contain a textual description of how instance identification information is derived for columnar objects, then the INDEX clause must be present.
To define the instance identification information, determine which object value(s) will unambiguously distinguish a conceptual row. The syntax of those objects indicate how to form the instance-identifier:
Note that if an "indextype" value is present (e.g., INTEGER rather than ifIndex), then a DESCRIPTION clause must be present; the text contained therein indicates the semantics of the "indextype" value.
By way of example, in the context of MIB-II [7], the following INDEX clauses might be present:
objects under INDEX clause ----------------- ------------ ifEntry { ifIndex } atEntry { atNetIfIndex, atNetAddress } ipAddrEntry { ipAdEntAddr } ipRouteEntry { ipRouteDest } ipNetToMediaEntry { ipNetToMediaIfIndex, ipNetToMediaNetAddress } tcpConnEntry { tcpConnLocalAddress, tcpConnLocalPort, tcpConnRemoteAddress, tcpConnRemotePort } udpEntry { udpLocalAddress, udpLocalPort } egpNeighEntry { egpNeighAddr }