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

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Thanks Mike fro bringing this up.

One of my reasons for formulating it as we did is that if you
use the mailer service, then you cannot specify any warning
levels, and it assume -l 9 by default.

In fact I like it if people use -l 9 to check their MIB Modules.
They should look at the warnings and evaluate if they are
serious or not. Sometimes they are not serious and easily
fixable too... so it would not hurt to just fix it.

I guess we might want to clarify the "must compile cleanly".
How about:

      * 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.

        This may cause some warnings (and the email service has
        currently no mechanism to supress such warnings). Pls
        evaluate the warnings before assuming they are OK. If
        in doubt, feel free to check on the mibs@ops.ietf.org
        mailing list or with OPS AD Bert Wijnen.

Thanks,
Bert 

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: donderdag 12 december 2002 4:19
> To: iesg@ietf.org
> Cc: mreview@ops.ietf.org
> Subject: Issue with MIB compilation requirement in "AD Review of I-Ds"
> (http://www.ietf.org/ID-nits.html)
> 
> 
> 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
> 
>