9 SMI Conversion
Within the menu, MIB Designer provides automated SMI version conversion between SMIv1 and SMIv2 and vice versa. Although a fully automated conversion is not possible (and eligible), MIB Designer can save a lot of repetitive work.
To convert a SMIv1 MIB module to SMIv2, choose . Because SMIv2 requires a MODULE-IDENTITY construct, the following wizard dialog prompts for a parent OID of all objects to be created by the conversion, including the MODULE-IDENTITY construct.
If necessary, an OBJECT-GROUP and a NOTIFICATION-GROUP are created too.
The conversion compromises the steps set forth below. Not all steps can be performed fully automated. The list below is largley along the lines with the steps listed in §2.1of RFC3584, however it is grouped by the level of manual interventation needed for each step.
The following conversion steps are fully automated by MIB Designer and do not need manual interventation.
1. The IMPORTS statement references SNMPv2-SMI, instead of RFC1155-SMI and RFC-1212.
2. For any object with a SYNTAX clause value of Counter, the object’s SYNTAX clause is changed to Counter32.
3. For any object with a SYNTAX clause value of Gauge, the object’s SYNTAX clause is changed to Gauge32. If Gauge32 is not the appropriate for type, it can be changed to Unsinged32 can be manually after the conversion.
4. For all objects, the ACCESS clause is be replaced by a MAX-ACCESS clause. If the value of the ACCESS clause is "write-only", then the value of the MAX-ACCESS clause is set to "read-write".
5. For all objects, if the value of the STATUS clause is "mandatory" or "optional" it is set to "current" or "obsolete" respectively. Depending on the usage of the object, its STATUS might have to be set to “deprecated” manually after the conversion.
6. If any INDEX clause contains a reference to an object with a syntax of NetworkAddress, then a new object is be created and placed in this INDEX clause immediately preceding the object whose syntax is NetworkAddress. This new object has a syntax of INTEGER, it is not-accessible, and its value is limited to the value 1.
Note that the use of NetworkAddress in new MIB documents is strongly discouraged (in fact, new MIB documents should be written using SMIv2, which does not define NetworkAddress).
7. For any object with a SYNTAX of NetworkAddress, the SYNTAX is be changed to IpAddress.
8. An OBJECT-GROUP is defined, and related object types are collected into that group - if there are any. Otherwise, the group object is not defined.
9. A NOTIFICATION-GROUP is defined, and related notification types are collected into that group - if there are any. Otherwise, thgroup object is not defined.
10. For any object with an integer-valued SYNTAX clause, in which the corresponding INTEGER does not have a range restriction (i.e., the INTEGER has neither a defined set of named-number enumerations nor an assignment of lower- and upper-bounds on its value), a range restriction is added to the object.
11. The value of an invocation of the NOTIFICATION-TYPE macro is an OBJECT IDENTIFIER, not an INTEGER, and is be changed accordingly. The value of the invocation is the value of the ENTERPRISE clause extended with two sub-identifiers, the first of which has the value 0, and the second has the value of the invocation of the TRAP-TYPE.
An empty DESCRIPTION clause is be added, if not already present. The ENTERPRISE clause is removed. The VARIABLES clause is renamed to the OBJECTS clause. A STATUS clause with value “current” is added. If this value is not appropriate for the objects usage then you should replace it by ”deprecated” or “obsolete” as needed.
9.1.2 Manual Intervention or Review Needed
1. The MODULE-IDENTITY macro must be invoked immediately after any IMPORTs statement. You will have to specify the parent OID of the MODULE-IDENTITY construct in the wizard and then edit its DESCRIPTION, CONTACT, etc. clauses manually afterwards.
2. For any object not containing a DESCRIPTION clause, an empty DESCRIPTION clause is defined which needs to be filled manually after the conversion.
The following steps necessary for a conversion from SMIv1 to SMIv2 according to RFC 3584 are not supported by the conversion wizard. These steps have to be performed manually after conversion - if necessary:
1. For object types for which instances can be explicitly created by a protocol set operation, their object type’s MAX-ACCESS clause is replaced by "read-create".
2. For any object corresponding to a conceptual row which does not have an INDEX clause, the object must have either an INDEX clause or an AUGMENTS clause defined. Although a missing INDEX clause is detected by the SMI check, it cannot be automatically corrected by MIB Designer.
3. For any object containing a DEFVAL clause with an OBJECT IDENTIFIER value which is expressed as a collection of sub- identifiers, the value must be changed to reference a single ASN.1 identifier. This may require defining a series of new administrative assignments (OBJECT IDENTIFIERs) in order to define the single ASN.1 identifier.
4. For any non-columnar object that is instanced as if it were immediately subordinate to a conceptual row, the value of the STATUS clause of that object must be changed to "obsolete". MIB Designer reports such an issue in its SMI check, but does not correct it automatically.
5. For any conceptual row object that is not immediately subordinate to a conceptual table, the value of the STATUS clause of that object (and all subordinate objects) must be changed to "obsolete". MIB Designer reports such an issue in its SMI check, but does not correct it automatically.
6. All textual conventions informally defined in the MIB module should be redefined using the TEXTUAL-CONVENTION macro. Such a change would not necessitate deprecating objects previously defined using an informal textual convention.
7. For any object which represents a measurement in some kind of units, a UNITS clause should be added to the definition of that object.
8. For any conceptual row which is an extension of another conceptual row, i.e., for which subordinate columnar objects both exist and are identified via the same semantics as the other conceptual row, an AUGMENTS clause should be used in place of the INDEX clause for the object corresponding to the conceptual row which is an extension.
Although the conversion of a MIB module from SMIv2 to SMIv1 can be almost fully automated, some information gets lost. MODULE-IDENTITY, OBJECT-GROUPs and NOTIFICATION-GROUPs definitions have to be removed from the MIB module, for example.
This conversion can be useful if a system does not support SMIv2 and that system cannot be changed to support it.
To convert a SMIv2 MIB module to SMIv1, choose . The conversion compromises the steps set forth below.
1. The MODULE-IDENTITY construct is replaced by an OBJECT IDENTIFIER.
2. All OBJECT-GROUP, NOTIFICATION-GROUP, and AGENT-CAPABILITIES constructs are removed.
3. For all object types, the MAX-ACCESS clause is replaced by a ACCESS clause. A value of “read-create” is replaced by “read-write”.
4. For any object with a STATUS clause of value “current” its value is replaced by “mandatory”.
5. For any object type with an AUGMENTS clause, that clause is replaced by an INDEX clause with the value of the INDEX clause of the referenced conceptual table.
6. All invocations of the TEXTUAL-CONVENTION macro are replaced by an informally defined textual convention.
7. Any UNITS clause is removed from the definition of that object.
8. The IMPORTS statement references RFC1155-SMI and RFC-1212, instead of SNMPv2-SMI.
9. For any object with a SYNTAX clause value of Counter32, the object’s SYNTAX clause is changed to Counter.
10. For any object with a SYNTAX clause value of Gauge32, the object’s SYNTAX clause is changed to Gauge.
11. For any object with a SYNTAX clause value of Unsinged32, the object’s SYNTAX clause is changed to Unsigned.
12. Any object with a SYNTAX clause value of Counter64 is removed.
13. The value of an invocation of the TRAPE-TYPE macro is an INTEGER, not an OBJECT IDENTIFIER, and is be changed accordingly. The ENTERPRISE clause is added. The OBJECTS clause is renamed to the VARIABLES clause. The STATUS clause is removed.
14. For any object with a SYNTAX clause value of “BITS” is replaced by “OCTET STRING” and a corresponding DEFVAL clause is converted from enumerated bit names to a hex string.
1. If the object identifier of a notification type has a second to last sub-identifier which is not zero, that notifcation type cannot be used with SMIv1.
2. If a notification type refers to an object type with effective syntax of Counter64, that notification type cannot be used with SMIv1.