Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2)
obsoleted by
- rfc-1904 — Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)
Extracted elements (24)
The AGENT-CAPABILITIES macro specifies refinements or variations with respect to OBJECT-TYPE macros in MIB modules, NOT with respect to MODULE-COMPLIANCE macros in compliance statements. This distinction ensures that capabilities describe actual agent behavior relative to the MIB definition, not relative to a compliance floor.
The binding of AGENT-CAPABILITIES to sysObjectID may not always suffice to define all MIB objects an agent can provide access to, particularly where the agent dynamically learns of supported objects. In these cases, the snmpORID column of snmpORTable should be used in addition to sysObjectID.
The expansion of OBJECT-GROUP, MODULE-COMPLIANCE, and AGENT-CAPABILITIES macros conceptually happens during implementation and not during run-time, clarifying that these are static documentation constructs rather than dynamic protocol elements.
If a SYNTAX clause and WRITE-SYNTAX clause are both present in a VARIATION or OBJECT clause, the SYNTAX clause only applies when instances of the object are read, while WRITE-SYNTAX applies when instances are written, allowing different value ranges for reading versus writing.
The STATUS value 'deprecated' in MODULE-COMPLIANCE and AGENT-CAPABILITIES indicates an object is obsolete, but an implementor may wish to support it to foster interoperability with older implementations.
A MIN-ACCESS clause should not be present for objects whose access level is fixed by their syntax definition, including conceptual tables and rows, auxiliary objects, and objects with Counter32, Counter64, or certain textual convention syntaxes such as RowStatus.
If a SNMPv2 entity acting in an agent role claims compliance to a MIB module, it must implement each and every object within each conformance group listed in the MANDATORY-GROUPS clause. Returning noSuchObject for any object in a mandatory group means the entity is not a conformant implementation.
If any non-editorial change is made to any clause of an object group, compliance definition, or capabilities definition, then the OBJECT IDENTIFIER value associated with it must also be changed, along with its associated descriptor.
The ACCESS value 'write-only' in AGENT-CAPABILITIES VARIATION is provided solely for backward compatibility and shall not be used for newly-defined object types.
The CREATION-REQUIRES clause must not be present unless the object named in the VARIATION clause is a conceptual row (i.e., has a syntax resolving to a SEQUENCE containing columnar objects). All objects named in CREATION-REQUIRES that are columnar objects of that row must have an access level of 'read-create'.
The DESCRIPTION clause must be present for each use of the VARIATION clause in AGENT-CAPABILITIES, containing a textual description of the variant or refined implementation.
The DESCRIPTION clause of OBJECT-GROUP must be present and contains a textual definition of the group along with descriptions of relations to other groups. Generic compliance requirements should not be stated in this clause.
The INCLUDES clause must be present for each use of the SUPPORTS clause in AGENT-CAPABILITIES, naming each MIB group associated with the SUPPORTS clause which the agent claims to implement.
The MIN-ACCESS clause, if present, must not specify a greater level of access than is specified in the correspondent OBJECT-TYPE macro. An implementation is compliant if the access level it provides is greater or equal to the minimal level in MODULE-COMPLIANCE and less or equal to the maximal level in OBJECT-TYPE.
The OBJECTS clause of OBJECT-GROUP must be present and is used to name each object in the conformance group. Each named object must be defined in the same information module as the OBJECT-GROUP macro appears.
The PRODUCT-RELEASE clause of AGENT-CAPABILITIES must be present and contains a textual description of the product release which includes the agent.
The STATUS clause of OBJECT-GROUP must be present and indicates whether the definition is current or historic. Valid values are 'current' and 'obsolete'.
Under no circumstances shall a SNMPv2 entity return a value for objects which it does not implement — it must always return the appropriate exception or error (e.g., noSuchObject) as described in the protocol specification.
The AGENT-CAPABILITIES macro conveys the capabilities present in a SNMPv2 entity acting in an agent role. Its value is an OBJECT IDENTIFIER naming the sysObjectID or snmpORID for which the capabilities statement is valid, allowing management stations to optimize behavior when communicating with a particular agent.
The GROUP clause in MODULE-COMPLIANCE names each MIB group that is conditionally mandatory or unconditionally optional for compliance. A MIB group named in neither MANDATORY-GROUPS nor GROUP clause is unconditionally optional.
The MODULE-COMPLIANCE macro conveys a minimum set of requirements with respect to implementation of one or more MIB modules. A requirement on all 'standard' MIB modules is that a corresponding MODULE-COMPLIANCE specification is also defined, either in the same or a companion information module.
The OBJECT clause in MODULE-COMPLIANCE names MIB objects for which compliance has refined requirements. The named object must be present in one of the conformance groups named in the MANDATORY-GROUPS or GROUP clauses.
The OBJECT-GROUP macro defines a collection of related managed objects for conformance purposes. Each named object must be defined in the same information module and must have a MAX-ACCESS clause value of 'read-only', 'read-write', or 'read-create'.
Security issues are not discussed in this memo. RFC 1444 focuses solely on conformance notation and does not address authentication, authorization, or other security aspects of SNMPv2.