Subject: RE: Allocating RFC numbers at time of approval

From: [email-masked]
Date: Mon, 19 Sep 2005 23:59:20 +0300

Allison,

I favor this approach.  As an author and a chair of documents that have
spent a long time in 
the RFC Editor's queue, I have gotten many questions related to these
documents.  You can
imagine a non-IETF participant who is interested in a document that says
'This document
expires January 1, 2005' but yet has no RFC.  How are they to know that
the document
is in the RFC Editor's queue and that the draft is still considered
'active'?

John

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext Allison Mankin
>Sent: 19 September, 2005 09:03
>To: [email-masked]
>Cc: [email-masked]; [email-masked]
>Subject: Re: Allocating RFC numbers at time of approval 
>
>I've been thinking about this for some time, motivated by the 
>fact that very big fraction (need to do the numbers) of TSV 
>documents have someone who requested expedited publication or 
>someone who sent mail of concern about delay in the RFC 
>number, about delay in the RFC number appearing in the IANA registry.
>
>I have in mind the following outline, chronologically (with 
>details needing filling in...)
>
>- IESG approves document, which may include some
>   "Notes to the RFC Editor" - text changes resulting
>    from the review or late Last Call
>
>- IESG obtains the next technical publication designator
>   for use ("RFC number") and holds it (or obtains it
>   at the time below - this is an implementation detail,
>   as is how the IESG/Secretariat actually take the
>   actions in this outline).
>
>- IANA performs IANA actions for the document, which
>  are technically complex and have give and take, so
>  they begin as early as the document is technically
>  stable (before it's possible to put the number in
>  the registry) - IANA places i-d placeholder.
>
>- The two month timeout on appeals runs out (document approval
>  is now final).
>
>- technical publication designator can now be assigned to
>  document and given to IANA for its registry information.
>
>At this time:  an new internet-draft should be prepared with 
>the string - draft-ietf-<wg>-<orginalrestofstring>-rfc####-00.txt
>(or something like that).
>
>Instead of the existing i-d headers, where the expiration date 
>quite bothers outsiders, because an approved draft may not be 
>an RFC before its original (now meaningless to IETF) expiration:
>
>OLD:
>INTERNET-DRAFT
>September 5, 2005
>Expires: March 5, 2006
>
>The new draft would use:
>
>NEW:
>RFC-TO-BE ####
>Approved September 30, 2005
>Expires at RFC Publication
>
>This new i-d would not be as beautiful as the RFC publication, 
>but it would incorporate the text changes and would be 
>technically stable (we can consider this also as pushing back 
>on all but the biggest and most urgent of late technical 
>fixes, asking them to be new documents).
>
>The IANA would be given the RFC number at that two-month date 
>by the IESG and given more urgency about putting those numbers 
>in the registry RIGHT AWAY.
>
>As Brian says, support for this would have to come from a 
>reasonable swathe of people in the IETF, but if a lot of 
>chairs like it, that is a good start :)
>
>
>
>    
>
>

---

From: Geoff Huston <[email-masked]>
Date: Tue, 20 Sep 2005 09:34:26 +1000

Let me explain my frustration here that lead to my previous outburst.

This entire thread appears to be about developing more process
relating to the common perception of the extended period of time
that a document spends in the RFC Editor queue, and devising
some additional referential structure to allow documents that are
residing in that state to be externally referenced in some form or
fashion. The thread  appears to be honing in on adding even more
referenceable document states which, invariably, will
extend the amount of time that documents spend in this state.

If we really are interested in looking at the root cause then we should be 
looking
at how the publication process can simply take less time (which is what I see
with the draft proof-reading effort, and the IAOC-related work in overseeing
various aspects of the performance of this work) rather than spending our
collective energy exploring how we can add yet further complexity to a
process that is obviously under strain already.

regardes,

    Geoff