Re: comments on mib review guidelines 01

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

On Tue, 1 Jul 2003, Juergen Schoenwaelder wrote:

JS> Here are some comments on <draft-ietf-ops-mib-review-guidelines-02.txt>:

Actually, the comments are on <draft-ietf-ops-mib-review-guidelines-01.txt>
with a few previously reported grammatical/typo corrections incorporated.

>>>>> On Fri, 4 Jul 2003, Wijnen, Bert (Bert) replied:
> Thanks for reviewing and commenting.
> Some answers/comments inline

JS> a) First, let me say that I like this document. Thanks to Mike for
JS>    his energy to actually put this together.

Thank you.

JS> b) I am not sure if the editor's note in section 3.8 is still needed -
JS>    at least people seem to be using the example given in the text
JS>    successfully.

BW> Agree

I agree that the editor's note needs to be replaced, but I would like to
point out that what it refers to are IANA-maintained MIB modules, which
are now required to have a DIFFERENT kind of copyright notice than the
one that is presently in the text (the IESG ruling that established this
postdates <draft-ietf-ops-mib-review-guidelines-01.txt>).  What is needed,
I think, is to re-word this section along the lines of Section 5.6(a) of
<draft-ietf-ipr-submission-rights-06.txt>.

JS> c) The document uses the phrase "OPS Area MIB Review" in several
JS>    places and I was wondering whether "IESG MIB Review" would not be
JS>    more appropriate. Rationale: All MIBs go through this review as
JS>    part of the IESG procedure and as such I feel that (i) MIB
JS>    reviewers actually help the IESG (although the process is organized
JS>    by the OPS area ADs) and (ii) "OPS Area MIB Review" could
JS>    potentially mislead people that only MIBs from the OPS area are
JS>    reviewed. Note also that the Introduction says in the first
JS>    sentence that this policy was instituted by the IESG.

BW> How about: s/OPS Area MIB review/IESG MIB Doctor Review/
BW> 
BW> If you do just "IESG MIB Review" it sounds as if IESG members do it
BW> themselves.

I don't agree with this comment.  As is noted above, the introduction of
<draft-ietf-ops-mib-review-guidelines-01.txt> says:

   Some time ago the IESG instituted a policy of requiring OPS area
   review of IETF standards-track specifications containing MIB modules.

Now, maybe this statement needs some work (to substitute "specifications
on the IESG agenda" for "IETF standards-track specifications" -- cf.
http://www.ops.ietf.org/mib-doctors.html), but it certainly does NOT say
or imply that only OPS area specs are subject to these reviews.  And so
long as the MIB doctors advise the OPS AD responsible for Network
Management (which they do: see http://www.ops.ietf.org/mib-doctors.html),
I think that it is correct to say "OPS area review".

All other occurrences in the document of "OPS Area" or "OPS area" (at
least that I was able to find) refer to "the current pool of OPS Area
MIB reviewers" (in Sections 4.2 and 4.8) or "the OPS area web site"
(in Appendix A, Checklist items 3 and 6).  Since the MIB doctors are
indeed "OPS Area MIB reviewers", and since the "the OPS area web site"
means http://www.ops.ietf.org/mib-security.html in both places where
is occurs, these are worded correctly and shouldn't be changed.  The
phrase "OPS Area MIB review" does not, in fact, occur at all, except
as a substring of "the current pool of OPS Area MIB reviewers", so I
don't see that there is any problem to solve.

JS> d) A duplicate "the" in the first bullet item in section 4.6.1.2.

Added to my typo list;  thanks.

JS> e) I recently came around the question whether numbered objects which
JS>    are not enumerations should always have a display hint. So far, I
JS>    always assumed that implementations would use "d" as a default but
JS>    that is not required by the SMIv2. So by putting in an explicit
JS>    display hint, MIB authors give a clearer hint.

Do you want the to say that a DISPLAY-HINT clause is RECOMMENDED?  I am
neutral on this, and request further input from the other MIB doctors.
I'm happy to document the consensus, I just want to hear what it is.

JS> f) Duplicate "to" in section 4.6.1.10.

Added to my typo list;  thanks.

JS> g) Would it be useful to suggest an OID layout which is being used in
JS>    IETF MIBs unless there is a reason to do something different?
JS>    [This question got triggered because the document is silent on the
JS>    question where to register the notification prefix.]
JS> 
JS>    I believe a common structure for a FOO-MIB is the following:
JS> 
JS>    fooMIB (x.y.z)
JS>    |
JS>    +-- fooNotifications(0)
JS>    +-- fooObjects(1)
JS>    +-- fooConformance(2)
JS>        |
JS>        +-- fooCompliances(1)
JS>        +-- fooGoups(2)
JS> 
JS>    The more controversial thing is probably the usage of fooNotifications
JS>    but I believe this is a nice and compact solution. (Of course, the 
JS>    fooConformance intermediate node actually has close to zero value but
JS>    since this is established practice, we better stick to it.)

BW> I like the above. But I think it was Juergen who convinced me a while
BW> ago that sometimes there may be good reasons to group notifications
BW> differently as suggested above. Anyway, as long as we make it a
BW> "good practice suggestion" and not another MUST conform to new CLR,
BW> then I am fine with this.

One way to do this would be to add an "advisory" appendix entitled
"Suggested OID layout", somewhat along the lines of the existing one
on naming conventions, which was phrased as a "suggestion" and does
not even use the imperative RECOMMENDED.

Are there any objections to my doing that?

JS> h) The text in section 4.8 on page 24 contains a duplicate "contains
JS>    the" which should be removed.

Added to my typo list;  thanks.

JS> i) The text allows to change module names when revising MIB modules to
JS>    correct typos. I think the same should be explicitly allowed for
JS>    labels (next to last item on page 26).

I agree and will make this change unless someone objects.

JS> j) The text at the start of page 27 says that addition of restrictions
JS>    is an editorial change if the restriction makes an already existing
JS>    protocol imposed restriction explicit. Question: Is it the removal
JS>    of "duplicate" restrictions also considered an editorial change?
JS>    The typical example is "DisplayString (SIZE (0..255))" where the
JS>    size constraint adds nothing new to the DisplayString definition.

BW> I would say that such would be allowed too.

I agree, subject to the proviso that I don't think that that there should
be any rule against such things as "DisplayString (SIZE (0..255))").

JS> k) Appendix B says that smidiff does not honor the -i namelength-32
JS>    switch which was indeed correct. I have fixed this bug and the next
JS>    release will just do the right thing so I suggest to remove the
JS>    relevant text.

BW> I thought we were going to remove the listing of specific tools
BW> (cause it might look as promoting things or omiting others).

I have to say (reluctantly) that the comments we got some months ago on
the mibs@ops.ietf.org list lead me to agree with Bert on this.  Personally,
I think that the appendices are quite useful, but I don't want to get in
the middle of a cat fight about this.

JS> l) I suggest that we add PhysicalIndex and PhysicalIndexOrZero to the
JS>    TCs listed in Appendix D.

Can you tell me what MIB module these appear in, and which RFC I should
reference?

JS> m) Appendix E says something about MIB module names. I suggest to add
JS>    one or two additional sentences which suggest that related MIB
JS>    modules and MIB module extensions should use the naming scheme
JS>    FOO-MIB, FOO-<EXTENSION>-MIB, ... rather than FOO-MIB,
JS>    <EXTENSION>-FOO-MIB, ... with the rationale that grouping all
JS>    related MIB modules below a common prefix makes it easier to find
JS>    them if you sort the module names alphabetically (on Unix "ls
JS>    FOO*").

BW> Agreed

OK by me.

Mike