[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: comments on mib review guidelines 01
> 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> 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
> 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.
Mmm... can you send me a complete rev 02 (ort whatever the curen doc
is that you have, so I can check latest text).
> 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.
I am neutral on this. I prefer defaults to be spelled out (there are
so many defaults to remember in life), but would hate to see another CLR.
> 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> I believe a common structure for a FOO-MIB is the following:
> JS> fooMIB (x.y.z)
> JS> |
> JS> +-- fooNotifications(0)
> JS> +-- fooObjects(1)
> JS> +-- fooConformance(2)
> JS> |
> JS> +-- fooCompliances(1)
> JS> +-- fooGoups(2)
> 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?
not from me
> 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))").
Agreed. No explicit rule against it. I do often suggest that they might
change it into just DisplayString... but no mandate indeed.