Subject: [Techspec] Pre vs Post approval editing

From: "Stephen Hayes (TX/EUS)" <[email-masked]>
Date: Wed, 15 Feb 2006 18:45:58 -0600

mankin-pub-req currently has requirements for both pre approval (Potential Req-PREEDIT-1) and post approval (Req-POSTEDIT-1).  We need to decide which requirements stay and which ones go.

I think both requirements are needed, however each document should only have to pass through either pre-approval editing or post-approval editing but not both.  This will allow the IETF to migrate to a methodology using pre-approval editing over time.  Usage of pre-approval editing should be encouraged.

In addition an additional requirement should be added along the lines of:

o Potential Req-TIMEFRAMES-3 - The IETF technical publisher should have a goal of an average time for completing the pre-approval editorial review of no more than 2 weeks and at least 98% of all documents should be reviewed within 4 weeks.  The review interval starts when the editorial review is requested and ends when the review results are provided.

This is to prevent simply shifting the long queuing delay from the post-approval phase to the pre-approval phase.

I would also propose that we add text prohibiting stylistic changes in the post-approval editing (but permit it in pre-approval editing).

Stephen Hayes

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 16 Feb 2006 12:40:53 -0800

At 6:45 PM -0600 2/15/06, Stephen Hayes (TX/EUS) wrote:
>mankin-pub-req currently has requirements for both pre approval 
>(Potential Req-PREEDIT-1) and post approval (Req-POSTEDIT-1).  We 
>need to decide which requirements stay and which ones go.
>
>I think both requirements are needed, however each document should 
>only have to pass through either pre-approval editing or 
>post-approval editing but not both.

There is a significant problem with have a document edited 
pre-approval and then not re-editing post-approval, namely the 
changes that get introduced during the approval process itself. A 
typical change is "add a section to the Security Considerations 
talking about how Wxyz interacts with this protocol." Unless the 
authors use exactly the same spelling, capitalization, reference 
format, and so on, that new section will not match the rest of the 
document.

There is also the very real issue of document authors not doing some 
of the proposed edits, either intentionally or unintentionally.

If the document has had pre-approval editing, when it goes into 
post-approval editing, one would hope that the editor would look at 
the diffs from the earlier edit and only edit the changed sections.

>Usage of pre-approval editing should be encouraged.

Fully agree.

--Paul Hoffman, Director
--VPN Consortium

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Feb 2006 16:04:39 +0100

> I think both requirements are needed, however each document should only have to pass through either pre-approval editing or post-approval editing but not both.  This will allow the IETF to migrate…

What about cases where (e.g. due to major issues during IESG processing),
significant new text has appeared? I think we need the option of a post
approval edit pass in such cases, but it should be the exception.

> o Potential Req-TIMEFRAMES-3 - The IETF technical publisher should have a goal of an average time for completing the pre-approval editorial review of no more than 2 weeks and at least 98% of all do…

I'm leery of specifying the times here. I think we should make the requirement
that there *should* be target times, but leave the actual values to the RFP
process. These times can have a direct effect on cost, and I don't think
it's appropriate to fix them a priori. It would be OK to say

The IETF technical publisher should have a defined goal for the average time for
completing the pre-approval editorial review and for the 90th percentile.
Suggested target times are two and four weeks respectively.

Honestly, I think a 98th percentile target is unreasonable for this
kind of work. And these comments apply elsewhere in the draft too.

> I would also propose that we add text prohibiting stylistic changes in the post-approval editing (but permit it in pre-approval editing).

Yes, but even in pre-approval I see no reason why editing should change
the tone, for example by removing intentional informality.

     Brian

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 17 Feb 2006 09:42:11 -0600

Two (fairly distinct) points...

Spencer

From: "Brian E Carpenter" <[email-masked]>
>> (Potential Req-PREEDIT-1) and post approval (Req-POSTEDIT-1).  We need to 
>> decide which requirements stay and which ones go.
>>
>> I think both requirements are needed, however each document should only 
>> have to pass through either pre-approval editing or post-approval editing 
>> but not both.  This will allow the IETF to migrate to a methodology using 
>> pre-approval editing over time.  Usage of pre-approval editing should be 
>> encouraged.
>

OK, this is the IETF side of techspec, which is likely a newtrk 
responsibility, but ... if a working group forwards out a working 
group-consensus draft, and then "significant new text appears", we probably 
need more than a "post approval edit pass" in most cases, don't we? Given 
that this stuff really *should* be running through the working group before 
publication, why do we need a post-approval edit pass?

I agree that significant new text during approval processing should be the 
exception.

>> I would also propose that we add text prohibiting stylistic changes in 
>> the post-approval editing (but permit it in pre-approval editing).
>

Agree, and suggest that the wording say something like "proposed" when we 
talk about stylistic changes, so that it's perhaps more obvious that 
stylistic changes aren't gating for document approval and/or publication - 
if Brian and Elwyn spell the word as "colour" in their drafts, and don't 
want to accept a proposed change from "colour" to "color", that's OK within 
techspec.

Thanks,

Spencer

---

From: John C Klensin <[email-masked]>
Date: Sat, 18 Feb 2006 10:45:18 -0500

--On Friday, 17 February, 2006 16:04 +0100 Brian E Carpenter
<[email-masked]> wrote:

>> I think both requirements are needed, however each document
>> should only have to pass through either pre-approval editing
>> or post-approval editing but not both.  This will allow the
>> IETF to migrate to a methodology using pre-approval editing
>> over time.  Usage of pre-approval editing should be
>> encouraged.
> 
> What about cases where (e.g. due to major issues during IESG
> processing), significant new text has appeared? I think we
> need the option of a post approval edit pass in such cases,
> but it should be the exception.

Brian,

To repeat a comment of Spencer's, but with a different slant, it
seems to me that, for this reason, the entire pre- versus
post-approval editing question cannot be answered except in the
context of evolution of the standards process.  Our friends with
more traditional standards processes (and a larger infestation
of [real] lawyers, have firm "the document that is approved is
the document that is published" rules for what seem to them to
be obvious reasons.  Such rules effectively require that any
document changes of a technical or editorial nature occur before
the formal decision (ballot in their case) point.  The only
post-approval editing that is possible involves formatting and
attachment of final boilerplate and, typically, very little of
the former.   Their idea of "approval" involves some complex
dealings that are called a "ballot resolution process" in
ISO-speak (other groups have other procedures and other
terminology).

Were we to adopt a similar model without making major structural
changes, "major issues during IESG processing" would require
return of the document to the WG with suggested text.  The WG
would then do its thing and then return the document to the IESG
via a second-round pre-approval editing process.

We have had "discussions" before about the issue of whether it
is really appropriate for the IESG to alter a document, perhaps
negotiate the changes with a document editor and/or WG chair,
and then send the document on to the RFC Editor without formal
WG signoff.  I don't think I saw clear consensus either way, but
it was clear that some non-trivial portion of the community has
been unhappy with that procedure in some number of cases.  But I
think the IETF decision about this needs to be made first and
then decisions about pre- or post-approval editing made in that
context.  While I personally favor pre-approval editing, it
seems to me that it is justified/ appropriate only if it serves
one of two functions:

(1) Improving the presentation quality of a document, not to
approximately-final form, but so that its technical/ protocol
intent is completely clear.  This is certainly not required for
all documents that emerge from every WG, but we have all seen
I-Ds whose presentation is sufficiently poor that it was obvious
that the intent of the protocol provisions could not be
interpreted unambiguously.   Today, those documents are
typically handled by AD intervention prior to Last Call.  There
is a case to be made that we should have better rules, better
mechanisms, and a more organized way to get that level of
editing and document approval done.  It is not clear that having
the Publisher do that work is the most efficient approach.

(2) Making sure that the document that is Last Called and
approved will be the one that is published, with very small
deviations and only of  varieties that are well-understood
procedurally.

And whether we want either of those (or more of them) and what
to do about them are, I believe, IETF standards process
decisions, not technical-specification-handling ones.

     john

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Feb 2006 19:28:28 +0100

In answer both to Spencer and John, it's elementary
that if IESG review throws up things that need to get
changes, and that are substantive, they go back to the
WG and maybe even through another last call cycle.
But that can happen quite quickly sometimes, and I
wouldn't want to inject delay in the form of an edit
cycle right then. Sometimes it's only a paragraph or
a sentence but it can still need copy editing.

    Brian