Updating the MIB Review guidelines

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

MIB Doctors --

In the next couple of weeks I plan to issue an update the MIB review
guidelines document.  The main reasons for the update are to bring
the document into compliance with RFCs 3667 and 3668 (these are the
recently-published replacements for RFC 2026 Section 10) and with
the latest IESG policies in http://www.ietf.org/ID-Checklist.html,
but besides this there are also some things that need to be updated
based on experience with the document over the last 9 months.

The purpose of this note is to make a list of the changes that I
need to make to draft-ietf-ops-mib-review-guidelines-02.txt.  
Please let me know if there is something not on the list below that
you think needs to be fixed, or if there is something on the list
that you do not think should be there.  Once we agree on the list I
will circulate proposed text for the ones that are not routine or
obvious.  Note that items below are listed in order of appearance in
the guidelines draft.

1.) Add updated I-D boilerplate & disclaimer, as required by RFC
3667.

2.) On the front page direct comments on the document to
<ietf-mibs@ops.ietf.org>, since the old mibs list is defunct.

3.) In Section 3.2 add a requirement to mention all modules from
which items are imported in the overview section.

4.) Change all occurrences of http://www.ietf.org/ID-nits.html to
http://www.ietf.org/ID-Checklist.html

5.) Change the instructions for IPR notices in Section 3.4 (and also
in Appendix A) to refer to RFC 3667 instead of RFC 2026.

6.) Add some text in Section 3.5 noting that the RFC Editor requires
that all references be cited somewhere in the text (this is the main
reason for item #3 above;  the alternative of putting citations in
the MIB module is something that I don't think we want to
encourage).

7.) Where [RFC2223bis] is referenced change the section numbers to
match the current draft (<draft-rfc-editor-rfc2223bis-07.txt> unless
a newer one appears soon).  Affected sections are 3.5, 3.6, and 3.7.

8.) Change the IANA Considerations instructions in Section 3.7 to
comply with the new policy requiring an IANA Consideridations
section even when the only IANA action that is needed is the
assignment of the object identifier for the MIB module's
MODULE-IDENTITY value.  Note that this was requested by the IANA
representative (and is also required by
http://www.ietf.org/ID-Checklist.html).

9.) Change the instructions for copyright notices in Section 3.8 to
refer to RFC 3668 instead of RFC 2026.

10.) Add some text to Section 4.5 encouraging people to root their
standards-track MIB modules directly under mib-2 or transmission and
discouraging them from creating new technology-specific registries
for the IANA to maintain.  (The MPLS WG did that and the PWE3 group
is to be following in their footsteps, and I think the trend is
regrettable.)

11.) Add some text to Section 4.5 strongly admonishing authors NOT
to use misappropriated SMI numbers in drafts.  If early
implementations are wanted then experimental numbers should be
obtained.

12.) In Sections 4.6.1.1 and 4.6.1.6 mention that DEFVALS for
enumerated INTEGER and BITS objects may, according to the SMI, be
specified either by label or by value, but since some tools do not
accept the numeric form, the label form is preferred.

13.) In Section 4.9 clarify that adding an OBJECT clause specifying
support for the original set of values of an enumerated INTEGER or
BITS object is needed (to avoid a silent change to the meaning of
the compliance statement) only when the MAX-ACCESS is read-write or
read-create.

14.) I am not sure if the issue of module names is clear in
guidelines.  My intent was that Appendix C should be considered to
be helpful suggestions, not rules that we impose on other people;  
but the practical effect is that the MIB doctors themselves become
bound by these suggestions.  Frankly I don't think that a change is
needed, but others might disagree.  Let me know if you do.

15.) Update all references to I-Ds that have turned into RFCs (one
good think about the long delay is that most of the referenced I-Ds
have in fact been published).  Add RFCs 3667 and 3668 to the
normative reference list (and remove RFC 2026 if it is no longer
cited after the changes discussed above).

Regards,

Mike