[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Target times for MIB Doctor Review



Thanks for the good feedback we have seen sofar.
Some more background.

- The IESG retreat we just finished was about "IESG efficiency"
  with some touch of "IETF effieciency", but focused on the things
  that happen at the end of the process (I.e. AD review,
  IETF Last Call, IESG review, IESG-issues followup/closure) just
  before final IESG approval.
  We know there are wider issues, but we decided to start with the
  places where we (ADs/IESG) are (or are at least perceived to be)
  the bottleneck or the cause.
- Of course there are all sorts of things that can be done earlier
  as many of you suggested. In fact, we do have a number of WGs
  outside the OPS area that have assigned MIB/SNMP advisiors from
  our MIB doctors group/team. Yet, also MIB documents that come
  from those WGs often have had (more or less serious) flaws/issues
  that needed to be fixed (or I think we as MIB doctors do believe so).
  We can try and find the reasons why that is... there are various.
- We can also wonder if we indeed always MUST try to understand the
  technology being modeled. To some extend yes, otherwise we cannot
  evaluate. But I personally do not believe we have to go and study
  the technology to such a level of detail to rty and see if we can
  come up with a better design (certainly not at or after WGLC).
- W.r.t. Juergens question about the actual time distributions, i.e.
     What is the time distribution to
     a) finding a reviewer,
     b) getting the initial review,
     c) going through the followup work? 
  I must admit that I have not investigated and not kept track of
  such things in enough detail and consistency that I can easily
  figure it out.  Here are some rough indications though:
  a) As you might have noticed in my original email, often I do not
     find a reviewer. So the MIB document ends up on my plate...
     (aside: that often means long delays. It also means if it gets
      too bad with my queue that my reviews are much lighter than
      when I do have more time. Sometimes after a wait of more than 
      30 days, I try again to get a reviewer (other than myself).
  b) In general, when I do find a reviewer, then I try to get a soft
     commitment (i.e. more like a promise to try) for a deadline.
     Most reviewers promise to do so in 2 weeks. Some promise to do
     so faster, others want 3 weeks or sometime a bit more.
     Many live up to their promise reasonably well. Not all. I then
     start prodding, and some of you may have found me a bit nasty at
     times (specifically if you answered with vague promises without
     dates; I rather have you tell me to not be wiliing to do a review
     than to make me think I have a reviewer but have no idea when
     the review would complete)
  c) That varies VERY WIDELY. Some have been longer than a year.
     A few have been very quick. Of course it depends a lot on the type
     of things we find. Some authors/WGs are just not responsive,
     but in several cases, there was serious changes and so new WGLC etc
     was needed, and we know such takes time.
- In my message I was mainly concentrating on the time required for 
  a)+b). I would like that to be no more than 30 days. We are not meeting
  that at all. The average is probably closer to 3 months than to 30 days.
  And that is just not acceptable. And I wonder if we (small group of
  MIB doctors) have the right to block MIB work because we feel the quality
  is not good enough while we seem not be able to cough up the cycles
  (or to recruit the cycles, whihc is my fault) to do timely review or
  do timely guidance/helping/advising (i.e. we just do not have enough
  MIB doctors to assign one to avery WG that does a MIB module).
  So I was kind of getting into a mood "If we (MIB doctors) cannot deliver
  in 30 days, for a+b, then we have no right to complain and should accept
  MIB modules of lesser quality, maybe even MIB modules with bugs in it".
- For now, our thought process in IESG has been to try and define "targets"
  for various pieces of the process. The target we discussed for "expert
  review" (MIB doctor review is considered expert review) is 30 days now.
  So no hard rule, but a target against which we try to measure (we will
  be doing more measuring of document progress through the system).

So with that, we as MIB doctors need to find ways to try and achieve that.
The suggestions that have been made in this thread are useful. 
We probably need to discuss and work out some details and see if we 
can agree. I think we must be prepared to help my sucessor. Even if we
decide that we are going to structure MIB-doctor review such that each AD
or WG must directly try to find a MIB doctor/expert for themselves, even
then we need to see how we can make that work. Otherwise, the end result
is that MIB documents will come up on the IESG agenda and then my
successor will have to decide to do MIB doctor review at that time or
let it pass at possible lower qaulity.

Bert
> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]
> Sent: Tuesday, January 31, 2006 12:46
> To: David B Harrington
> Cc: 'Wijnen, Bert (Bert)'; 'Mreview (E-mail)'
> Subject: Re: Target times for MIB Doctor Review
> 
> 
> On Tue, Jan 31, 2006 at 03:30:03PM -0500, David B Harrington wrote:
> > Hi,
> > 
> > I don't agree with
> > > Perhaps there should be mechanism where a standards-track document
> > > automatically becomes an informational (or even historic 
> :) document
> > > if the authors do not followup on IESG/AD/... comments withing a
> > given
> > > time period once a document is in the IETF publication machinery.
> > 
> > Many people don't care about the status of an RFC, as long 
> as it is an
> > RFC. Look at RFC3164 for example; there are a number of vendors
> > touting they have an RFC3164-compliant implementation of syslog. But
> > RFC3164 is an Informational document that only "describes 
> the observed
> > behavior of the [BSD-style] syslog protocol"; it is not an IETF
> > standard specification, and it turns out that many 
> implementations of
> > BSD syslog are totally incompatible except that their messages start
> > with a <PRI> field.
> > 
> > Having a poorly-written standards-track MIB module to be 
> published as
> > Informational or Historic RFC is much simpler for authors 
> than meeting
> > the rigors of passing MIB Doctor review. 
> 
> Sure, the world at large does not care about RFC status levels. I
> fully agree with that observation.
> 
> But then again, I find it important to include the authors in the
> consideration when we talk about overall MIB review times. What you
> are saying is that if authors do not follow up in a reasonably amount
> of time, the document simply should not be published at all and just
> be dropped.
> 
> Bert, can you shed some light what the actual time distributions look
> like? What is the time distribution to a) finding a reviewer, b)
> getting the initial review, c) going through the followup work? It is
> hard to tell where to optimize without knowing the facts.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
> 28725 Bremen, Germany
>