Proposed changes to MIB review guidelines checklist (Appendix A)

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

Folks --

Since we have decided to eliminate mention of specific MIB compilers
in the guidelines document, some changes are needed to the
checklist, specifically item 9 (MIB compilation).  In several recent
MIB reviews I've used the checklist to organize my comments, and
I've found that it increasingly awkward to disuss MIB compilation as
if it were separate from technical content.  So to kill two birds
with one stone I propose to replace the old items 9-11:

   9.) MIB compilation -- examine all error or warning messages
   generated by SMICng and smilint when set to maximum complaint levels
   (exception:  warnings for names longer than 32 characters should be
   ignored).  In general, error messages (E from SMICng, severity <= 4
   from smilint) indicate conditions that MUST be corrected, and warning
   messages (W from SMICng, severity >= 5 from smilint) indicate
   conditions that SHOULD be corrected.  Judgment is required, however,
   because there are situations when a diagnostic message will be issued
   for something that is in fact legitimate (the converse is also true).

   10.) Other issues -- check for any issues mentioned in
   http://www.ietf.org/ID-nits.html that are not covered above.

   11.) Technical content -- review the actual technical content for
   compliance with the guidelines in this document.  It is particularly
   important to check that DESCRIPTION clauses are sufficiently clear
   and unambiguous to allow interoperable implementations to be created.

with new items 9 and 10:

   9.) Other issues -- check for any issues mentioned in
   http://www.ietf.org/ID-nits.html (other than MIB compilation) that
   are not covered above.

   10.) Technical content -- review the actual technical content for
   compliance with the guidelines in this document.  The use of a MIB
   compiler is recommended when checking for syntax errors;  see
   http://www.ops.ietf.org/mib-review-tools.html for more information.
   Checking for correct syntax, however, is only part of the job.  It is
   just as important to actually read the MIB document from the point of
   view of a potential implementor.  It is particularly important to
   check that DESCRIPTION clauses are sufficiently clear and unambiguous
   to allow interoperable implementations to be created.

Please let me know ASAP whether or not this is OK.  It is preferred that
you send text if you want to request that something be changed.

Thanks,

Mike