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 <margaret(_at_)thingmagic(_dot_)com>
Date: 2005/05/10 Tue PM 04:36:51 EEST
To: Brian E Carpenter <brc(_at_)zurich(_dot_)ibm(_dot_)com>,
ietf(_at_)ietf(_dot_)org
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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf