Conformance and Compliance

Conformance statements are a part of the SMI that let a MIB define, formally, which of its objects are actually required for an implementation to claim support for that MIB - as opposed to simply listing every possible object with no indication of which ones are essential versus optional.

This solves a real, practical problem: a large MIB might define dozens of objects, but a specific vendor's hardware might only sensibly support a subset of them (a feature that doesn't apply to that hardware, an optional capability they haven't implemented). Conformance statements make it possible to say precisely which subset is required, which is optional, and under what conditions - without needing a separate, informal document to explain it.

OBJECT-GROUP and NOTIFICATION-GROUP

Objects and notifications are first bundled into logically related groups:

ifGeneralGroup OBJECT-GROUP
    OBJECTS { ifIndex, ifDescr, ifType, ifMtu }
    STATUS  current
    DESCRIPTION
        "The generic managed objects applicable to all
        network interfaces."
    ::= { ifGroups 1 }

This just names a set of related objects as a unit - it doesn't yet say anything about whether that unit is required.

MODULE-COMPLIANCE

A separate MODULE-COMPLIANCE statement then defines an actual compliance level, referencing which groups are mandatory and which are optional (sometimes with conditions attached - "required if you support X"):

ifCompliance MODULE-COMPLIANCE
    STATUS  current
    DESCRIPTION "Compliance statement"
    MODULE
        MANDATORY-GROUPS { ifGeneralGroup, ifCounterDiscontinuityGroup }
    ::= { ifCompliances 1 }

An implementation that supports every mandatory group referenced by a given compliance statement can claim to meet that specific compliance level - a formal, checkable claim, not just a marketing statement.

Why this matters practically

For anyone actually consuming a MIB rather than writing one, conformance statements are mostly useful as documentation - they're a reliable way to tell, just by reading the MIB, which objects a spec-compliant device is actually expected to support versus which are genuinely optional extras. That's a meaningfully different question from "which objects does this specific vendor's specific device happen to implement," which conformance statements describe the intended baseline for, but can't guarantee in practice - real-world implementations don't always fully comply with what they claim to.

Where you'll actually run into this

Conformance sections show up near the bottom of most well-structured MIBs, generally after all the actual object and notification definitions. Tools that browse or summarize a MIB's structure sometimes surface this information directly - showing you, for instance, which of a table's columns are considered mandatory versus optional for compliance.