[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Target times for MIB Doctor Review
A couple of observations, trying to make it short.
- My proposal to make the MIB review part of the WGLC was targeting
minimizing the number of steps in the process. Yes, there may be more
than one WGLC iterations, but separating MIB review from WGLC risks to
create even more, because a document that underwent consistent changes
following a MIB Doctor review should go again through WGLC anyway. Let
us face it, the MIB Doctor review is in most cases a more serious
scrutiny than the one a MIB document gets during WGLC, so why not make
the two in one step?
- As for credit or recognition for the MIB review work, as observed it
may be important for the company sponsoring the reviewer more than the
reviewer. Mentioning the name of the MIB Advisor on the Web page of the
WG is another way of making more people happy at a low cost.
Regards,
Dan
> -----Original Message-----
> From: owner-mreview@ops.ietf.org
> [mailto:owner-mreview@ops.ietf.org] On Behalf Of David B Harrington
> Sent: Tuesday, January 31, 2006 10:17 PM
> To: 'Mreview (E-mail)'
> Subject: RE: Target times for MIB Doctor Review
>
> 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 (one
> > Bert> of the situations where some ADs put the doc in
> "expert review"
> > Bert> status as the substate in the I-D tracker) can take
> enourmously
> > Bert> 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 MIB
> > Bert> 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
> modules in
> > Dan> 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 subject
> > Dan> of proper compilation requirements by using the publicly
> > Dan> available tools, same as I-Ds can be checked by using idnits.
> > Dan> This would allow for consistent compilation by all authors and
> > Dan> lead the WG chairs to verify the syntax problems of
> MIB modules
> > Dan> submitted in their realms without 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
> >
> >
> >
> >
>
>
>
>