MIB Smithy
MOSY Output Format
The MOSY file format is a basic format for representing MIB module information in an easy-to-parse style. The format is supported by a wide variety of NMS tools and MIB compilers, including several variants of the original MOSY compiler. The following is a specification of the MOSY format, including the extensions to the format that are supported by the MIB Smithy compiler.
Example 1:
rfc3414.mib (input) / rfc3414.defs (output).
Example 2:
rfc2863.mib (input) / rfc2863.defs (output).
General Provisions
Each basic definition from a MIB module typically consists of one or two lines defining the record name, its OID (if applicable), and the record type if it cannot otherwise be inferred from the first line. For certain records, additional lines may be provided with further information, with a special prefix code identifying the type of information, such as each line listed for a named-number enumeration. The end-of-line sequence marks the end of the information contained on that line, and any number of whitespace characters may be used to separate the individual fields in a line.
Comments
Comments in the MOSY file format begin with a double-hyphen sequence (--), generally always at the start of a line, and end with the end-of-line sequence. Additionally, several of the extensions that MIB Smithy supports begin with the comment sequence. This allows the information to be present without causing problems for other implementations that do not support the extensions. Example:
-- object definitions compiled from DOCS-BPI2-MIB -- %mcgr docsBpi2BasicCompliance DOCS-BPI2-MIB docsBpi2CmGroup -- %mcgr docsBpi2BasicCompliance DOCS-BPI2-MIB docsBpi2CmtsGroup
The first line above appears near the start of the MOSY .defs file and indicates the name of the module from which the definitions were compiled. The other two lines are examples of one of the extensions to the format, which are at the end of this document.
Syntax Keywords
For the most part, the keyword given in the MOSY file format corresponding to the [WRITE-]SYNTAX field for a Type Assignment, TEXTUAL-CONVENTION, OBJECT-TYPE or variation is the same as given in the SMI MIB module. The exceptions are as follows:
| ASN.1/SMI Format | MOSY Format |
|---|---|
OCTET STRING |
OctetString |
OBJECT IDENTIFIER |
ObjectID |
SEQUENCE* |
Aggregate |
SEQUENCE OF rowName* |
Aggregate |
RowType* |
N/A |
* The MOSY format specifies Aggregate as the syntax for both conceptual table and row OBJECT-TYPE definitions. The rowName subtype is discarded. The SEQUENCE type assignment, which specifies the names and types of columns in the row, is not included in the output file. This information can be inferred from the other OBJECT-TYPE definitions with OID values subordinate to the row.
Type Assignments/TEXTUAL-CONVENTIONs
The first line of an ASN.1-style Type Assignment or TEXTUAL-CONVENTION begins with the three-letter prefix code %tc, followed by the descriptor or name for the record, the specified SYNTAX (minus any size or range refinements), and its DISPLAY-HINT value, if specified. That is:
-- Format: %tc TypeName Syntax "DisplayHint" -- Example: %tc DisplayString OctetString "255a" %er DisplayString 0 255
Additional lines may be present following this line that specify any size/range (indicated by the %er code in the above example), or named-number enumeration list refinements specified in the record's SYNTAX field. These are described further below. For enumerations, the %es prefix code is used (where the %ev code is used for OBJECT-TYPE enumerations); for other types of refinements, the prefix code is the same as for the OBJECT-TYPE's SYNTAX field.
OBJECT-TYPE definitions
The first line of an OBJECT-TYPE definition begins with the descriptor ofor the record, followed its dotted OID value, its SYNTAX, ACCESS and STATUS values. This first line is very similar to the output for the OBJECT-IDENTITY and OBJECT IDENTIFIER Value Assignments, except for the lack of SYNTAX, ACCESS and STATUS fields in those records.
-- Format: recordName oidValue Syntax access status -- Example: sysDescr system.1 DisplayString read-only current %er sysDescr 0 255
Additional lines may be present following this line that specify any size/range (indicated by the %er code in the above example), or named-number enumeration list refinements specified in the record's SYNTAX field, as well as the object's INDEX and DEFVAL fields. These are described further below.
Size/Range Refinements
Size and Range refinements given the SYNTAX field of an OBJECT-TYPE, TEXTUAL-CONVENTION or ASN.1 Type Assignment, take the same form. One line is present, starting with the %er prefix code, for each discrete subrange specified in the refinement, specifying the minimum and maximum value for that subrange. If a single value is specified, such as in SYNTAX OCTET STRING (SIZE(10)), then both the minimum and maximum are listed with equal values.
-- Format: %er recordName minValue maxValue -- Example: sysDescr system.1 DisplayString read-only current %er sysDescr 0 255
Named-Number Enumerations
The named-number enumeration list given the SYNTAX field of an OBJECT-TYPE, TEXTUAL-CONVENTION or ASN.1 Type Assignment, take the same form, other than a %ev prefix code for OBJECT-TYPEs and %es otherwise. One line is present, starting with the appropriate prefix code, for each named number, specifying both its name and value.
-- Format for OBJECT-TYPEs: %ev recordName enumName enumValue -- Format for TEXTUAL-CONVENTIONs/Type Assignments: %es TypeName enumName enumValue -- Example: snmpEnableAuthenTraps snmp.30 INTEGER read-write current %ev snmpEnableAuthenTraps enabled 1 %ev snmpEnableAuthenTraps disabled 2 %tc RowStatus INTEGER "" %es active 1 %es notInService 2 %es notReady 3 %es createAndGo 4 %es createAndWait 5 %es destroy 6
The OBJECT-TYPE's INDEX field
The INDEX field of an OBJECT-TYPE definition, if present, consists of a single line beginning with the %ei prefix code, the OBJECT-TYPE's descriptor, and a quoted, space-delimited list of objects from the INDEX. If one of these objects listed in the INDEX is prefixed by the IMPLIED keyword in the SMI/ASN.1 module, it is prefixed by an asterisk (*) character in the MOSY file.
-- Format: %ei recordName "index1 ?index2? ..." -- Example: usmUserEntry usmUserTable.1 Aggregate not-accessible current %ei usmUserEntry "usmUserEngineID usmUserName"
The OBJECT-TYPE's AUGMENTS field
The AUGMENTS field of an OBJECT-TYPE definition, if present, consists of a single line beginning with the %ea prefix code, the OBJECT-TYPE's descriptor, and the name of another OBJECT-TYPE defining a conceptual row for a table.
-- Format: %ea recordName rowName -- Example: %ea snmpTargetAddrExtEntry snmpTargetAddrEntry
OBJECT-IDENTITYs and Other OID Values
The first line for all records defining an OID value (other than OBJECT-TYPE) is the same as that for an OBJECT-TYPE definition, but with only the record name and its OID value. A second line, starting with the %n0 prefix, indicates that the macro used to create the definition (such as object-id for an OBJECT-IDENTITY versus a NOTIFICATION-GROUP). This distinguishes the record type from others where the normal (unextended) MOSY format excluses all information except for its OID value.
-- Format (first line, plus one "%n0" line): recordName oidValue %n0 recordName module-identity %n0 recordName object-id %n0 recordName notification %n0 recordName object-group %n0 recordName notification-group %n0 recordName module-compliance %n0 recordName agent-capabilities -- Example: snmpUsmMIB snmpModules.15 %n0 object-id
Extensions to the MOSY Format
Format specifications beyond this point are considered extensions to the MOSY format. Not all MOSY-format compilers generate these fields, and not all applications that ready MOSY files support them. For compatibility, some of these extensions are prefixed by the comment sequence so that they are ignored by non-supporting applications, while others are more common (such as for notifications and default values) are not commented.
IMPORTS Extension
This extension to the MOSY format specifies the modules from which various definitions used in the module are imported. Each imported symbol is given on a single line, using the (commented) %import prefix code as shown below. The moduleOID parameter, if present, indicates the dotted OID value for either the module its self if SMIv1 (as specified in the module header) or the OID value for the MODULE-COMPLIANCE statement in that module if SMIv2.
-- Format: -- %import symbolName moduleName ?moduleOID? -- Example: -- %import MODULE-IDENTITY SNMPv2-SMI -- %import OBJECT-TYPE SNMPv2-SMI -- %import OBJECT-IDENTITY SNMPv2-SMI -- %import snmpModules SNMPv2-SMI -- %import Counter32 SNMPv2-SMI -- %import TEXTUAL-CONVENTION SNMPv2-TC -- %import TestAndIncr SNMPv2-TC -- %import RowStatus SNMPv2-TC -- %import RowPointer SNMPv2-TC -- %import StorageType SNMPv2-TC -- %import AutonomousType SNMPv2-TC -- ...
NOTIFICATION-TYPE/TRAP-TYPE Extension
This extension to the MOSY format, supported by several MOSY-type compilers, uses a single line (prefixed by the %trap code) to indicate the trap value, enterprise OID, and objects that must be included when the trap/notification is sent. The trapObjects parameter may or may not be present. If specified, this parameter indicates the objects that must be included in the trap and, The trapEnterprise field corresponds to the ENTERPRISE field of an SMIv1 TRAP-TYPE, or the OID value of a NOTIFICATION-TYPE.
-- Format:
%trap recordName trapNumber trapEnterprise ?trapObjects?
-- Example (SMIv2):
%trap coldStart -1 snmpTraps.1
-- Example (SMIv1):
%trap otherTrap 2 acme { object1, object2, ... }
OBJECT-TYPE DEFVAL Extension
This extension to the MOSY format specifies the DEFVAL parameter for an OBJECT-TYPE, starting with the %defval prefix. This extension is NOT used, however, for variations in an AGENT-CAPABILITIES statement.
-- Format: %defval recordName defaultValue -- Example: %defval usmUserAuthProtocol usmNoAuthProtocol
OBJECT-GROUP/NOTIFICATION-GROUP Extensions
These extensions to the MOSY format specify the STATUS and OBJECTS or NOTIFICATIONS list for an OBJECT-GROUP or NOTIFICATION-GROUP. For both macros, the STATUS line begins with the (commented) %gs prefix, and each member is specified on an individual line using the (commented) %gl prefix.
-- Format (OBJECT-GROUP/NOTIFICATION-GROUP STATUS): -- %gs groupName statusValue -- Format (OBJECT-GROUP/NOTIFICATION-GROUP Member): -- %gl groupName memberName1 -- %gl groupName memberName2 -- ... -- Example: usmMIBBasicGroup usmMIBGroups.1 %n0 usmMIBBasicGroup object-group -- %gs usmMIBBasicGroup current -- %gl usmMIBBasicGroup usmStatsUnsupportedSecLevels -- %gl usmMIBBasicGroup usmStatsNotInTimeWindows -- ...
MODULE-COMPLIANCE/AGENT-CAPABILITIES Extensions
These extensions to the MOSY format specify the other information on modules, groups and variations included in a conformance statement. Module names can be inferred from the group and variation entries.
-- Format for MANDATORY-GROUPS/INCLUDES: -- %mcmg confName moduleName groupList -- Format for VARIATION/OBJECT: -- %mcob confName moduleName variationName Syntax WriteSyntax access -- Format for VARIATION/OBJECT Enumerations: -- %mcev confName moduleName variationName enumName enumValue -- %mcevw confName moduleName variationName enumName enumValue -- Format for VARIATION/OBJECT Range/Size Subspecification: -- %mcer confName moduleName variationName minValue maxValue -- %mcerw confName moduleName variationName minValue maxValue -- Format for MODULE-COMPLIANCE GROUP: -- %mcgr confName moduleName groupName
The optional w suffix in %mcevw and %mcerw indicates that the item is part of the WRITE-SYNTAX field for the variation, as opposed to %mcev and %mcer for the SYNTAX field. If no SYNTAX or WRITE-SYNTAX is specified for a variation, these fields are represented as an empty quoted string ("").
For %mcmg, the groupList is a quoted, space-delimited list of group names that are listed in the INCLUDES (AGENT-CAPABILITIES) or MANDATORY-GROUPS (MODULE-COMPLIANCE) fields.