RE: Proposed "Last Call" version of draft-ietf-ops-mib-review-guidelines [ Corrected, for the 2nd time ]

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

On Mon, 3 Jan 2005, Romascanu, Dan (Dan) wrote:
> At IETF61 in the Bridge MIB WG meeting the issue was raised
> about the usage of the guidelines document for reviewing and as
> a guidelines for editors of documents defining MIB modules from
> outside of the IETF (see
> http://www1.ietf.org/proceedings_new/04nov/minutes/bridge.html).
> One of the options I had in mind was a possible section that
> mentions the non-IETF specifics and possible relaxation of some
> of the rules that would allow for the guidelines to be used in a
> more convenient manner by non-IETF consistencies. I apologize
> for raising this in a thread that tries to get this extremely
> useful work closer to completion, but is it too late to discuss
> this issue?

It is certainly not too late to discuss this, particularly if we
expect some of the current IETF MIB Doctors to be doing MIB review
work for the IEEE.  But if we do end up making changes, we should
try hard to minimize the impact.

Obviously, we can't put anything in the MIB review guidelines that
is binding on other organizations, the most we can do is to suggest
what parts of the document might be useful to them, and then let
them write their own "applicability statements" saying what parts of
the document do and do not apply to them.

In doing a quick scan through the table of contents, it seems to me
that the "meat" is in Sections 3, 4, and Appendices A through D.

For the IEEE -- or for that matter, for any outside standards body
or private enterprise -- it is pretty clear that none of Section 3
applies, since that all deals with IETF documentation requirements.

Section 4.3 (Naming Hierarchy) is IETF-specific, and would not apply
to an outside standards body or to an enterprise.  Neither would the
part of Section 4.5 after the first paragraph.  However, I think
that the remainder of Section 4 does apply, provided that the
outside standards body or enterprise chooses to comply with the
extra restrictions that RFCs 2578, 2579, and 2580 impose on
"standard" MIB modules (subject to the caveat that uniqueness of
descriptors can be guaranteed only within the MIB modules under the
direct control of the outside standards body or enterprise).

In Appendix A items 1-9 of the checklist deal with IETF
documentation requirements and again do not apply to an outside
standards body or enterprise.  Item 10 does apply, but it is not
very helpful to have a one-item checklist.

Appendix B would probably be useful to an outside standards body or
enterprise that wants to re-use IETF work.  However, I would not be
surprised to find that many such organizations have their own
library of TCs, and those organizations would probably want to
supplement Appendix B with a catalogue of their own.

Appendix C would probably be useful to an outside standards body or
enterprise;  however, it would be a good idea for such an
organization to have a rule that module names (at least) have a
prefix that is likely to be unique to the organization.  On the
other hand, I can easily imagine an organization coming up with its
own naming convenions, so Appendix C would have to figure as nothing
more than a suggestion (which, officially, it already is).

Similar comments apply to Appendix D.

One thing that could be done to address Dan's comment would be to
add another appendix to the guidelines document that is essentially
a summary of what I just wrote down.  Another approach would be to
remain silent and let outside standards bodies and enterprises make
their own determination of what they consider to be useful.

One request from me:  if the consensus is that we do need to add
another appendix (or another section), then I would like to have 
some help in crafting the text.

Thanks,

Mike