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
John C Klensin wrote:
--On Friday, 17 February, 2006 16:04 +0100 Brian E Carpenter
<[EMAIL PROTECTED]> 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
_______________________________________________
Techspec mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/techspec
