[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Updating the MIB Review guidelines
Shouldn't we also update 4.6.1.7 and refer to http://www.ietf.org/internet-drafts/draft-ietf-ops-rfc3291bis-04.txt rather than to RFC 3291?
Regards,
Dan
> -----Original Message-----
> From: owner-mreview@ops.ietf.org
> [mailto:owner-mreview@ops.ietf.org]On Behalf Of C. M. Heard
> Sent: 24 May, 2004 6:32 PM
> To: Mreview (E-mail)
> Subject: Updating the MIB Review guidelines
>
>
> 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
>
>
>