SMI

The SMI (Structure of Management Information) is the set of rules that define how a MIB is allowed to be written - the formal grammar and base data types every MIB has to follow. If a MIB is a document describing a specific set of manageable data, the SMI is the rulebook that document has to comply with in order to be a valid MIB at all.

It's built on ASN.1 (Abstract Syntax Notation One), a general-purpose data description language originally developed for telecommunications, with SNMP-specific extensions and restrictions layered on top - the SMI is essentially "the specific, constrained subset of ASN.1 that's usable for defining MIBs," not a wholly separate language of its own.

SMIv1 vs. SMIv2

Like SNMP itself, the SMI has gone through revisions. SMIv1 (RFC 1155) accompanied SNMPv1; SMIv2 (RFC 2578) came with SNMPv2 and added a number of genuinely useful capabilities:

• Counter64, for 64-bit counters (see textual conventions) - important for accurately tracking traffic on high-speed interfaces without wrapping constantly.
• A more expressive, better-defined mechanism for textual conventions generally.
• OBJECT-GROUP, NOTIFICATION-GROUP, and MODULE-COMPLIANCE - the machinery behind conformance and compliance statements.

Almost every actively-maintained MIB you'll encounter today is written to SMIv2. SMIv1-only MIBs still exist, mostly for very old equipment, but are increasingly rare.

What the SMI actually defines

Concretely, the SMI specifies the base types available for use in a MIB (INTEGER, OCTET STRING, OBJECT IDENTIFIER, and a handful of SNMP-specific application types like Counter32 and Gauge32), the macros used to define things (OBJECT-TYPE, NOTIFICATION-TYPE, and others), and the rules for how OIDs get assigned relative to their parent in the tree.

Why this matters if you've never written a MIB yourself

For most people, the SMI is invisible - you interact with the objects a MIB defines, not the grammar rules that made those definitions valid in the first place. It becomes directly relevant in exactly one common situation: a MIB failing to parse. A MIB parser is, among other things, checking SMI compliance, and a MIB that violates the SMI's rules (using an undefined type, malformed syntax, a macro used incorrectly) will fail to load with an error pointing at the specific problem. See MIB loading errors for what that actually looks like in practice.