Blog

MIB Smithy 1.5 Release

Version 1.5 of MIB Smithy is a significant update that adds support for several of the more obscure areas of the SMI that are rarely supported by other tools. This includes complete support for ‘module.descriptor’ forms for type and value references described by RFC 2578, section 3.2. This version also includes support for specifying the OID value for an imported module’s MODULE-IDENTITY in an importing module’s IMPORTS statement, allowing the importing module to locally reference a module by a different name. This feature, along with ‘module.descriptor’ references, allows modules to import and use symbols that would otherwise be ambiguous due to the modules or symbols having the same descriptor.

Also new in this version, the tool now consistently supports all three forms for value references — identifier, ‘module.descriptor’, and object identifier — for all OID assignments to macro invocations, as well as all constructs where the SMI macro definitions reference the ‘ObjectName’ and ‘NotificationName’ internal types or ‘value(OBJECT IDENTIFIER)’, such as INDEX, AUGMENTS, NOTIFICATIONS, etc., with relevant compatibility warnings.

With these changes, along with the improved internal indexing from 1.4, MIB Smithy’s support for every feature the SMI has to offer is now considered by Muonics to be complete, and one of the most flexible MIB editors/compilers in existence. This will pave the way for a number of significant new features and tools under development for the upcoming 2.0 release.

As always, your feedback is important in determining changes and fixes that will be made in coming releases. If you have questions or comments, please don’t hesitate to contact us.

Significant Changes

• Use of INTEGER type without bounds now generates a compatibility warning, rather than a warning implying that it is forbidden, to align with the upcoming Coexistence RFC update.
• MIB Smithy now fully supports value and type references of the ‘module.descriptor’ form described by RFC 2578 (3.2). Similarly, IMPORTS module references now allow an OID to be present after the FROM module, allowing imports from different modules with the same name (where the name specified in the ‘FROM module’ part in this case specifies the “local” name for the module and the OID references the module’s MODULE-IDENTITY).
• Module workspace’s ‘Imports’ page now has an ‘Advanced’ button to show/hide a column allowing an OID to be specified for the MODULE-IDENTITY in the imported module, per above.
• Macro invocations (OBJECT-TYPEs, etc.) will now accept, and warn about, values that are a specified as a simple ‘DefinedValue’ (ie., identifier or module.identifier) reference.
• Multi-component OBJECT IDENTIFIER values and ‘module.identifier’ references (as opposed to identifiers only) are now accepted for member lists in NOTIFICATION-TYPE, OBJECT-GROUP and NOTIFICATION-GROUP, CREATION-REQUIRES, INDEX column and AUGMENTS row references, and a compatibility warning is issued by the compiler for such usage.
• A compiler error is now generated for duplicate references the CREATION-REQUIRES parameter of a VARIATION as well as in the OBJECTS and NOTIFICATIONS parameters of the OBJECT-GROUP and NOTIFICATION-GROUP record types.
• GUI properties now accept OID values and ‘module:identifier’ forms where the core library/compiler now accepts such (see above). The ‘module:identifier’ form is used in place of ‘module.identifier’ in the actual SMI file for simplified processing/pattern matching.
• Added optional OID property in conformance module workspaces (MODULE-COMPLIANCE ‘MODULE’ and AGENT-CAPABILITES ‘SUPPORTS’) for specifying the OID of the MODULE-IDENTITY in the module where the module’s name is ambiguous. This property corresponds to the ‘ModuleIdentifier’ production in the definition for these macros.
• A compiler error is now generated when an OBJECT-GROUP or NOTIFICATION-GROUP specifies an object or group, respectively, that is defined in a different information module than the one defining the group (as required by RFC 2580).
• Several dependency errors/warnings have been clarified or made more specific to the place where the reference occurs.
• Added GUI page/property for specifying CREATION-REQUIRES object list for VARIATIONs in an AGENT-CAPABILITIES statement.
• Parser can now recover from/correct an AUGMENTS field without the required braces around the row reference specified by the field.
• Removed ability to deal with IMPORTS OIDs that are simple identifiers in favor of ability to work around missing commas. Added ability to work around missing/extra commas in many additional places.
• Added test to verify that each group referenced by MANDATORY-GROUPs is not also referenced by a GROUP clause in MODULE-COMPLIANCE modules.
• Added test to verify that each variations in a MODULE-COMPLIANCE module is listed in one of the groups referenced by a GROUP or MANDATORY-GROUPS clause in the same compliance module.
• Added warning if a column with ‘RowStatus’ syntax is detected within a table augmentation “row” definition.
• Comments immediately after the LAST-UPDATED and REVISION timestamps in a MODULE-IDENTITY statement, which are used by some authors to give a formatted version of the revision date for readers who are unfamiliar with the ExtUTCTime format, are now discarded by the parser when loaded. Formatted timestamps with the correct month, day and year are now automatically generated as comments in these places for all modules.
• Added warning regarding use of the obsolete ‘UInteger32’ data type.
• Improved checks and reporting for mixing SMI versions in a single module and importing SMI base types from the proper modules.
• Altered layout of DISPLAY-HINT wizard slightly to accommodate smaller displays.
• Added rfc3418.mib (SNMPv2-MIB) to included sample MIB files.

Miscellaneous Bug Fixes

• ASN.1 tag information is now preserved where present, in case the SMI base modules are saved.
• Corrected various issues with truncated or otherwise improperly handled 64-bit values.
• Skipped dependency warnings were erroneously switched to disabled by default in an earlier version. They are now on by default.
• An incorrect error would be generated for a textual convention with INTEGER syntax and a DISPLAY-HINT. The error is now only generated if the INTEGER has an enumerated refinement.