MODULE-COMPLIANCE statements, in conjunction with the MAX-ACCESS (or PIB-ACCESS) clause of OBJECT-TYPEs, allow module authors to define the conditions that an implementor of the module must meet in order to claim compliance to the specification. Among the types of things that can be specified are groups that must be implemented, minimum access levels that an agent must support for different objects, as well as minimum subsets of the range or size of values those objects must support.
MODULE-COMPLIANCE Statements are not supported by SMIv1.
To create a MODULE-COMPLIANCE in MIB Smithy, you must first have created or loaded one or more MIB Modules within the project. Use the Project Tree to select the module in which to create the record -or- one of its records that is the desired parent for the new record. Then, you can either: use Insert → Compliance from the main menu; click on the Add Compliance button in the Toolbar; or right-click on the desired parent within the Project Tree and use its New → Compliance menu. MIB Smithy will then create the record with a unique, automatically assigned name and subidentifier, and open a page in the Workspace Panel where you can edit its name and other properties.
The Compliance Name, Status and OID Value properties are all available to be edited from the General Page of the Compliance Workspace, which is pictured below.
Figure - MODULE-COMPLIANCE Workspace, General Page
Each MODULE-COMPLIANCE statement must be assigned a name. MIB Smithy will automatically assign a name that is unique within the project; however, a user should assign a more suitable name that roughly describes the nature of the statement, such as the module and level of conformance to which it pertains. The name should be chosen so-as to minimize to the possibility of other OIDs being given the same name for compatibility with tools that do not provide mechanisms for working around name collision.
A valid compliance name begins with a lowercase letter and may contain zero or more additional letters or numbers. Hyphens are allowed in SMIv1 provided the name does not end in a hyphen and no two hyphens are adjacent. Hyphens are not allowed in SMIv2 except by way of conversion from SMIv1, which does not have a MODULE-COMPLIANCE equivalent.
This property is unconditionally required.
This property indicates the status of the compliance statement with regards to its historic nature. It may take one of three values: current
, deprecated
or obsolete
, indicating that the statement is current and valid and may continue to be used as a target for implementing a conformant agent, that it may still be used but may soon become obsolete in the future, or that the statement is now obsolete and should not be considered a valid level of conformance. Note that a conformance statement's status does not affect the status of any groups or other records it references; however, a conformance statement should not in general have a more current status than any such referenced records.
This property is unconditionally required.
This property registers a unique OBJECT IDENTIFIER value that may be used to identify the level of conformance. It is not in general used by SNMP entities, but may be used by MIB compilers and similar tools.
This property is unconditionally required.
This property is unconditionally required.
Figure - MODULE-COMPLIANCE Workspace, Description Page
The MODULE-COMPLIANCE's Reference property may be used to provide the reader or implementor a reference to additional supporting documentation that may be of assistance in interpreting the rules or basis for the type. MIB Smithy will apply the same formatting rules to this property as it does for other similar quoted-text fields such as descriptions.
This property is optional.
The Modules property is used to add pseudo-records referencing each of the modules required by a MODULE-COMPLIANCE statement. A Conformance Module record is needed to list any required or supported groups and define any variations on objects or notifications.
This property is required. A MODULE-COMPLIANCE statement must reference at least one module (which may be the same module in which the statement is defined).
Figure - MODULE-COMPLIANCE Workspace, Modules Page
The Comments Property, which is common to all MIB Smithy records for which ASN.1 is generated (including modules, type assignments, MODULE-COMPLIANCEs, etc.), allows you to specify optional comments that are to be associated with the record. Like comments in programming languages, ASN.1 comments are bits of text that allow extra descriptive text to be provided that are discarded by normal parsers. When MIB Smithy generates the module, either when saving or previewing, the comments for a particular record will be generated immediately above the record they are associated with.
Figure - MODULE-COMPLIANCE Workspace, Comments Page