2.1. Object Definitions

In general, conversion of a MIB module does not require the deprecation of the objects contained therein. Only if the semantics of an object truly changes should deprecation be performed.

1. The IMPORTS statement must reference SNMPv2-SMI, instead of RFC1155-SMI and RFC-1212.

2. The MODULE-IDENTITY macro must be invoked immediately after any IMPORTs or EXPORTs statement.

3. For any descriptor which contains the hyphen character, the hyphen character is removed.

4. 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), the object must have the value of its SYNTAX clause changed to Integer32.

5. For any object with a SYNTAX clause value of an enumerated INTEGER, the hyphen character is removed from any named-number labels which contain the hyphen character.

6. For any object with a SYNTAX clause value of Counter, the object must have the value of its SYNTAX clause changed to Counter32.

7. For any object with a SYNTAX clause value of Gauge, the object must have the value of its SYNTAX clause changed to Gauge32.

8. For all objects, the ACCESS clause must be replaced by a MAX-ACCESS clause. The value of the MAX-ACCESS clause is the same as that of the ACCESS clause unless some other value makes "protocol sense" as the maximal level of access for the object. In particular, object types for which instances can be explicitly created by a protocol set operation, will have a MAX-ACCESS clause of "read- create". If the value of the ACCESS clause is "write- only", then the value of the MAX-ACCESS clause is "read- write", and the DESCRIPTION clause notes that reading this object will result implementation-specific results.

9. For any columnar object which is used solely for instance identification in a conceptual row, the object must have the value of its MAX-ACCESS clause set to "not- accessible", unless all columnar objects of the conceptual row are used for instance identification, in which case, the MAX-ACCESS clause for one of them must be something other than "not-accessible".
10. For all objects, if the value of the STATUS clause is "mandatory", the value must be replaced with "current".

11. For all objects, if the value of the STATUS clause is "optional", the value must be replaced with "obsolete".

12. For any object not containing a DESCRIPTION clause, the object must have a DESCRIPTION clause defined.

13. 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.

14. For any object with an INDEX clause that references an object with a syntax of NetworkAddress, the value of the STATUS clause of the both objects is changed to "obsolete".

15. For any object containing a DEFVAL clause with an OBJECT IDENTIFIER value which is expressed as a collection of sub-identifiers, change the value to reference a single ASN.1 identifier.

Other changes are desirable, but not necessary:

1. Creation and deletion of conceptual rows is inconsistent using the current framework. The SNMPv2 framework corrects this. As such, if the MIB module undergoes review early in its lifetime, and it contains conceptual tables which allow creation and deletion of conceptual rows, then it may be worthwhile to deprecate the objects relating to those tables and replacing them with objects defined using the new approach.

2. For any object with a string-valued SYNTAX clause, in which the corresponding OCTET STRING does not have a size restriction (i.e., the OCTET STRING has no assignment of lower- and upper-bounds on its length), one might consider defining the bounds for the size of the object.

3. For all textual conventions informally defined in the MIB module, one might consider redefining those conventions using the TEXTUAL-CONVENTION macro. Such a change would not necessitate deprecating objects previously defined using an informal textual convention.
4. For any object which represents a measurement in some kind of units, one might consider adding a UNITS clause to the definition of that object.

5. 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, one might consider using an AUGMENTS clause in place of the INDEX clause for the object corresponding to the conceptual row which is an extension.

Finally, when encountering common errors in SNMPv1 MIB modules:

1. For any object with a SYNTAX clause value of an enumerated INTEGER, if a named-number enumeration is present with a value of zero, the value of the STATUS clause of that object is changed to "obsolete".

2. 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 is changed to "obsolete".

3. For any conceptual row object that is not contained immediately subordinate to a conceptual table, the value of the STATUS clause of that object (and all subordinate objects) is changed to "obsolete".