Issue with MIB compilation requirement in "AD Review of I-Ds"(http://www.ietf.org/ID-nits.html)

["C. M. Heard" <heard@pobox.com>]

Greetings,

Regarding the ID-nits document dated 2 Nov 2002 and posted 7 Nov 2002:
it is NOT appropriate to make the following rule into an absolute
requirement:

>      * All MIBs must compile cleanly using "smilint -l 9"
>        An email service is available for the check.
>        Extract the MIB form the document and send it in the body of an
>        email to smilint@ibr.cs.tu-bs.de.

The problem with requiring all MIBs to compile cleanly (i.e. with no
errors or warnings) using "smilint -l 9" is that this setting will
almost certainly cause smilint to complain about things that are not
really wrong.  Some warnings need to be ignored, and judgement is
required regarding many of the others as to whether they in fact
indicate the presence of a defect which warrants correction.

At Bert Wijnen's request I am currently preparing a document -D that
covers guidelines for MIB authors and reviewers.  The smilint command
line that I have recommended is:

smilint -l 9 -s -i namelength-32 <module>

This causes all warnings and errors to be reported except for descriptors
longer than 32 characters.  The switch "-i namelength-32" causes warnings
for descriptors longer than 32 characters to be suppressed.  The reason
for doing so is that the the SMIv2 documents say only that descriptors
SHOULD NOT have more than 32 characters, and the consensus among most
MIB reviewers seems to be that considerations of clarity override this.

The expectation is that in most cases there will be no warning messages
with these switches, but in some cases warning messages may legitimately
appear.  One example is in the IF-MIB (RFC 2863) contains an object group
ifStackGroup2 that is not used within that module, which causes a warning
message from smilint, but this is in fact legitimate since that group
appears in the conformance statement for the IF-INVERTED-STACK-MIB (RFC
2864).  Another example is in the PerfHist-TC-MIB (RFC 2493), which
contains just the definitions of three textual conventions that are used
in other modules.  smilint complains that the TCs are not referenced in
that module, which is true but again happens to be legitimate.

It will probably be a while before the MIB guidelines are ready, but
in the meantime it's definitely the case that this aspect of the
ID-nits document needs to be corrected.

Regards,

Mike Heard