Subject: Allocating RFC numbers at time of approval

From: [email-masked]
Date: Mon, 19 Sep 2005 11:29:41 -0400

> If people want this to change, it means changing another long-time
> practice by allocating RFC numbers at the time of approval.

That might be a very good thing.  I have a number of interactions
with another standards body in which speed of IETF publication of
RFCs is an issue.  The crucial external requirement is a stable
reference designator - having an RFC number prior to publication
could be quite useful by taking the RFC Editor out of the critical
path to that designator, thereby enabling publication of other
standards that want to reference RFCs (to-be).

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Monday, September 19, 2005 4:26 AM
> To: Scott Bradner
> Cc: [email-masked]
> Subject: Re: when does the RFC2026 advancement timer start? 
> IESG approval, or publication as an RFC?
> 
> Scott Bradner wrote:
> >>but when does the timer start?  with IESG approval, or at 
> publication as an RFC?
> > 
> > 
> > a long-time question - the only date that shows up in the index and
> > document is the publication date so there is no way to know 
> by looking
> > at the RFC what the approval time was so in practice the publication
> > date is the practical one to use
> 
> If people want this to change, it means changing another long-time
> practice by allocating RFC numbers at the time of approval. 
> That way the
> RFC index could carry an "approved date" as well as a 
> publication date.
> 
> That's a requirement the IETF would have to express very clearly
> for it to happen.
> 
>      Brian
> 
>

---

From: [email-masked] (Scott Bradner)
Date: Mon, 19 Sep 2005 11:32:11 -0400 (EDT)

this only works if indeed the reference is stable - i.w., will not
change in any significant way before actual publication - otherwise
the other stds body may agree to use a technology that changes out
from under them

---
>From [email-masked]  Mon Sep 19 11:29:55 2005
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Allocating RFC numbers at time of approval
Date: Mon, 19 Sep 2005 11:29:41 -0400

Thanks,
--David

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 19 Sep 2005 11:52:58 -0400

>standards that want to reference RFCs (to-be).

For at least one reason why that doesn't work well, see RFC 3333 or 
perhaps 3350.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 19 Sep 2005 10:17:01 -0700

This can also be done with allocating the number and the name "PRERFC 
4999" but not the name "RFC 4999". From that date until the RFC 
issues (or, in those rare cases, when some says "RFC 4999 will never 
issue"), people can refer to the document as "PRERFC 4999".

In fact, they should even be able to find a file called 
"prerfc4999.txt" in an IETF-sponsored web/FTP site that says:

    This is a pre-RFC document. When an RFC is eventually issued,
    it will look very much like draft-ietf-somewg-someprot-07.txt,
    but it won't look exactly like it, so don't rely on the exact
    wording yet.

    For information on the IESG's comments on this document that
    will affect the content of the eventual RFC, see
 
<https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19876>. 

    For information on the status of this document in the RFC
    Editor's queue, see <http://www.rfc-editor.org/queue/prerfc4999>.
    The RFC Editor estimates that this document will become an RFC on
    approximately February 1, 2006.

When RFC 4999 issues, the text of prerfc4999.txt on the IETF site turns into:

    This document no longer exists; please see RFC 4999 for what it became.

This lets people know the eventual RFC number ahead of time, gives 
them a way to resolve it into its original Internet Draft, lets them 
see the expected changes from the IESG's perspective, and lets them 
see what is happening to the document at the RFC Editor.

--Paul Hoffman, Director
--VPN Consortium

---

From: James Carlson <[email-masked]>
Date: Mon, 19 Sep 2005 13:32:38 -0400

> "prerfc4999.txt" in an IETF-sponsored web/FTP site that says:
[...]
>     This document no longer exists; please see RFC 4999 for what it became.

Does that differ significantly from the existing behavior of I-Ds?

I'd expect that if anyone can make good use of an RFC number before
the final text is available, the same purposes would be served by the
I-D name as well.

> see what is happening to the document at the RFC Editor.

I think it just obscures the fact that, until the RFC is published in
immutable form, it can (and sometimes will) mutate.  If others are
basing standards on mutating documents, then I think that's very much
the same problem as having IETF standards-track documents that have
normative references to I-Ds.

I agree that there can be delays and that it's obviously causing some
people some pain, but I'm not sure that this particular cart/horse
ordering exercise fixes the root problem.

-- 
James Carlson, KISS Network                    <[email-masked]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 19 Sep 2005 16:50:27 -0400

> the other stds body may agree to use a technology that changes out

We can optimize for the normal case -- in the (on average, unlikely)
event that a significant flaw is discovered between IESG approval and
publication, we can publish a placeholder explaining the failure and
assign the document a new RFC number.  Other organizations referencing
our specs would then have to respin their documents, of course, but
they'd have to do that anyway.

This closely resembles what we have to do if a flaw is discovered after
publication.

					- Bill

---

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

prerfc?  um - this is getting _really_ silly if you ask me.

Publish the damn things. Let the RFC editor figure out when a number is 
allocated and let them just get on with their job.

Now can we drop wgchairs off this thread - please?

thanks,

    Geoff

At 03:17 AM 20/09/2005, Paul Hoffman wrote:
>4999" but not the name "RFC 4999". From that date until the RFC issues 
>(or, in those rare cases, when some says "RFC 4999 will never issue"), 
>people can refer to the document as "PRERFC 4999".
>
>In fact, they should even be able to find a file called "prerfc4999.txt" 
>in an IETF-sponsored web/FTP site that says:
>
>This lets people know the eventual RFC number ahead of time, gives them a 
>way to resolve it into its original Internet Draft, lets them see the 
>expected changes from the IESG's perspective, and lets them see what is 
>happening to the document at the RFC Editor.
>
>--Paul Hoffman, Director
>--VPN Consortium
>

---

From: Dean Willis <[email-masked]>
Date: Fri, 23 Sep 2005 16:06:04 -0500

> ordering exercise fixes the root problem.

Some pain? It's more like a two-year delay!

A quick scan through the RFC editor queue shows documents that have  
dates of 2002 and 2003 . . .

Admittedly, there are probably "dependency issues", but that really  
shouldn't make the documents unreferencable.

Why should ITU have to re-issue one of their specifications three  
years after it is published just to account for a name change in one  
of our specifications that resulted from the clearance of a  
dependency issue in our specification family?

--
Dean

---

From: James Carlson <[email-masked]>
Date: Fri, 23 Sep 2005 17:32:19 -0400

> dates of 2002 and 2003 . . .

Indeed.

> shouldn't make the documents unreferencable.

Are you absolutely certain that's the case?

If the dependency shakes out such that the dependent document is
*withdrawn* rather than published, doesn't that cause a problem for
the other documents?

> dependency issue in our specification family?

I guess I don't see how referring to a document that might never be
published at all, or when it is published might end up with
significant changes, is really a step in the right direction.  That's
why I referred to it as a cart/horse ordering issue.

Suppose we have a "Foo" protocol that can run over TCP or a new "Bar"
transport.  Foo has normative references to both TCP and "Bar."  The
ITU decides it wants to "standardize" the use of Foo over Bar, and
refer to those documents.  However, due to some unforseen problem, Bar
is withdrawn.

We then edit Foo so it runs over TCP alone and continue with the
publishing process.  The ITU ends up with a perfectly stable but
completely unusable (to them) set of references.  Was that a gain?

If anything, I think the ITU documents ought to be in the same
dependency boat with the RFCs on which they depend.  Fixing the
latency ought to be the high-order bit here, not stepping around it by
providing quasi-stable reference points and effectively pretending
that the problem doesn't exist.

---

From: Ned Freed <[email-masked]>
Date: Fri, 23 Sep 2005 15:01:48 -0700 (PDT)

> *withdrawn* rather than published, doesn't that cause a problem for

Then the other documents need to either be revised or themselves
withdrawn. 

It is entirely possible, with the current system, for a published document to
be found to be so egregiouly broken that it has to immediately be reclassified
as "historic". I fail to see how this differs dramatically from the case where
a document is withdrawn immediately prior to first publication. Both cases
break references unexpectedly. But more to the point, past experience indicates
very strongly that both cases will be quite uncommon.

> refer to those documents.  However, due to some unforseen problem, Bar

Again, similar things can happen in our current process. I've seen
several cases where something got changed at some point but nobody
noticed how the change impacted some other dependent document.

The solution is to fix these things as the arise, not to introduce (or retain)
significant overhead in the process to try and prevent rare events from
occurring.

> completely unusable (to them) set of references.  Was that a gain?

In this specific case, of course not. The gain lies elsewhere. You might as
well argue that some beneficial drug should never be used because in rare cases
it has some minor side effects.

> that the problem doesn't exist.

No one is pretending the problem doesn't exist. What people are saying is that
the process works best when it is optimized for the most common cases. And the
need for early RFC number assignment has become a common case, like it or not.
Right now we're effectively optimizing for problems that arise only rarely, and
the pain this is causing is considerable.

				Ned

---

From: James Carlson <[email-masked]>
Date: Fri, 23 Sep 2005 18:24:10 -0400

> the pain this is causing is considerable.

It seems quite strange to retain the dependency handling in one case
(for RFCs themselves) but just toss it overboard for other documents
(ITU).  The two kinds of dependencies seem more alike than different.

One of the things I think we're dancing around here is the
immutability of RFCs once published.  If we're certain that these
problems happen so rarely that they're not of any real concern, then
I'd rather see the early-assignment mechanism used everywhere rather
than just for the ITU.  This implies that we don't track dependencies
at all for documents going through the RFC editor.  Instead, we just
assign RFC numbers as soon as needed, and allow each document to be
published when it is done with the editing process.

If this means that some RFCs get published with dangling (not yet
published) normative references, then that fairly represents the state
of the system that the rest of the world must somehow deal with.

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 26 Sep 2005 09:48:07 -0400

Hi,

The problem is not ITU-specific; I also see the problem with the IEEE.
If you want to bring it closer to home, then I also see it in the
Bridge WG.

The BRIDGE WG has dependencies between documents. One of the documents
was approved months ago, but only recently was the RFC# assigned.
While we waited, the two other I-Ds had to keep referring to the I-D
that was approved rather than the RFC#. The dependent documents have
already been through IETF Last Call. Now somebody has to go change
those document references, and because the WG cannot change the
doucments any longer, that means the RFC Editor has to do it. If the
RFC# was assigned when the first document was approved, the WG editors
could have updated the references in the dependent documents, thus
reducing the work that needs to be done by the RFC-Editor. 

Requiring the RFC-Editor to make these reference changes in this
common case doesn't scale very well, and the RFC-Editor queue is
already recognized as a bottleneck. Assigning the RFC#s at approval
time should help reduce the work of the RFC Editor and improve RFC
publication throughput (not by much, but every little bit helps).

Not only would it help reduce the RFC-Editor work load, it would be
beneficial to other standards bodies.

David Harrington
[email-masked]

> [mailto:[email-masked]] On Behalf Of James Carlson
> Sent: Friday, September 23, 2005 6:24 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Allocating RFC numbers at time of approval
>

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 26 Sep 2005 10:48:29 -0700

>From a theoretical point of view I disagree. If document B reference A, and
A completely changes, it might change how to use and implement B. If
document C refers to to B, document C might make absolutely no sense and
need to be re-written.
 
The basic fact is that a document is not a stable reference until it is
certain that it, and all of it's normative references will not change in a
substantial way. What 3GPP sounds like they are asking for here is that we
issues stable reference early. This is not what they want - they will be
asking for once a document is "stable", we as IETF promise not to make any
non editorial changes to it or any of the documents it references, even
though some of documents may not even be in the RFC editor queue yet.

At the point that IETF knows the document and it's dependences are not going
to change, we should issue a stable reference but not before.

We already have enough of "you can't change that non working group draft,
3GPP is using it" - lets not make it worse. Don't take this as I don't care
that 3GPP documents depend on IETF ones, I do care and I want to make that
easier and work better but I want to point out the problem is not that they
need an RFC number but that they need a pointer (or RFC number) to something
that is not changing in ways that will mess up their documents.

Cullen

---

From: Dean Willis <[email-masked]>
Date: Wed, 28 Sep 2005 14:17:59 -0500

> that is not changing in ways that will mess up their documents.

I think the need for a "non-changing pointer" outweighs the need for  
a pointer to a "non-changing specification".

The usual case is that an external document will refer to a proto-RFC  
in a general way: "The request must be encoded as a tel: URI as  
specified in POINTER".  They don't really CARE if the specification  
of tel: URI changes slightly because the RFC defining the ABNF got  
revved. They're committing to use whatever we put in that POINTER  
placeholder, with the general understanding that if it changes  
HUGELY, then we'll publish the newly-obsoleted spec as historical  
(preserving the POINTER) and work on a new document that will someday  
have a new POINTER.

Their world just works differently from ours -- a few months ago, I  
sat in an OMA board meeting where we essntially approved release of  
three different versions of one enabler specification with a single  
vote. Why not just approve the latest version and drop the others?  
Because stuff pointed at the old versions by their version number.

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 28 Sep 2005 14:29:59 -0700

> Because stuff pointed at the old versions by their version number.

I hear you but not sure I buy it. We already provide non-changing pointers
very early in the process. A draft name, draft-willis-sip-answeralert-01, is
a non changing pointer. If a 3g spec references a tel URL draft, no one can
finalize an implementation until the details of the TEL ABNF are final.

If what they need is a placeholder for the RFC when it is finalized, then
seems like the draft name should work. Feel free to whack me in the head
here and tell me why a changing document reference by a 4 digit number is
better than a draft name but it's not obvious to me.

Every time I hear about a specific example of the problem, it sounds like
what 3G (and others) need is for us to finalize our RFCs sooner. Right now
the SIPish folks choose to spread very thin effort over many drafts instead
of trying to concentrate effort on a few key ones and quickly move to next.
I don't know if that is changeable but it is the best way I can imagine to
get key RFCs finalized sooner. It's probably a fairly good discussion for
the wgchairs list to discuss overall strategies for prioritization of an
overwhelming amount of work.

Cullen

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Sep 2005 11:58:22 +0200

Cullen Jennings wrote:
>...

    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."

Whack?

    Brian

---

From: James Carlson <[email-masked]>
Date: Thu, 29 Sep 2005 08:15:40 -0400

>     material or to cite them other than as "work in progress."

Maybe a head-whack, maybe not.  Until the RFC has actually issued, all
of the above is still true.

What exactly makes it appropriate to cite that very same document with
very same lack of intrinsic stability by some "pre-RFC" number, when
citing it by document name or title is inappropriate?

An extra level of indirection often does change things, but I don't
see that it really solves the underlying problem in this case.  It
appears to me only to obscure the problem -- by providing a supposedly
"stable" reference to something that is itself not actually stable.

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 29 Sep 2005 10:28:48 -0400

Hi,

I think the pre-RFC accomplishes two things.

1) It tells people what the RFC# will be when finally published. For
other standards bodies or for other internet-drafts, that means they
can cite the anticipated RFC and be fairly certain (probably ~99%
certain) it will not go away, as an internet-draft will be guaranteed
to do.

2) It provides a warning that the pre-RFC represents an approved
technical specification that is not expected to change, except
editorially, during the publication process.

Especially for Informative References, that may be good enough for the
desired usage, and other documents don't need to be delayed waiting to
see if the approved internet-draft actually makes it through the small
remaining portion of the process.

We can shoot for perfection, or we can shoot for good enough. While I
certainly appreciate perfection, there is a time utility to industry
standards, and sometimes delays can kill a standard, effectively
encouraging the development of timely proprietary alternatives.

David Harrington
[email-masked]

> Sent: Thursday, September 29, 2005 8:16 AM
> To: Brian E Carpenter
> Cc: [email-masked]
> Subject: Re: When can we provide stable references to other 
> standards bodies
>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 29 Sep 2005 13:18:24 -0700

>     material or to cite them other than as "work in progress."

100% agree but this is exactly what Dean asked for. A reference to work in
progress.

---

From: Dean Willis <[email-masked]>
Date: Thu, 29 Sep 2005 16:37:34 -0500

> finalize an implementation until the details of the TEL ABNF are  

draft-willis-sip-answeralert-0x hopefully will change to RFC XXXX  
eventually. Why should OMA have to re-issue some specification just  
because IETF administratively changed the name of the document?

> better than a draft name but it's not obvious to me.

Whack! Whack! Whack!

because they PROBABLY won't have to change RFC XXXX to RFC YYYY (only  
OCCASIONALLY will we kill an IESG approved document before  
publication or change it so dramatically that it immediately goes  
historical) but they ABSOLUTELY WILL HAVE TO change draft-fluffy- 
mondoidea-39 to RFC XXXX.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 29 Sep 2005 16:49:27 -0500

> 100% agree but this is exactly what Dean asked for. A reference to  

Actually, I'm asking for a reference to a work that is "mostly  
progressed". It's been IETF last-called, blessed by the IESG, and is  
waiting for some editorial pixie-dust that it has a better than %99  
probability of surviving unscathed.

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 29 Sep 2005 15:34:23 -0700

Ah, Dean now I understand our disconnect.... If the normative references are
all also in this state of approved by the IESG, then I agree with you. But
what folks seem to be asking for is RFC numbers for documents where a person
who wanted to interpret or understand that document you would have to rely
on another document X that was *not* approved by the IESG and is a normative
reference. The second we do that, we will have cries of you can't change the
document X because some other standards group has already referenced it. I
understand that there will be times where the is no way the document X could
change anything relevant, however there will be time when it is really the
bulk of the specification. There's no reasonable process to separate these
two case. It the document X is not really relevant, then it should not be a
normative reference.

I've got no serious complaints with RFC numbers for documents that are IESG
approved and all the normative references are IESG approved. I just don't
like the idea of RFC numbers for shell documents that refer to a bunch of
drafts that may be substantially change after the RFC number is issued.

Cullen

---

From: Dean Willis <[email-masked]>
Date: Thu, 29 Sep 2005 18:25:02 -0500

> drafts that may be substantially change after the RFC number is  

So we'd assign and publish an RFC number for every pre-RFC document  
that is IESG-approved and for which all normative references are  
either published or (if IETF references) are IESG-approved.

I could live with that.

--
Dean

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 29 Sep 2005 19:29:06 -0400

And I'd be willing to wait until after the two-month appeals window as
well, to ensure relative stability.

David Harrington
[email-masked]

> [mailto:[email-masked]] On Behalf Of Dean Willis
> Sent: Thursday, September 29, 2005 7:25 PM
> To: Cullen Jennings
> Cc: [email-masked]; Brian E Carpenter
> > all also in this state of approved by the IESG, then I agree with

> > you. But
> > what folks seem to be asking for is RFC numbers for 
> documents where  
> > a person
> > who wanted to interpret or understand that document you would have

> > to rely
> > on another document X that was *not* approved by the IESG and is a

> > normative
> > reference. The second we do that, we will have cries of you can't

> > change the
> > two case. It the document X is not really relevant, then it should

> > not be a
> > normative reference.
> >
> > I've got no serious complaints with RFC numbers for documents that

> > are IESG
> > approved and all the normative references are IESG 
> approved. I just  
> > don't

---

From: Bill Fenner <[email-masked]>
Date: Thu, 29 Sep 2005 16:48:27 -0700

>either published or (if IETF references) are IESG-approved.

To make it a little more concrete, this means any draft in
http://rtg.ietf.org:8080/Test/parking that doesn't have
"Blocked" in the "Unblock Date" column should have an RFC
number already.

  Bill

[* - the data is a little noisy because the RFC Editor changed
their queue format yesterday and all the bugs haven't been
shaken out yet]

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 29 Sep 2005 19:41:44 -0700

> their queue format yesterday and all the bugs haven't been

Bill, as said many times before - thanks for great tool and data.

Would you hazard a guess on how much sooner, on average, this would result
in another standards body getting an RFC number?

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Sep 2005 15:18:54 +0200

Please hold this thought for the techspec BOF in Vancouver
and the draft that will go with it (once written).

     Brian