Re: Target times for MIB Doctor Review

[Harrie Hazewinkel <harrie@lisanza.net>]

On Jan 31, 2006, at 9:17 PM, David B Harrington wrote:
> Andy commented about the fact that a MIB reviewer gets no credit. I
> think MIB Doctors aren't very worried about getting credit, but it can
> make a difference to the company that sponsors them. I'd suggest that
> the MIB reviewer should get credit in the acknowledgements section of
> the document. That little acknowledgement, where the company's name is
> mentioned, can help our supervisors justify the (sometimes inordinate
> amount of) time we spend doing this work.

Recognition is not a direct concern, it is only nice.

However, I also have done MIB review that require a lot of fixes in the
wording of description clauses. In such occasions it might become easier
to edit the document directly instead of mentioning all proposals
for improved wording. In that case the reviewer becomes like being
an editor. I am not sure if all would agree on this, but I beleive
it is part of the task of the MIB reviewer to make the text also
correct (of course style might be subjective to reviewer also).
However, I also believe that in those occasions, the original editors
are at fault, since they do not provide a MIB module with proper
descriptions, for instance.

I am not sure how this can be avoided, but being earlier
part of the process it might help.

> For example, the MIB boilerplates require authors to list the Mib
> objects in the secuirty considerations. I suggest we add a SECURITY
> field to the OBJECT macro to identify whether an object is
> read-sensitive or write-sensitive, so the lists are unnecessary or can
> be generated automatically, and we ask the xml2rfc maintainers to
> automatically select the "read" versus "read-write" clauses in the
> security considerations based on the values of the field (or we
> provide static boilerplate that says if the SECURITY field contains a
> "write-sensitive" value, then it means this.... This way the authors
> can focus on the real security considerations - what might happen if
> the read objects are exposed, or the write objects are misconfigured.

I believe this is a good idea, but it would also mean SMI will
change. The question is than is it feasible?


Harrie