Subject: Re: Re: New root cause problems?

From: John Loughney <[email-masked]>
Date: Thu, 12 May 2005 14:35:21 +0300

Margaret,

This is a huge problem, IMO.  If you couple your point with James sub-point about drafts expiring in the RFC editors' queue, you really do have a mess.

I often have to discuss with other SDOs on IETF drafts; often they need an RFC number for their own processes.  It might be enough to say to some IETFers to look at the RFC Editor's Queue, but it is not a reasonable way to manage things inter-SDO.

I am a co-author of a draft that was initially requested in August 2003, by 3GPP for Release 5, but it had not been accepted yet as a WG item, so it was not included in 3GPP Release 5.  The authors worked hard to get the document done, and the current version is dated August 12, 2004.  It is currently listed in the RFC Editors Queue with the note "Fast Track requested." It is in the AUTH = Awaiting Author Action state, but all of the authors signed off on it on March 23rd.  I'll admit that the authors made a bit of a mess during AUTH48 because we had quite many changes requestes, but that should only account for about 1 month of delay.

I'm actually catching a lot of grief about this via private mail because it looks like incompetence to folks outside of the IETF.  I really think these type of things really strains any credibility that the IETF has.

John Loughney
> From: Margaret Wasserman <[email-masked]>
> Date: 2005/05/10 Tue PM 04:36:51 EEST
> To: Brian E Carpenter <[email-masked]>,  [email-masked]
> Subject: Re: New root cause problems?
> 
> 
> I have one new "root cause" issue that I don't believe was included 
> in the original Problem Statement:
> 
>      It takes too long to publish an RFC after final approval.
> 
> It currently takes several months for an RFC to be published after it 
> is approved by the IESG.
> 
> This results in several problems:
> 
> - RFCs come out much later than they should, contributing greatly to 
> the perception that the iETF is slow.  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.
> - Stable references are not available until months after a 
> specification is fully approved, resulting in ambiguity about the 
> status of a document and encouraging the use of I-D names as 
> references, thus blurring the distinction between WG I-Ds and 
> approved specifications.
> - Too many changes are made to documents after WG and IESG approval 
> (copy editing, changes to reflect updated thinking/terminology, 
> etc.).  These changes are often not reviewed or approved by the WG or 
> the community.
> - Some RFCs are already out-of-date by the time they are published. 
> The document then contains the RFC publication date, which may result 
> in a mistaken impression about when the IETF held a specific view or 
> encouraged a particular practice.
> 
> I believe that the IETF should consider modifications to our document 
> handling process to reduce or eliminate the delay in publishing 
> approved specifications.
> 
> Margaret
> 
> 
> At 2:36 PM +0200 5/10/05, Brian E Carpenter wrote:
> >Having finally read the list traffic up to date, I have a question.
> >
> >Can anybody identify a *new* "root cause problem" at the same level
> >of abstraction as those identified in RFC 3774? Or is it the case
> >that (at that level of abstraction) we have only been re-discussing
> >the RFC 3774 problem set?
> >
> >(Please try to be succinct... or change the subject header if you want
> >to change the subject.)
> >
> >Thanks
> >    Brian
> >
> >
> >
> >
> >_______________________________________________
> >Ietf mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/ietf
> 
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
> 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: John Loughney <[email-masked]>
Date: Thu, 12 May 2005 14:42:21 +0300

Margaret,

> At 10:50 AM +0200 5/11/05, Brian E Carpenter wrote:
> >But that gives very limited insight into what is holding it up, except
> >for a few cases. If it's in EDIT state you get no useful information about
> >issues and progress, for example.
> 
> Also, if there is the equivalent of the I-D tracker for the RFC 
> Editor Queue (where correspondence and major state transitions for a 
> document are captured and can be seen later), I am not sure where to 
> find it.  The RFC editor queue is a text document that only seems to 
> capture the current state of the document (EDIT, AUTH48, etc.).

I'm personally not to sure about the accuracy of some of those states.  I found a couple that I am personally involved in that are still listed as in the AUTH state, but where all of the authors have signed off on the document & the RFC Editor has confirmed that we have signed off on it.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 16 May 2005 07:03:04 -0700 (PDT)

Last year, Tim Simcoe, now on the faculty at the Rotman School of
Management at the University of Toronto, completed a study entitled:
"Delays and de Jure Standards: What Caused the Slowdown in
Internet Standard Setting?" For those interested, here are pointers to the
work (which is continuing):

http://groups.haas.berkeley.edu/bpp/phd/simcoe/profile.htm
http://www.rotman.utoronto.ca/strategy/research/working%20papers/Simcoe%20-%20Delays.pdf

---

From: Bruce Lilly <[email-masked]>
Date: Wed, 25 May 2005 12:55:42 -0400

>  From: Brian E Carpenter <[email-masked]>

> Dave Crocker wrote:
> > use the median, rather than the mean.  
> 
> I'm actually more interested in the mode, I think, but first,
> some actual data would be good.

Agreed.  And I would add that other than mode it matters what is
actually being measured -- in the case of 0 documents for IESG
review in 8 years it makes a wee bit of difference to some measures
if the statistic is presented as years/document or documents/year...
On the other hand, the mode isn't very informative if the sample
size is small.