[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: comments on mib review guidelines 01
Thanks for reviewing and commenting.
Some answers/comments inline
Bert
> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]
> Sent: dinsdag 1 juli 2003 11:48
> To: mreview@psg.com
> Subject: 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.
>
Ditto from here!
> 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.
>
Agree
> 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.
>
How about: s/OPS Area MIB review/IESG MIB Doctor Review/
If you do just "IESG MIB Review" it sounds as if IESG members do it
themselves.
> 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.)
>
I like the above. But I think it was Juergen who convinced me a while
ago that sometimes there may be good reasons to group notifications
differently as suggested above. Anyway, as long as we make it a
"good practice suggestion" and not another MUST conform to new CLR,
then I am fine with this.
> 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.
>
I would say that such would be allowed too.
> 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.
>
I thought we were going to remove the listing of specific tools
(cause it might look as promoting things or omiting others).
> 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*").
>
Agreed
Bert
> /js
>
> --
> Juergen Schoenwaelder International University Bremen
> <http://www.eecs.iu-bremen.de/> P.O. Box 750 561,
> 28725 Bremen, Germany
>