Manager needs to know the variables to query for something specific. The variables can be identified by OIDs or MIB objects names.
MIBs give Manager information such as:
- Human friendly symbolic names associated with the OIDs
- Types of values associated with particular OIDs
- Hints on variable access permissions that are implemented by the Agent
- SNMP tables indices structure and types
- References to other MIB objects (e.g. Notifications)
If MIB is available, Manager would be able to perform any SNMP operation knowing either symbolic name or OID of the Agent's variable it is interested in. All required details would be gathered from the MIB.
If MIB is not available, Manager would still have to figure out more or less of the additional details (some are listed above) so those can be hardcoded to the Manager.
For example, a GET operation could be performed having just an OID, however without MIB Manager may have troubles making response value looking human friendly.
Another example is a SET operation that requires Manager to properly encode value -- its type can be dynamically looked up at the MIB or hardcoded into the Manager for specific OIDs.
More complex scenarios involve dynamically building OIDs (for addressing SNMP table entries) using indices structure formally defined by the MIB.
The purpose of the GETNEXT/GETBULK queries is to let Manager be unaware of the exact set of OIDs provided by the Agent. So Manager could iterate over Agent's variables starting from a well known OID (or even its prefix). One of the uses of this feature is SNMP table retrieval.
MIBs are written in a subset of ASN.1 language. Unlike ASN.1, MIBs are very specific to SNMP domain.
To use MIBs with pysnmp you need to pass ASN.1 MIBs to the build-pysnmp-mib shell script (from pysnmp distribution) which would invoke smidump and other tools to convert ASN.1 MIBs into a collection of Python classes representing pysnmp-backed MIB objects.