Subject: Re: Allocating RFC numbers at time of approval

From: Allison Mankin <[email-masked]>
Date: Mon, 19 Sep 2005 09:13:53 -0700

Steve,

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

Not sure what you mean by those two, but if we wait for the two months
of appeal time, it should prevent most fizzles.  In the past five
years (thousand+ RFCs) I think I've seen a couple of non-issued RFCs,
compared with the very* large number of document-years of waiting
built up for IETF work that needs to be cited but can't be.

And I really need to mention the effort put in by the RFC Editor on
fast tracking documents when someone asks the IESG, because they've
got a desperate need.  This causes hard work for the RFC Ed too.

Allison

---

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

In message <[email-masked]>, Allison Mankin writes
:
>Not sure what you mean by those two

They don't exist....  (Also note the date on RFC 1108, compared to 1107 
or 1109.)

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

---

From: Allison Mankin <[email-masked]>
Date: Mon, 19 Sep 2005 16:04:01 -0700

David,

> That would help for those circumstances where a reference is needed,
> yes.
> It would also presumably allow WGs to resolve the references in
> subsequent documents, saving the RFC Editor the time to do this.

Good point, an added benefit.

> 
> While this proposal helps some, it would be even better if we could
> speed up the process of publishing the RFCs.
 
This is a good and important goal, but it can be its own task,
which the IETF could work distinctly, since the final RFC
publication is done by a separately contracted organization.
Even if there's a lag now, there could be speedup later, lag
again at another time, due to changes in our process or productivity,
changes in the RFC Editor end.  We need a bit of operations research 
here ;)

I'm suggesting we decouple the problems, where they haven't
been before.  Work on the final publication goals (how our 
organizations mesh, how to ensure the predictability and 
speed of the final documents) but separate this from the
citability of the approved documents.  Having smaller solutions,
separated tasks, seems like good engineering.

Allison

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 19 Sep 2005 16:11:08 -0700

Hi, Henrik,

I knew that a detail that wasn't well developed in
my thinking was a suitable new name, given database impacts
etc.  What you suggest makes sense to me, I like the first
one a little more, maybe with an incremented draft number in it
(reflecting that there was an rev of the i-d) just because it
is a bit more readable than one with two i-d string copies.

Allison

> Hello Allison,
> 
>     Quite a lot of what you write in your note makes sense
> to me, but there's one detail I'd like to comment on:
> 
> on 2005-09-19 18:03 Allison Mankin said the following:
> [...]
> > At this time:  an new internet-draft should be prepared
> > with the string - draft-ietf-<wg>-<orginalrestofstring>-rfc####-00.txt
> > (or something like that).
> 
> I think this particular proposed name would be unfortunate.
> Currently, a document has one single tag associated with it,
> from -00 to publication; it is currently also available in
> the RFC editor's index and provides continuity from draft to
> RFC (and vice versa): the draft-name.  
> 
> The handling proposed above would break that, and make current
> (and future) tools more complex, because it would give this
> special document a new tag in the drafts namespace .
> 
> There are a number of other variations on the name which
> would not place a new draft tag in the drafts namespace; one
> I can think of would be something like
> 
>   approved-<originaldraftname>-rfc####.txt
> or maybe
>   approved-<originaldraftname>-<originaldraftnum+1>-rfc####.txt
> 
> The latter would have the benefit of not obscuring the draft
> revision from which the document is derived.
> 
> This document would still be associated with the original
> draft name tag, but would not have an additional pre-publication
> name in the same namespace.
> 
> 
> 	Henrik
> 
>

---

From: Allison Mankin <[email-masked]>
Date: Mon, 19 Sep 2005 16:17:34 -0700

[Somehow my system let me edit/send this message with From and To
 fields awry.  I've seen it come back but I suppose that
 it could be blocked by some of you, so here it is in better shape]

Hi, Henrik,

Allison

> name in the same namespace.

------- End of Forwarded Message

---

From: Allison Mankin <[email-masked]>
Date: Mon, 19 Sep 2005 16:59:30 -0700

Geoff,

It sounds complex without a draft that has distilled
it and made it work.  I suspect that resolving a publication
system for all the unpredictable aspects of IETF documents
so that it doesn't have unpredictability and delay and so
we can just forklift it in quite soon is very complex, and
meanwhile the users (many many many of them) will keep waiting
for their specs.

Some Editors and Chairs see a lot of this user waiting, some
less.  

Of course we want to fix a root issue, but a present fix should
be compatible with any root cause fix that comes in the
next year or so.  The IETF has its roles, the technical
publisher its roles.

Anyway, you are right that this group needs to refrain from
further detailing.  There's expectation of a BOF about these
topics.  I need to get back to work on a draft for that, from
which I've been riffing.

I do want to add one last thing...
The WG Chairs are stewards of IETF technical publications,
so although their (collective) experiences vary a lot,
depending on the audience/takeup/field of the RFCs they've
shepherded along, they've had a lot of responsibility for these
documents and it's not unreasonable to have things to say
about them to each other on this list.  Part of the job.

Allison

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 20 Sep 2005 08:50:49 +0200

Hi Allison,

> is a bit more readable than one with two i-d string copies.

Well, in that case we're very close ;-) since the second one actually
actually _has_ the incremented number in it, not a second copy of
the i-d string.  I guess I should have expressed myself better, with
"something like

  approved-<originaldraftname>-<num+1>-rfc####.txt"

rather than the easily mis-read

Best,

	Henrik

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 20 Sep 2005 16:42:23 +0200

Last email I post on this specific topic:

> >>At some point, the diliquent normative reference must be dealt with. 
> >>That is independent of whether or not the referring document has been
> >>WG last called.
> >
> >And if that is a year and umpty revisions of the normative doc later,
> >then who guarantees that the referenced doc is still in sync with
> >the one that makes the reference?
> >  
> >
> I guess hypothetically documents could get out of sync and contradict 
> one another - can you cite an example?
> 
Sorry I cannot. Or I'd have to go dive into old archives and such and
I just don't have the time for that.
Formally, I think we should carefully check when we get to such a situation,
but I doubt that that really happens.

Oh well.

I am done with this. You and I disagree.
Others have not expressed an opinion. Too little data to draw
conclusions.
Bert

> -----Original Message-----
> From: Acee Lindem [mailto:[email-masked]]
> Sent: Tuesday, September 20, 2005 16:20
> To: Wijnen, Bert (Bert)
> Cc: [email-masked]
> Subject: Re: Allocating RFC numbers at time of approval
> 
> 
> Inline.
> 
> Wijnen, Bert (Bert) wrote:
> 
> >Inline
> >
> >  
> >
> >>-----Original Message-----
> >>From: Acee Lindem [mailto:[email-masked]]
> >>Sent: Tuesday, September 20, 2005 14:51
> >>To: Wijnen, Bert (Bert)
> >>Cc: Geoff Huston; [email-masked]; [email-masked]
> >>Subject: Re: Allocating RFC numbers at time of approval
> >>
> >>
> >>Wijnen, Bert (Bert) wrote:
> >>
> >>    
> >>
> >>>W.r.t.
> >>> 
> >>>
> >>>      
> >>>
> >>>>3 - there is no way for the editor to 'spit it back' as being 
> >>>>   not ready for publication as it is awaiting some other
> >>>>   event that is beyond the rfc editor's control.
> >>>>   i.e. the queue is actually two queues - documents
> >>>>   that are awaiting processing, and documents that have
> >>>>   failed some step in the publication process and are now
> >>>>   awaiting some external action beyond the Editor's control.
> >>>>
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>For example, if a document has normative references to another I-D
> >>>that has not yet passed the IESG and so is not yet in the 
> RFC-Ed queue.
> >>>
> >>>Would WGs be OK with a rule that would say that an I-D can 
> >>>only be IETF Last Called if all the normative references (to I-Ds)
> >>>are also being IETF Last Called at the same time?
> >>> 
> >>>
> >>>      
> >>>
> >>I don't like this proposed change at all - it is better WG 
> >>last call the document while it is fresh in
> >>eveyone's mind. Also, it's hard enough to move these 
> >>documents forward with out adding the
> >>additional constraint that they have to be progressed in lock step.
> >>
> >>    
> >>
> >
> >Well... but the other problem is that when the rfc-to-be 
> finally gets 
> >into AUTH48 (after some normative ref finally shows up, we've
> >seen cases where that is more than a year later), then the authors
> >may not be present anymore to review the AUTH48... and so we
> >have ended up with docs in multiple-months of AUTH48 state.
> >  
> >
> The tracker seems to keep them in the RFC editor's queue rather than 
> AUTH48 hours
> state. This is still preferable.  I still think trying to assure that 
> all documents that reference
> one another go forward is a bad, bad, bad idea.
> 
> >You can't win them all you know.
> >
> >
> >  
> >
> >>>It would put the burdon with the WG/authors to ensure and pressure
> >>>others (WGs, individuals) that the other documents actually DO get
> >>>worked on and DO move forward.
> >>>
> >>>Just wondering. I just see too often that a doc (I-D) gets approved
> >>>by IESG with a normative ref to some other I-D that than 
> >>>easily expires and never gets moving again.
> >>> 
> >>>
> >>>      
> >>>
> >>At some point, the diliquent normative reference must be 
> dealt with. 
> >>That is independent of
> >>whether or not the referring document has been WG last called.
> >>
> >>    
> >>
> >
> >And if that is a year and umpty revisions of the normative doc later,
> >then who guarantees that the referenced doc is still in sync with
> >the one that makes the reference?
> >  
> >
> I guess hypothetically documents could get out of sync and contradict 
> one another - can you
> cite an example?
> 
> Acee
> 
> >Bert
> >  
> >
> >>>Bert
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >
> >  
> >
>

---

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 20 Sep 2005 12:00:31 -0400

Hi David,

One thought, I think that some other standards bodies might still want
to cite
an approved RFC and so would still wait until the RFC is issued.
Otherwise they
might cite something that has some finite chance of never being
completed.

Cheers,

Lyndon  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Monday, September 19, 2005 8:30 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Allocating RFC numbers at time of approval

> 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
----------------------------------------------------

> 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: Allison Mankin <[email-masked]>
Date: Tue, 20 Sep 2005 09:25:50 -0700

> to cite an approved RFC

Lyndon, it's not my experience (across
an awful lot of groups) that the published RFC
has been a requirement (versus the citation
and a stable technical text).  

Note that the text and content are fully approved
by the time we send it to the RFC Editor.  In
my original note, I suggested a two month wait
time to close out appeals that might cause the
IETF's approval to be withdrawn.

But if a group wants to wait for the publication,
they certainly still could.

Allison