RE: Target times for MIB Doctor Review

["David B Harrington" <dbharrington@comcast.net>]

Hi,

I dislike the idea of a 30-day window for Mib review, unless the
number of Mib Doctors is increased significantly. 

I agree mostly with the suggestions that have already been made.

Getting a MIB Doctor involved earlier, such as at charter approval
time, lets the MIB Doctor know earlier that they need to learn about a
particular technology, an early review of the MIB can alert the MIB
Doctor to how knowledgeable (or not) the MIB writer is, and the MIB
Doctor can ensure that the MIB writer knows about the available tools
earlier. 

I don't agree with making the review part of WGLC. Making MIB review
part of WGLC keeps the MIB in the WG before it gets to AD/IESG level.
However, my experience in IEEE showed that doing this can lead to the
MIB Doctor being asked to review multiple revisions of the MIB, since
there can be multiple WGLCs, and this can greatly increase the work
load for the MIB Doctor. Making the review something after WGLC limits
the number of reviews expected from the Mib Doctor.

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.

I like Mike's suggestion of letting the WG find a reviewer, because it
might widen the pool of MIB Doctors, making the job easier on the rest
of us. This might also be combined with the "credit" issue if a list
of approved reviewers is prominently displayed on the O&M web site,
and potential reviewers know they will get credit for doing the work.
It might help if the MIBs we have reviewed is displayed under our
names on the web site, so somebody looking for a reviewer can quickly
determine our individual areas of expertise, and (if current
assignments are listed) whether we're already overly committed, and
the AD can see if we're being active or not.

I believe we should increase the level of automation used in writing
and checking MIB modules for compliance to all the CLRs (er,
guidelines). XML2RFC automates the selection of the most current
boilerplates, where the boilerplate is static; Unfortunately, the O&M
boilerplates are often not static and that makes it much harder to
automate.

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 agree that requiring a MIB module to achieve a minimum severity
level of a specific compiler made available for free via the O&M web
site would simplify reviews. For commercial compiler vendors who
dislike the competition of a free IETF-recommended compiler, they
should compete based on value-add features in their products above and
beyond the basic requirement for IETF standardization.

I suggest each AD should be required to recruit a number of MIB Doctor
trainees from their area, to provide reviews of MIB documents in their
area (preferably within a 30-day window), and the O&M AD's MIB Doctors
can help when the load exceeds the capacity of the area Mib Doctors.
The area MIB Doctors are likely to already understand the technologies
of the area. All the area MIB Doctors should be approved by the O&M
AD, and trainees should be willing to provide reviews with support
from an already-approved MIB Doctor until they are approved. An
additional approach compatible with Dan's suggestion would be to have
the area MIB Doctors do a review as part of WGLC, and the 30-day
window for review and the window for author response should be under
the eyes of the WG chairs and AD, before it ever gets to AD/IESG
review level. The O&M senior MIB Doctors could do a simpler
second-level review at AD/IESG level to verify that the area MIB
Doctors haven't let any (uncommon) problems slip through.

David Harrington
dbharrington@comcast.net

 

> -----Original Message-----
> From: owner-mreview@ops.ietf.org 
> [mailto:owner-mreview@ops.ietf.org] On Behalf Of C. M. Heard
> Sent: Tuesday, January 31, 2006 10:43 AM
> To: Mreview (E-mail)
> Subject: Re: Target times for MIB Doctor Review
> 
> >>>>> On Tue, 31 Jan 2006, Wijnen, Bert (Bert) wrote:
> Bert> One of the things being discussed is that MIB doctor review
> Bert> (one of the situations where some ADs put the doc in "expert
> Bert> review" status as the substate in the I-D tracker) can take
> Bert> enourmously long.
> Bert> 
> Bert> The main reason is that it is often difficult to find a
> Bert> reviewer, and then the doc sort of by defaults ends up in my
> Bert> queue (which is too long already).
> Bert> 
> Bert> So the suggestion is that we would like to have a target of
> Bert> MIB Doctor review to be done within 30 days of the request.
> Bert> 
> Bert> I want to hear from you how to deal with that?
> 
> >>>>>> On Tue, 31 Jan 2006, Romascanu, Dan (Dan) replied:
> Dan> 2. MIB advisors should be assigned to WGs who have MIB
> Dan> modules in their charter.
> 
> YES!  And it should be the responsibility of the people who want to
> get the WG charter approved to find the advisor/reviewer.  The
> advisor/reviewer should be someone acceptable to the OPS-NM AD, but
> there shouldn't be any other a priori restrictions.
> 
> I really think that this step is the key.  It can be implemented
> today, even without #1 below (although that, too, is a good idea).
> 
> Dan> 1. Provide MIB compilation and CLR checking tools publicly
> Dan> available on the IETF Web site. MIB submissions should be
> Dan> subject of proper compilation requirements by using the
> Dan> publicly available tools, same as I-Ds can be checked by
> Dan> using idnits. This would allow for consistent compilation by
> Dan> all authors and lead the WG chairs to verify the syntax
> Dan> problems of MIB modules submitted in their realms without
> Dan> being MIB experts.
> 
> When I did MIB reviews I often found that the stuff that was largely
> mechanical (items 1-9 in the Appendix A of RFC 4181) took up an
> enormous amount of time.  Having automated tools to do as many of
> those checks as possible AND pushing the responsibility back on the
> authors to prove that those automated checks had been done would
> greatly reduce the amount of effort required from a reviewer and
> would allow him or her to concentrate on the non-mechanical stuff.  
> I think this would make the reviewing job more rewarding (or at
> least less tedious), and that should help get more people willing to
> be reviewers.
> 
> One political issue that I see here is that the IETF will end up
> with an "official" MIB checker/compiler, and that may raise cries of
> "foul!" from some vendors.  I think the right answer to that is to
> say "tough".
> 
> Good work, Dan.  I hope the IESG goes for your idea.
> 
> Mike
> 
> 
> 
>