MIB Smithy

General Provisions

Identifiers

An identifier, in general, is any sequence of characters starting with an upper or lowercase letter and followed by zero or more upper or lowercase letters, numbers, or the hyphen character, with the additional restrictions that it cannot end in a hyphen and two hyphens may not be adjacent. SMIv2 and SPPI also loosely forbid hyphens for most circumstances, allowing them primarily for compatibility with SMIv1.

Identifiers starting with an uppercase letter and identifiers starting with a lowercase letter are used for different purposes, and where one is required the other may not be used. This is a requirement inherited from ASN.1, where different capitalizations were required keep the language from being ambiguous.

Uppercase Identifiers

When an API or option requires an identifier starting with an uppercase letter it is referred to as an "uppercase identifier" or ucidentifier. Uppercase identifiers are used to name types (as in the definition of a TypeReference in the ASN.1 language specification) and modules (as in the definition of a ModuleReference in the ASN.1 language specifications). They are also used in naming or referencing macros, although SMI does not permit the definition of new macros. Example: SNMPv2-SMI and RowStatus both qualify as "uppercase identifiers" under this definition.

Lowercase Identifiers

When an API or option requires an identifier starting with a lowercase letter it is referred to as a "lowercase identifier" or lcidentifier. Lowercase identifiers are used to name any item that defines a value of any type (as in the definition of a ValueReference in the ASN.1 language specifications). Example: sysOrDescr is a "lowercase identifier" under this definition.

Type References

There are three forms of type references allowed by MIB Smithy SDK. The first two are the simplest, most commonly used, and most commonly supported by other compilers and NMS applications. These are the "uppercase identifier" described above, and certain ASN.1 base types that consist of two or more words or tokens (e.g. OCTET STRING and OBJECT IDENTIFIER). The third, which is not commonly supported or used, corresponds to the DefinedType production in the ASN.1 language specification.

In the DefinedType production, a type may be referenced by both the name of the type and the module in which it is defined, using a period as a delimeter. Example:

EXAMPLE-MIB.ExampleType

In MIB Smithy, this form may be used with a colon character instead of a period as the delimeter. This is done for consistency with object identifier values, where similar rules are implemented to simplify splitting the individual components apart when desired (such as for conversion to various formats). Example:

EXAMPLE-MIB:ExampleType

Value References

As with Type References, there are three forms of value references allowed by MIB Smithy SDK. In this document, an API or option that calls for a value reference refers to any of these accepted forms. Places where these are used are, for example, lists of columns in the INDEX clause of an OBJECT-TYPE, objects listed as members of a notification, etc. Essentially anywhere that the SMI specifications refer to value(ObjectName), value(NotificationName) or value(OBJECT IDENTIFIER) are properties that this document refers to as Value References.

The first form, and that which is the only one commonly used and supported, is that of a simple "lowercase identifier" as described above. The second form, not commonly used or supported, corresponds to the DefinedValue production in the ASN.1 language specification.

In the DefinedValue production, a value may be referenced by both the name/descriptor assigned to the value and the module in which it is defined, using a period as a delimeter. Example:

EXAMPLE-MIB.exampleMIBBranch

In MIB Smithy, this form may be used with a colon character instead of a period as the delimeter, as with Type References. This is done for consistency with object identifier values, where similar rules are implemented to simplify splitting the individual components apart when desired (such as for conversion to various formats). Example:

EXAMPLE-MIB:exampleMIBBranch

The third and final form, which is even less commonly (if ever) used or supported, is actually that of the Object Identifier Value. MIB Smithy SDK will allow (and work with) references such as those in the VARIABLES clause of NOTIFICATION-TYPE that are defined by OID rather than by value, although using this form is highly discouraged for reasons of compatibility between compilers.

Object Identifier Values

In basic terms, an OID value consists of two or more non-negative integers (called subidentifiers) separated by a dot (.). Due to the Basic Encoding Rules (the part of ASN.1 that defines how values are encoded for transmission "on the wire"), the first subidentifier must be 0, 1 or 2. The second subidentifier must be between 0 and 39 if the first subidentifier is 0 or 1. Otherwise, the only further restrictions imposed by SNMP are that (1) there is a limit of 128 subidentifiers in an OID value, and (2) that each subidentifier is restricted to the range 0..4294967295.

In the SMI/SPPI languages, OID values can either be "assigned" or "registered", depending on the type of record or macro used to define the OID. "Registered" OIDs are those that are unique to a particular definition, such that no two records may register the same OID. All of the SMI/SPPI macros register OIDs, whereas the ASN.1 Value Assignment form is only an assignment. Assignments do not necessarily uniquely identify anything, and can in fact have the same value as a registered OID (although many compilers don't support this). Example OID assignment:

system OBJECT IDENTIFIER ::= { mib-2 1 }

MIB Smithy SDK recognizes many forms for object identifiers, owing to the several ways in which they can be specified in module definitions and referenced by the APIs. OID values may be relative, where the first part of the OID value is similar to a Value Reference specifying a starting point or prefix in the OID tree (typically specified as a lowercase identifier) and followed by one or more integer subidentifiers, or absolute, where every integer subidentifier is present all the way up to one of the three roots 0, 1 or 2.

Further, each subidentifier (in both absolute and relative forms) can be a simple numeric value or a name-and-number value, where the integer subidentifier is given in parentheses following a lowercase identifier (as in org(3)). The following examples of OID values are all equivalent:

• system.1
• SNMPv2-MIB:system.1
• SNMPv2-MIB:mib-2.system(1).1
• 1.3.6.1.2.1.1
• iso.org(3).6.1.2.1.1
• iso(1).org(3).6.1.2.1.system(1)

MIB Smithy SDK provide several properties for dealing with each of these forms in specifying the OID value for record definitions. This allows records to be defined with OID values in a particular desired format for a resulting SMI language output file: in setting record properties, all are treated as specifying the so-called "as-declared" OID value -- meaning, the value as it would appear in the actual MIB definition when generated by MIB Smithy. When querying the OID property, on the other hand, several options are treated differently, allowing one to obtain either the "as-declared" OID value, a simple relative OID where module name and the names for name-and-number subidentifiers are stripped out, or "absolute" OIDs where the OID value returned is as fully resolved to one of the root nodes as possible.