Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)
obsoleted by
- rfc-2580 — Conformance Statements for SMIv2
obsoletes
- rfc-1444 — Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2)
Extracted elements (25)
AGENT-CAPABILITIES specifies refinements and variations relative to OBJECT-TYPE and NOTIFICATION-TYPE macros in MIB modules, explicitly not relative to MODULE-COMPLIANCE macros. This distinction separates what the standard requires from what a particular agent actually delivers.
AGENT-CAPABILITIES values are bound to instances of sysORID, enabling management stations to build a database of capabilities and automatically optimize their behavior when communicating with a specific agent by retrieving its sysORID values at runtime.
The 'deprecated' STATUS value is distinguished from 'obsolete' to signal that an implementor may wish to support a group solely to foster interoperability with older implementations, even though the definition is considered historic.
The VARIATION concept is intended for generic implementation restrictions. If a variation depends on the runtime values of other objects, that dependency should be noted in the DESCRIPTION clause rather than encoded structurally, since the macro cannot express value-dependent branching.
When SYNTAX and WRITE-SYNTAX clauses both appear in the same OBJECT or VARIATION clause, the SYNTAX clause applies only during read operations; WRITE-SYNTAX governs write operations exclusively. Implementors must apply the correct refinement based on operation type.
A MIN-ACCESS clause should not be present for objects whose access level is fixed by their syntax: conceptual tables and rows, auxiliary objects, Counter32, Counter64, and certain textual conventions.
A SNMPv2 entity acting in an agent role must never return a value for objects it does not implement; it must always return the appropriate exception or error (e.g., noSuchObject). Returning a fabricated value for an unimplemented object is prohibited.
All objects named in CREATION-REQUIRES that are columnar objects of the relevant conceptual row must have an access level of 'read-create'.
Every object defined in an information module with a MAX-ACCESS clause other than 'not-accessible' must be contained in at least one OBJECT-GROUP. This prevents new objects from being inadvertently omitted from conformance groups.
Every standard MIB module must have a corresponding MODULE-COMPLIANCE specification, defined either in the same information module or in a companion information module.
If a SNMPv2 agent claims compliance to a MIB module, it must implement every object and notification in each conformance group listed in the MODULE-COMPLIANCE MANDATORY-GROUPS clause. Returning noSuchObject for any mandatory object in any MIB view means the implementation is non-conformant.
If any non-editorial change is made to any clause of an object group, the OBJECT IDENTIFIER value and descriptor associated with that group must be changed. The same rule applies identically to compliance definitions (Section 7.2) and capabilities definitions (Section 7.3).
Objects named in an OBJECT-GROUP's OBJECTS clause must be defined in the same information module as the OBJECT-GROUP macro and must have a MAX-ACCESS of 'accessible-for-notify', 'read-only', 'read-write', or 'read-create'.
The ACCESS value 'write-only' in AGENT-CAPABILITIES VARIATION shall not be used for newly defined object types; it is provided solely for backward compatibility with older MIB definitions.
The MIN-ACCESS clause, when present, must not specify a greater level of access than is specified in the corresponding OBJECT-TYPE macro's MAX-ACCESS clause. An implementation is compliant if its access level is between MIN-ACCESS and MAX-ACCESS (inclusive).
The ACCESS clause within a VARIATION names the agent-specific access level, which may be lower than the object's defined maximum. For notifications, only 'not-implemented' is applicable; 'write-only' is included solely for backward compatibility and must not be used for newly defined object types.
The AGENT-CAPABILITIES macro conveys the precise capabilities of a SNMPv2 agent with respect to one or more MIB modules. Its value is an OBJECT IDENTIFIER bound to an instance of sysORID, allowing management stations to discover and optimize behavior for specific agents.
The CREATION-REQUIRES clause in a VARIATION names the columnar objects to which values must be explicitly assigned (via a Set operation) before the agent will allow a row's status column to be set to 'active'. All named columnar objects in this clause must have read-create access.
The GROUP clause in MODULE-COMPLIANCE names object or notification groups that are conditionally mandatory or unconditionally optional. A group in a GROUP clause must be absent from MANDATORY-GROUPS; the DESCRIPTION specifies conditions under which it becomes mandatory.
The MODULE-COMPLIANCE macro conveys a minimum set of implementation requirements for one or more MIB modules. It uses MANDATORY-GROUPS for unconditionally required groups, GROUP for conditionally mandatory or optional groups, and OBJECT for per-object refinements.
The NOTIFICATION-GROUP macro defines a named collection of related notifications for conformance purposes. Each group is identified by an OBJECT IDENTIFIER and contains notifications defined in the same information module.
The OBJECT clause in MODULE-COMPLIANCE refines compliance requirements for individual MIB objects and may include SYNTAX (read-path restriction), WRITE-SYNTAX (write-path restriction), and MIN-ACCESS (minimum required access level) subclauses.
The OBJECT-GROUP macro defines a named collection of related managed objects for conformance purposes. Each group is identified by an OBJECT IDENTIFIER and groups objects with compatible MAX-ACCESS values for use in MODULE-COMPLIANCE statements.
The VARIATION clause in AGENT-CAPABILITIES names each object or notification that the agent implements in a variant or restricted fashion. It supports SYNTAX, WRITE-SYNTAX, ACCESS, CREATION-REQUIRES, and DEFVAL subclauses to precisely document deviations from the MIB definition.
RFC 1904 explicitly states that security issues are not discussed in this memo. Conformance statement macros (OBJECT-GROUP, NOTIFICATION-GROUP, MODULE-COMPLIANCE, AGENT-CAPABILITIES) are purely definitional constructs with no direct security implications addressed in this document.