Subject: RE: [Techspec] IETF steering of publisher editing

From: "Stephen Hayes (TX/EUS)" <[email-masked]>
Date: Tue, 11 Apr 2006 14:00:02 -0500

I don't think anyone is trying to destroy the publication process.  The idea is to try to speed up the process.  This is one idea.

During the session at IETF#65, two principles came across (at least two me).
1. We shouldn't use requirements as a vehicle to micro-manage the publication process
2. We should keep the processes simple.  Do we need additional process flows if we can get the overall average queue duration down to 4 weeks?

I think that if documents are in good shape and fairly simple, the publisher should be able to get them out the queue rapidly.  We have no FIFO requirement in processing.  So if the performance metric chosen is reasonable (say an average value), then it is in the publisher's interest to get easy documents out quickly.  I'm not sure we need an additional requirement to drive this behaviour.  To me it is micromanagement.

Specifying blocks of text as protected is a different story.  If experts have spent two months carefully crafting a paragraph, I would not like to see it inadvertently disturbed, even if the grammar is bad.  I don't see a problem saying that the IETF can flag parts of the text as "leave alone".  My understanding is that this is something the IESG does now.

Stephen Hayes

> -----Original Message-----
> From: Bob Braden [mailto:[email-masked]]
> Sent: Tuesday, April 11, 2006 11:36 AM
> To: Stephen Hayes (TX/EUS); [email-masked]
> Cc: [email-masked]
> Subject: Re: [Techspec] IETF steering of publisher editing
> 
> 
> 
> Brian,
> 
> There is something I just don't get.  Why do you personally wish to
> deliberately shun a publication process that is (1) working very well
> for nearly everyone, and (2) producing better quality standards
> documents than would be possible without this process?  Why
> do you want poor quality documents?
> 
> Bob Braden, speaking for himself.
> 
> 
> 

_______________________________________________
Techspec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/techspec

---

From: Jari Arkko <[email-masked]>
Date: Tue, 18 Apr 2006 13:14:16 +0300

> In the future there may be
> other experiments that we come up with. It's not possible to figure
> out what sorts of requirements we might need in the future to
> accomodate some not yet thought of experiment. If the desire is just
> to allow experiments, I think it is more appropriate to add a new
> requirement to section: 3.20 (Process and Document Evolution). I
> think this is already covered, but if we want to make it explict, we
> should add a new requirement along the lines of:
> 
> Req-PROCESSCHG-2 - The IETF technical publisher should participate in
> and support process experiments involving the technical publication
> process.

I think this is much better than the initial requirement, as
it no longer focuses on specific needs of a single experiment.

But I think the issue we are discussing goes beyond experiments.
The question is IETF's ability to affect what the publisher
does. There are several aspects in this. One is the ability to
run experiments, even those that go against currently approved
requirements. Another is the ability of the IETF to change
the requirements. Your text above captures the former. The
latter is captured elsewhere in the document:

> The IETF 
> technical publisher must be part of the discussions of these policies 
> and be prepared to implement and facilitate policy changes as they 
> are determined by IETF consensus. 
...
> Req-PROCESSCHG-1 - The IETF technical publisher should participate 
> in the discussions of changes to author guidelines and publication 
> process changes. 

Both are essential, I think. (Of course, they may result
in additional negotiation over, for instance, new tasks
required to be taken on by the publisher.)

These requirements allow us to cover, for instance, changes
to handling normative references as in draft-klensin,
"service level differentiation" as proposed in draft-eronen,
adoption of new input formats to the publisher, new technology
that allows automation of some steps in a way that the
publisher no longer needs to perform a particula
task, etc.

Is this all that is needed? In draft-klensin/eronen,
for instance, the -2 requirement would allow running
the experiments. If the experiments are successful,
the -1 requirement would allow a permanent change.

--Jari