An "information module" is an ASN.1 module defining information
relating to network management.
The SMI describes how to use a subset of ASN.1 to define an
information module. Further, additional restrictions are placed on
"standard" information modules. It is strongly recommended that
"enterprise-specific" information modules also adhere to these
restrictions.
Typically, there are three kinds of information modules:
MIB modules, which contain definitions of inter-related managed
objects, make use of the OBJECT-TYPE and NOTIFICATION-TYPE macros;
compliance statements for MIB modules, which make use of the
MODULE-COMPLIANCE and OBJECT-GROUP macros [2]; and,
capability statements for agent implementations which make use of
the AGENT-CAPABILITIES macros [2].
This classification scheme does not imply a rigid taxonomy. For
example, a "standard" information module will normally include
definitions of managed objects and a compliance statement.
Similarly, an "enterprise-specific" information module might include
definitions of managed objects and a capability statement. Of
course, a "standard" information module may not contain capability
statements.
The constructs of ASN.1 allowed in SNMPv2 information modules
include: the IMPORTS clause, value definitions for OBJECT
IDENTIFIERs, type definitions for SEQUENCEs (with restrictions),
ASN.1 type assignments of the restricted ASN.1 types allowed in
SNMPv2, and instances of ASN.1 macros defined in this document and in
other documents [2, 3] of the SNMPv2 framework. Additional ASN.1
macros may not be defined in SNMPv2 information modules.
The names of all standard information modules must be unique (but
different versions of the same information module should have the
same name). Developers of enterprise information modules are
encouraged to choose names for their information modules that will
have a low probability of colliding with standard or other enterprise
information modules. An information module may not use the ASN.1
construct of placing an object identifier value between the module
name and the "DEFINITIONS" keyword.
All information modules start with exactly one invocation of the
MODULE-IDENTITY macro, which provides contact information as well as
revision history to distinguish between versions of the same
information module. This invocation must appear immediately after
any IMPORTs statements.