ietf
[Top] [All Lists]

Re: New root cause problems?

2005-05-10 09:41:59
Adding to this - and I'm not sure this is the kind of thing you were looking for, but it adds to the overall problem - is that IDs timeout after 6 months (which is fine), but that includes IDs that are in the RFC-Editor queue process too.

For example, look at the RFC-Editor queue site:

http://www.rfc-editor.org/queue.html

and try and look at a document that has a original submission date more than 6 months ago (from today)? The search link will fail, and this is a problem. Some of these are quite valuable (especially to their WGs), yet the IETF process eliminates their viewing.

Solution: perhaps an exception to the 6 month timeout should be made for every document upon entry into the RFC-Editor's queue such that every document remains until the document has been published as an RFC (or won't be).

At 09:36 AM 5/10/2005 -0400, Margaret Wasserman wrote:

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


cheers,
James

                                *******************
                Truth is not to be argued... it is to be presented.

                     Alas, few *truths* exist without the math.

                            ...all else is a matter of perspective

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf



<Prev in Thread] Current Thread [Next in Thread>