SNMP OIDs are laid out in a hierarchy forming unique addresses into a tree similar to the DNS hierarchy. Like many other forms of addressing, OIDs can be used in 2 forms: fully qualified and relative (sometimes called "relevant").
The fully qualified form starts from the root and moves outward to the individual value on a device. An example of a fully qualified address is:
.1.3.6.1.4.1.789.1.6.4.8.0
This OID could be rewritten in human readable form as:
.iso.org.dod.internet.private.enterprises.netapp.netapp1.raid.diskSummary.diskSpareCount.0
All fully qualified OIDs will begin with .iso.org.dod.internet.private represented numerically as .1.3.6.1.4. Almost all OIDs will then be followed by enterprises (.1) and a unique number for the vendor as assigned by the Internet Assigned Numbers Authority (IANA). In the example OID 789 represents the vendor ID for the Network Appliance Corporation (NetApp). Everything beyond the vendor ID is based on the vendors implementation and may vary between implementations. Please note the prefixing dot before iso. Similar to the trailing dot in DNS, properly qualified IODs begin with a dot representing the root.
The complete list of enterprise assignments can be found at the IANA website: http://www.iana.org/assignments/enterprise-numbers
The relative form of an OID, on the other hand, begins from the enterprises value and leaves all the implied addressing off. So we can use the relative form of the above OID as enterprises.netapp.netapp1.raid.diskSummary.diskSpareCount.0 or numerically as .1.789.1.6.4.8.0 .
A common form of writing OIDs is by the name of the MIB and a unique key defined within the MIB. For instance, we could rewrite the above OID into the condensed form NETWORK-APPLIANCE-MIB::diskSpareCount.0 . This condensed form follows the convention of MIB_Name::Unique_Key.instance. Some keys, while unique, can be represented by multiple instances of that key, and thus all OIDs end with an instance value. This is why you'll notice that most OIDs end with a .0 .