[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Updating the MIB Review guidelines
Yep, would be good!
Thanks,
Bert
> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
> Sent: dinsdag 25 mei 2004 15:31
> To: C. M. Heard; Mreview (E-mail)
> Subject: 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
> >
> >
> >
>