Re: New root cause problems?

Margaret Wasserman <margaret@thingmagic.com> Tue, 10 May 2005 21:41 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVcTu-00005N-Gf; Tue, 10 May 2005 17:41:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVcTs-000050-1H for ietf@megatron.ietf.org; Tue, 10 May 2005 17:41:32 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23907 for <ietf@ietf.org>; Tue, 10 May 2005 17:41:29 -0400 (EDT)
Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVcjF-0001UC-FG for ietf@ietf.org; Tue, 10 May 2005 17:57:26 -0400
Received: from [10.0.0.171] (account margaret HELO [10.0.0.171]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 364661; Tue, 10 May 2005 17:37:21 -0400
Mime-Version: 1.0
Message-Id: <p06200727bea6d6e3086e@[10.0.0.171]>
In-Reply-To: <20055101011.141174@bbprime>
References: <20055101011.141174@bbprime>
Date: Tue, 10 May 2005 17:41:01 -0400
To: Dave Crocker <dcrocker@bbiw.net>, Brian E Carpenter <brc@zurich.ibm.com>, ietf@ietf.org
From: Margaret Wasserman <margaret@thingmagic.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0
Cc:
Subject: Re: New root cause problems?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi Dave,

My impressions are, of course, based upon my own experiences...

I checked the time spent in the "In RFC Editor Queue" state for the 
last 10 RFCs that have been published from my I-D Tracker queue, and 
the details are included below.

According to my numbers, these ten documents spent a combined total 
of 201 months in the IETF process after -00 publication, which 
typically approximates when the WG accepted the work item (about 20 
months per document).  These documents spent a combined total of 50 
months in the "In RFC Editor Queue" state (an average of 5 months per 
document) or just about 25% of the total time from WG acceptance to 
document publication.  Therefore, given my own experience, I will 
stand by my impression that about 25% of the IETF's processing time 
for a given document is being spent in the RFC Editor Queue.

This number may not capture the full extent of the issue, as my 
longest-standing documents in the "In RFC editor Queue" state haven't 
had a chance to emerge yet.  I've only been an AD for about 22 
months, and I am responsible for 11 documents that have been in the 
RFC Editor Queue for over 6 months, including 2 that have been in the 
RFC Editor Queue for over a year.

Please note that I do understand that not all of the time spent in 
the "In RFC Editor Queue" state can be attributed to the RFC Editor, 
any more than all of the time spent "in the IESG" can be attributed 
to the IESG.  Some of this time is spent waiting to resolve 
references, waiting for author feedback on IANA issues, waiting for 
author response to AUTH48, etc.

However, I do believe that far too much time is being spent during 
the "In RFC Editor Queue" phase of the process.  This phase of the 
process is too opaque for me to identify the specific reasons why 
this is taking so long, but I strongly believe that we need more 
visibilityy into this part of the process and that we need to apply 
our efforts to making this period shorter.

Margaret

draft-carpenter-obsolete-1888:  (TOTAL TIME: 8 months)
	In RFC Editor Q:  2004-11-02 to 2005-04-26 (5-1/2 months)
	-00 Published:  August 2004

draft-ietf-dhc-agentopt-radius: (TOTAL TIME: 36-1/2 months)
	In RFC Editor Q:  2004-09-27 to 2005-02-24 (5 months)
	-00 Published: 2002-02-14

draft-ietf-dhc-auth-suboption:  (TOTAL TIME: 33-1/2 months)
	In RFC Editor Q:  2004-09-21 to 2005-04-06 (6-1/2 months)
	-00 Published: 2002-06-23

draft-ietf-dhc-dhcpv6-opt-nisconfig: (TOTAL TIME: 32 months)
	In RFC Editor Q:  2004-06-02 to 2004-10-12 (4-1/2 months)
	-00 Published:  2002-02-17

draft-ietf-dhc-rapid-commit-opt:  (TOTAL TIME: 16 months)
	In RFC Editor Q:  2004-11-02 to 2005-04-06 (5 months)
	-00 Published:  2003-11-28

draft-ietf-dhc-reclassify-options:  (TOTAL TIME:  11 months)
	In RFC Editor Q:  2004-07-12 to 2004-12-03 (4-1/2 months)
	-00 Published:  2004-01-05

draft-ietf-dhc-subscriber-id:  (TOTAL TIME:  20 months)
	In RFC Editor Q:  2004-09-16 to 2005-03-22 (6 months)
	-00 Published:  July 2003

draft-ietf-dhc-vendor: (TOTAL TIME:   14 months)
	In RFC Editor Q: 2004-07-12 to 2004-11-04 (4 months)
	-00 Published:  September 2003

draft-ietf-eap-rfc2284bis: (TOTAL TIME: 17 months)
	In RFC Editor Q:  2004-02-29 to 2004-06-22 (4 months)
	-00 Published:  January 2003

draft-ietf-ipv6-deprecate-site-local:  (TOTAL TIME:  13 months)
	In RFC Editor Q:  2004-04-16 to 2004-09-21 (5 months)
	-00 Published:  2003-08-16

At 10:01 AM -0700 5/10/05, Dave Crocker wrote:
>>   The time to move from approved
>>
>>   I-D to RFC is often a significant percentage (perhaps averaging 20%
>>   of more?) of the time required to develop and publish a specification.
>
>
>Let's say that it averages 4 months to go from IESG approval to RFC
>publication.  (I'm choosing that number because it is big enough to indicate a
>problem, but small enough not to insult the RFC Editor.)
>
>Using your estimate of 20% for this step, that means that working groups
>average 16 months to do their part of the work, from start to finish.
>
>However that does not match either general impression or that statistics that
>were produced awhile back.
>
>If we averaged 16 months for working groups to go from start to finish,
>we would not have serious and consistent complaints that the IETF is too
>slow.
>
>So the actual, incremental delay for the RFC publication process is
>probably no worse than 10% and I wouldn't be surprised if the real
>statistic were more like 5%.
>
>As much as it is worth trying to make everything better, it is difficult
>to see a 5 or 10% overhead to the process as being one of our strategic
>problems.
>
>   d/
>   ---
>   Dave Crocker
>   Brandenburg InternetWorking
>   +1.408.246.8253
>   dcrocker  a t ...
>   WE'VE MOVED to:  www.bbiw.net


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf