Download White Paper				12 of 23

So every MIB file needs to describe the entire OID tree?

Fortunately, no. The upper levels of the OID tree - the parts that define the general OID structure - are defined in a series of standard reference MIB files called RFCs.

(The initials stand for Request for Comment. The RFCs that define SNMP OIDs are part of a larger group of RFC documents that define the Internet as a whole.)

The RFC MIB defines a basic dictionary of terms that vendors use to write their own equipment-specific MIBs. So a vendor-created MIB doesn't have to define the entire OID tree. The vendor's MIB file only has to define the unique OIDs that describe the vendor's equipment.

At the beginning of every MIB file is an IMPORTS line that calls out the terms used in the MIB and the RFC MIB that defines those terms.

Let's take another look at the very beginning of the DPS Telecom MIB:

DPS-MIB-V38 DEFINITIONS ::= BEGIN
IMPORTS
      DisplayString
            FROM RFC1213-MIB
      OBJECT-TYPE
            FROM RFC-1212
      enterprises
            FROM RFC1155-SMI;

From this IMPORTS line we can read that the DPS MIB is written using three terms defined in other MIBs - DisplayString, OBJECT-TYPE and enterprises - and these terms are defined in the RFC MIBs listed.

All MIB files are written as extensions of the master RFCs. For this reason, you'll sometimes hear people say that there's only one MIB for all SNMP devices, and that individual MIB files are merely subsections of the unified Management Information Base.

That may be true in theory, but in real life, you only need to worry about the equipment you use, the MIBs that support your equipment, and the RFCs that support those MIBs.

		Download White Paper				12 of 23