[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
comments on mib review guidelines 01
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
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 220.127.116.11.
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 18.104.22.168.
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:
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
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
Juergen Schoenwaelder International University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany