Subject: RE: rfc publication suggestions

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 13 Mar 2001 08:39:56 -0500

So, for example, if the time between a document approved by the IESG
for publication, and the time the RFC was published, grew to five years,
that would not concern you?

No one is suggesting that we compromise quality for speed.
It's a process.  Process cycle time is often one of two or
three most important measurements.  Engineers optimize processes 
all the time to improve cycle time.  Reducing queue time is
one of the most productive ways to improve cycle time.

Brian

> -----Original Message-----
> From: Lloyd Wood [mailto:[email-masked]]
> Sent: Tuesday, March 13, 2001 8:26 AM
> To: Rosen, Brian
> Cc: 'Fred Baker'; Dave Crocker; Steven M. Bellovin; [email-masked]
> Subject: RE: rfc publication suggestions
> 
> 
> On Mon, 12 Mar 2001, Rosen, Brian wrote:
> 
> > I'd love to have a discussion of:
> > 	What do we WANT the queue time to be
> > 	What would we have to do to get it there
> 
> Editor queue time is not a meaningful engineering constraint, and we
> shouldn't be optimising for it.
> 
> The IETF should not be organised around time to publication or time to
> decisions.
> 
> L.
> 
> <[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>
>

---

From: Scott Bradner <[email-masked]>
Date: Tue, 13 Mar 2001 11:14:12 -0500 (EST)

note that it is hard for the rfc edior to accept nroff

too often people use their own macro packages which are incompatable
also too often people change the text between the time that the iesg
approves of a doc and when then send it to the rfc editor - so the
rfc editor has to check for that

Scott

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 13 Mar 2001 09:52:29 -0700 (MST)

> From: Scott Bradner <[email-masked]>

> too often people use their own macro packages which are incompatable

Given the antediluvian, fossilized stability of nroff macros and the very
small number of people in this century who have their own macro packages,
that is a very strong statement about likely results of using any mark up
language, including XML.

For example, I guess HTML style sheets are like nroff macros. 
I recently dabbled with CSS, and tried to use the sample style sheet
at http://www.w3.org/TR/REC-CSS2/sample.html.  Can you guess what
happened when I copied it into my document without changes and asked
http://jigsaw.w3.org/css-validator/ ?

(That my CSS problem was probably purely my own fault does not
weaken the point.)

> rfc editor has to check for that

Is that a comment about nroff or delays?  
`diff` should work equally well for detecting such changes whether
applied to nroff or readable ASCII.

Vernon Schryver    [email-masked]

---

From: Bob Braden <[email-masked]>
Date: Thu, 15 Mar 2001 00:12:21 GMT

*> Perhaps, the perils of a cost-plus-fixed-fee contract? 

The fixed fee is zero.

Bob Braden

---

From: Bob Braden <[email-masked]>
Date: Thu, 15 Mar 2001 00:21:54 GMT

*> 
  *> The RFC editor has stated that the conversion step is a minor 
  *> annoyance, and not a significant source of delay.
  *> 
  *> 		--Steve Bellovin, http://www.research.att.com/~smb
  *> 
  *> 
True.

Bob Braden

---

From: Bob Braden <[email-masked]>
Date: Thu, 15 Mar 2001 00:26:25 GMT

*> however the editor queue can hold things for a very long time, and not just 
  *> due to waiting for an author to fix something.  (gosh.  we haven't 
  *> discussed THIS topic in a couple of years...)
  *> 
  *> d/
  *> 

Dave,

If the RFC is held for a long time, it is due to the IESG or
to the WG or to the author or to normative references.  It is
NOT due to formatting, editing, or proof-reading.

Bob Braden

  *> 
  *> ----------
  *> Dave Crocker   <mailto:[email-masked]>
  *> Brandenburg InternetWorking   <http://www.brandenburg.com>
  *> tel: +1.408.246.8253;   fax: +1.408.273.6464
  *>