comments on mib review guidelines 01

[Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>]

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

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

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

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

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

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

f) Duplicate "to" in section 4.6.1.10.

g) Would it be useful to suggest an OID layout which is being used in
   IETF MIBs unless there is a reason to do something different?
   [This question got triggered because the document is silent on the
   question where to register the notification prefix.]

   I believe a common structure for a FOO-MIB is the following:

   fooMIB (x.y.z)
   |
   +-- fooNotifications(0)
   +-- fooObjects(1)
   +-- fooConformance(2)
       |
       +-- fooCompliances(1)
       +-- fooGoups(2)

   The more controversial thing is probably the usage of fooNotifications
   but I believe this is a nice and compact solution. (Of course, the 
   fooConformance intermediate node actually has close to zero value but
   since this is established practice, we better stick to it.)

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

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

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

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

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

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

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany