[ Home | What's New | SNMPinfo | SMIC ]

Background on SMIC

• SMIC is short for SNMP MIB Information Compiler.
• The original version of SMIC, now called SMIC classic, was developed by David T. Perkins while he was an employee at SynOptics Communications, which merged with Wellfleet Communications to become Bay Networks, Inc.
• The current version is called SMICng, which is is short for SMIC next generation, and is an enhanced version developed by David T. Perkins from the SMIC sources licensed from Bay Networks.
• A reduced functionality version of SMICng is found on the CD-ROM included with the book Understanding SNMP MIBs by Perkins and McGinnis, published by Prentice Hall, with ISBN 0-13-437708-7.
• A full-function version is now available to individuals from SNMPinfo.
• There are several OEM versions of SMICng available from SNMPinfo.

Uses for SMICng

• The primary use of SMICng is to check a MIB module to determine if its syntax is valid. Unfortunately, the definition of the syntax of valid MIB modules is flawed. (There is on going work, called the SMI-clarification project, whose goal is to clean up the ambiguous, incomplete, and inconsistent of the MIB module language.) To work around the flaws, SMICng has many options that allow you to select what should be allowed, flagged as a warning, or flagged as an error for the constructs that are poorly specified in the definition of the MIB module language. SMICng can be configured with popular text editors such as emacs in Unix or brief in MS-DOS/Windows/NT so that MIB design and checking can be done interactively.
• Another use of SMICng is to print reports about MIBs so they can be better understood. One example is a report that lists the object identifier values specified in a MIB module, the traps defined in a MIB module, and the textual conventions defined in a MIB module. Another report is a pictorial view of the OID sub-trees for the OID values specified in a MIB module. Yet another example is a report that lists the count of each type of construct used in a MIB module.
• Besides using SMICng to design and understand MIBs, SMICng can be used to output information from a MIB module in a format that is easily used by another program. Such other programs, called back-ends, can generate data structures and code for SNMP agent developers; generate code and data structures for management application developers; generate information that is used to drive an agent test program; generate reports describing agent implementations; compare agent implementations and requirement specifications; or generate a list of changes between versions of MIB modules.
• Finally, SMICng can translate a MIB module written in the SMIv2 format to the SMIv1 format. This is quite useful, since many existing MIB tools only recognize the SMIv1 format.

Pictorial History of SMICng

Differences between the Full (Pro) and Limited (Book) versions of SMICng

• Both versions support all specifications for controlling the level of checking of MIB modules.
• The Book version is primarily for checking MIB modules. It does not support the generation of reports about MIB modules, or the translation of a MIB module written in the SMIv2 format to the SMIv1 format.
• The book version does include one output format for back-ends. This format contains all the information found in a MIB module.
• The license for the Book version allows only the owner to use the ouput. That is, the output, before or after processing, cannot be distributed to others.
• The Pro version includes all output formats and reports, and includes translation. One output format is identical to that generated by MOSY v7.1. This format is used by back-ends, the most noteworthy is postmosy from SNMP Research International.

Differences Between SMICng and Other MIB Compilers

• There are two current versions of the MIB module language. The first is called SMIv1 and second is called SMIv2. The first specification of SMIv2 (which is now obsolete) is in RFCs 1442-1444. The second specification of SMIv2 (which is now current) is in RFCs 1902-1904. SMICng supports SMIv1, and both specifications of SMIv2. (SMIC classic supports only SMIv1.) Other MIB compilers may support only SMIv1, or support only the first (and now obsolete) specification of SMIv2.
• Many implementations of MIB tools combine a compiler (the front-end) with a specific output generator (a back-end) and call this combined tool a MIB compiler. SMICng was designed so that independent back-ends could be developed without the need for access to the source code for SMICng.
• SMICng is designed to support a family of output generators. Other MIB compilers were designed as a MIB tool to generate a specific output. Thus, these other MIB compilers are difficult to adapt to generate different outputs.
• Many of the other MIB compilers assume that the MIB modules that are input to them are correct, since the focus of these compilers is to generate a specific output. On the other hand, the primary design goal for SMICng is to completely check MIB modules for correctness. The SMICng approach moves the generation of specific outputs to back-ends. Note that other MIB compilers do have some checking, but typically only a minimal amount and that for the constructs needed to generate their output. For example, SMIv2 includes the MODULE-COMPLIANCE construct, which is used to specify implementation requirements. Other MIB compilers, such as ones used in development of SNMP agents, minimally check this construct for correctness, since it is not needed for agent development.
• SMICng is designed to allow incorrect MIB modules to be compiled. Other MIB compilers have one view of what is the "correct" syntax for MIB module constructs. SMICng has option settings to specify what is allowed, or flagged as a warning or error for many MIB module constructs. Also, SMICng has many built in heuristics to cope with and offer suggestions for common errors found in MIB modules. Most other MIB compilers stop on the first encountered error with a message of the form "Syntax error on line 102. Last token read was Foo."
• SMICng is designed to check a collection of MIB modules for consistency. Other MIB compilers typically parse only a single MIB module and do not check for errors, such as, different items assigned the same OID value in different MIB modules.

Previous Objections to using SMICng

If SMICng is so good, then why haven't all vendors with MIB tools switched to SMICng?

There are many reasons why SMICng is not yet universally used. Reasons include:

1. Competitors of Bay Networks didn't want to license/ship technology from their competitor.
2. Confusion over the licensing terms.
3. The belief by users of existing MIB compilers that their compiler was good enough.
4. The belief that verification of MIB correctness was not the purpose or requirement of their tool.
5. Confusion over how to get SMICng.

Reasons to Use (or switch to) SMICng

For all:

• When a new standards-track RFC containing a MIB module is published, the module(s) are extracted and, if needed, corrected and posted at the SNMPinfo WEB site for download.

For beginning MIB designers:

• The Book version of SMICng is easy to obtain and is inexpensive. SMICng comes on a CD-ROM with the book Understanding SNMP MIBs.
• Updates of the Book version of SMICng to correct defects have been made available to purchasers of the book for no additional fee. (Note: there is no promise that future versions will be made available at no additional fee.)

For professional MIB designers:

• A license for the Pro version is available from SNMPinfo.
• The Pro version of SMICng includes all the outputs such as generating MIBs in SMIv1 format, and reports listing the items defined in MIB modules in sorted order. Output from the Pro version can be distributed to others as is, or after processing it with a back-end.
• Updates of the Pro version of SMICng to correct defects are made available to Pro licensees for no additional fee.

For OEMs:

• A license can be obtained for use of SMICng from SNMPinfo. There is no need to contact Bay Networks.
• The license terms for OEM deals are worked out on an individual basis. In general, the pricing of an OEM version is much lower than the cost of a license for the Pro version.
• Switching to SMICng from your current MIB tool will must likely result in lower total costs.
  
  One OEM that is switching to SMICng was using a MIB tool based on a version of the CMU MIB parser that supported only SMIv1. The OEM found that many SMIv1 MIB modules could not be parsed without errors due to the limitations of the CMU MIB parser. (And the OEM could not support MIBs written in the SMIv2 format). The switch over to SMICng required that a small back-end be written to take one of the outputs from SMICng and create the data structures identical to those created by the CMU MIB parser. Once this was done, it took the OEM less than an hour to change the code using the CMU MIB parser to code using this SMICng back-end.
  
  Another OEM that is switching to SMICng was using MOSY as its MIB compiler. This OEM needed to support many platforms, not just SunOS and Solaris. Porting and supporting MOSY on other platforms looked like an expensive undertaking. Since SMICng provides the same outputs as MOSY v7.1, is available on the leading platforms, and is easy to port to other platforms, switching to SMICng was a lower cost solution than porting and maintaining MOSY. Also, by switching to SMICng, the OEM's end users got better error messages when they compiled MIBs containing bugs.
  
• Using or switching to SMICng will ensure that when changes are made to the SMI, then you will have support for those changes.

Copyright © 1998 SNMPinfo. All Rights Reserved.
Last modified: May 25, 1997