Conformance Modules are an essential part of MODULE-COMPLIANCE and AGENT-CAPABILITIES (collectively, "conformance") statements. They are used to indicate MIB or PIB modules -- either the one the statement is defined in, or elsewhere -- that a particular section of the statement pertains to.
To create a Conformance Modules in MIB Smithy, you must first have created or loaded a Compliance or Capability record within the appropriate MIB Module in the project. Use the Project Tree to select and open the properties for the Compliance or Capability in which to create the record. Under the Modules Page for the record, specify the name of the module that is to be referenced by the Compliance/Capability statement and click the "Add" button. MIB Smithy will then create the record with the given name and open its workspace so that you may edit its properties or add variations or conformance groups to the conformance module.
The Module Name and OID Value properties are both available to be edited from the General Page of the Conformance Module Workspace, which is pictured below.
Figure - Conformance Module Workspace, General Page
The Module Name property is used to reference a MIB module that is applicable to the conformance statement. It corresponds to the SUPPORTS
clause if of the AGENT-CAPABILITIES macro and to the MODULE
clause of the MODULE-COMPLIANCE macro. Under normal circumstances, the module name referenced in this property will be the actual name of the MIB module. If the conformance needs to reference two different modules having identical names, then one or both can use an alternate name along with the OID Value property (below) to disambiguate the references.
A valid module name begins with an uppercase letter. It may contain zero or more additional letters, numbers or hyphens, provided it does not end in a hyphen and no two hyphens are adjacent.
This property is unconditionally required.
The OID Value property of the Conformance Module record may be used to specify the OID Value of the MODULE-IDENTITY statement in the referenced MIB module. This property corresponds to the ModuleIdentifier
part of the SUPPORTS
and MODULE
clauses for AGENT-CAPABILITIES and MODULE-COMPLIANCE. This OID value must be unique, unlike the module name its self. The behavior of this property is similar to that of the OID Value used in the MIB module's IMPORTS property in that it may be used in conjunction with specifying a local alternate name for the module to disambiguate references.
This property is optional, and not widely supported.
The Mandatory/Included Groups property corresponds to the MANDATORY-GROUPS
and INCLUDES
clauses in the MODULE-COMPLIANCE and AGENT-CAPABILITIES macros, respectively. In the case of MODULE-COMPLIANCE, this property lists the set of OBJECT-GROUPs and/or NOTIFICATION-GROUPs that MUST be implemented by an agent in order to claim conformance. In the case of AGENT-CAPABILITIES, this property lists those OBJECT-GROUPs and/or NOTIFICATION-GROUPs that the agent claims to support. In either case, if the conformance statement lists any variations, then the objects or notifications referenced by those notifications must be included in a group referenced by this property (or, for module compliance, through the Conditional Groups property).
This property is optional, but may be required by variations.
Figure - Conformance Module Workspace, Mandatory Groups Page
While SMIv1 does not have OBJECT-GROUP or NOTIFICATION-GROUP macros, it is still possible for conformance statements to reference groups of a sort. This property is allowed to take a reference (i.e., usually an identifier; possibly an OID value) to any record assigned an OID value in an SMIv1 module. In this case, any other record with an OID value defined subordinate to (that is, below) the referenced definition with a STATUS value of mandatory
is considered to be part of the group. This feature also applies to the Conformance Group property of MODULE-COMPLIANCE.
To add a group reference, enter its identifier or OID value into space provided, or select it from the drop-down list, and click the "Add" button. To delete a group reference, select it from the list and click the "Remove" button. The order that groups are listed is not significant, but a single group cannot be listed more than once.
The Conditional Groups property of the MODULE-COMPLIANCE Workspace is used to add pseudo-records referencing OBJECT-GROUPs and NOTIFICATION-GROUPs of the type called out by the macro's GROUP
clause. Where Mandatory Groups specifies groups that must always be implemented, this clause allows the compliance statement to document conditions under which a group is optional or mandatory.
This property is optional, but may be required by variations.
Figure - Compliance Module Workspace, Conditional Groups Page
To add a Conditional Group pseudo-record, enter its identifier or OID value into space provided, or select it from the drop-down list, and click the "Add" button. A new record will be created with the given name or OID and a workspace page will be opened where you can enter a description. To delete a group reference, select it from the list and click the "Remove" button. To edit the properties of an existing group, select it from the list and click the "Properties" button. The order that groups are listed is not significant, but a single group cannot be listed more than once.
The Variations property is used to add pseudo-records referencing OBJECT-TYPEs and NOTIFICATION-TYPEs as called out by the OBJECT
clause of MODULE-COMPLIANCE and VARIATION
clause of AGENT-CAPABILITIES.
For MODULE-COMPLIANCE statements, these pseudo-records are used to provide information to a reader or implementor as to the minimum requirements that an agent must meet in order to claim conformance to the level defined by the statement. This may include such things as a minimum accessibility level (e.g. indicating that a normally read-write object may be implemented as read-only) or a minimum subset of the normally-allowed range of values that the agent must support for read and/or write operations.
For AGENT-CAPABILITIES statements, these pseudo-records are used to provide information to a user or management application as to the actual level of support implemented by the agent. This may include such things as the highest level of access supported for an object (or, for that matter, if it isn't implemented), columns required for row creation, or the subset of values supported by the agent for read and/or write operations.
Figure - Conformance Module Workspace, Variations Page
To add a Variation pseudo-record, enter its identifier or OID value into space provided, or select it from the drop-down list, and click the "Add" button. A new record will be created with the given name or OID and a workspace page will be opened where you can edit its other properties. To delete a variation, select it from the list and click the "Remove" button. To edit the properties of an existing variation, select it from the list and click the "Properties" button. The order that variations are listed is not significant, but a single variations cannot be listed more than once. Also, for the conformance statement to be valid, the variation must be referenced by at least one group also referenced by the statement.
The Comments Property, which is common to all MIB Smithy records for which ASN.1 is generated (including modules, type assignments, Conformance Modules, 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.
Figure - Conformance Module Workspace, Comments Page