Stringency (RE: 12 problems)

James Kempf kempf at docomolabs-usa.com
Thu Jan 16 10:52:49 CET 2003


Whoops! Cancel that analysis. If the number is "months per RFC", then it
actually showed an *improvement* between 1995 and 2000.

            jak

----- Original Message -----
From: "James Kempf" <kempf at docomolabs-usa.com>
To: "Henning Schulzrinne" <hgs at cs.columbia.edu>; "Harald Tveit Alvestrand"
<harald at alvestrand.no>
Cc: <john.loughney at nokia.com>; <problem-statement at alvestrand.no>
Sent: Thursday, January 16, 2003 10:12 AM
Subject: Re: Stringency (RE: 12 problems)


> Dividing the delay by the number of RFCs gives an approximate estimate of
> productivity, how many months it takes to approve an RFC. This number does,
> indeed, show a bit of a decline between 1995 and 2000, with the steepest
decline
> happening between 1999 and 2000. The productivity declined between 1993 and
> 1994, but I assume that was due to the sharp jump in the number of RFCs
between
> the two years, it recovered again in 1995 but then started to slide:
>
> 1993    0.177
> 1994    0.105
> 1995    0.172
> 1997    0.139
> 1998    0.133
> 1999    0.126
> 2000    0.010
>
> Might be interesting to weigh these with the number of participants in working
> groups, to see if that also had an effect.
>
>             jak
>
> ----- Original Message -----
> From: "Henning Schulzrinne" <hgs at cs.columbia.edu>
> To: "Harald Tveit Alvestrand" <harald at alvestrand.no>
> Cc: <john.loughney at nokia.com>; <problem-statement at alvestrand.no>
> Sent: Thursday, January 16, 2003 3:18 AM
> Subject: Re: Stringency (RE: 12 problems)
>
>
> > http://www.cs.columbia.edu/~hgs/internet/IMR has the data and the .tcl
> > scripts. The measurements I reported were:
> >
> > year number of RFCs sampled  avg. delay (months)
> > 1993 31                      5.5
> > 1994 80                      8.4
> > 1995 61                     10.5
> > 1996 96                     12.4
> > 1997 103                    14.4
> > 1998 147                    19.6
> > 1999 157                    19.8
> > 2000 158                    24.2
> >
> > Things change a bit on the tail end if we ignore all RFCs with duplicate
> > titles, where association with I-Ds is likely to be iffy:
> >
> > 1993 27 5.6
> > 1994 73 8.0
> > 1995 50 8.8
> > 1996 90 12.2
> > 1997 98 12.9
> > 1998 123 15.0
> > 1999 147 18.8
> > 2000 139 19.1
> >
> > http://www.cs.columbia.edu/~hgs/internet/id-rfcyear.png
> >    Number of RFCs and I-Ds published each year, based on IMR reports from
> > the year 1991 and later
> >
> > http://www.cs.columbia.edu/~hgs/internet/rfcyear.png
> >    Number of RFCs published, also ratio to IETF attendance
> > (Ignore the year 2000 dip, as that's based on year-to-date statistics)
> >
> > Harald Tveit Alvestrand wrote:
> > >
> > >
> > > --On torsdag, januar 16, 2003 06:28:32 +0200 john.loughney at nokia.com
wrote:
> > >
> > >> Harald,
> > >>
> > >> Any stats of how long I-Ds take from WG Last Call completed to being
> > >> shipped to the RFC editor?  If this was examined over time, we may have a
> > >> better metric to see about IESG stringency ... If the this time has been
> > >> ballooning - especially in relation to other parts of a document's
> > >> lifetime, then we should assume there is some problem.  If it is not
> > >> dramatically increasing, then perhaps stringency would not be a problem.
> > >
> > >
> > > Unfortunately the stats in the ID-tracker haven't been around long
> > > enough to make sensible trend lines.
> > > A few years back, Henning Schultzerinne made scripts chewing through the
> > > Internet Monthly Report (http://www.ietf.org/IMR/) to generate stats on
> > > the time between -00 version publication, IETF-wide Last Call and RFC
> > > publication - that's the source of the frequently quoted statistic that
> > > "time has gone from 6 months to 2 years".
> > >
> > > I've CCed him on this message; if he still has the scripts, and is
> > > willing to share, we could get at least those numbers back again....
> > >
> > >               Harald
> >
> >
>
>



More information about the Problem-statement mailing list