--On Thursday, 13 April, 2006 11:56 -0500 "Stephen Hayes
(TX/EUS)" <[EMAIL PROTECTED]> wrote:
> To meet the April 15 deadline, I plan to produce
> mankin-pub-req-07 at the end of today.
>
> The changes collected so far are:
>
> 1. Replace Req-POSTEDIT-5 with
>
> Req-POSTEDIT-5 In specific instances, where some or all of
> document text is the result of a careful negotiation of
> contributions (within or between working groups, reviewers,
> etc), the IESG or IAB or IRSG will require that the publisher
> publish that text verbatim. It is the expectation of the
> IETF community that this will not be done often.
>
> 2. Add a new requirement to section 3.20:
>
> Req-PROCESSCHG-2 - The IETF technical publisher should
> participate in and support process experiments involving the
> technical publication process.
>
> Anything else?
Stephen,
While I think these changes, and some related text, reflect the
consensus of discussion on this list, I'd like to raise a flag
about another point of view... and the possibility that IETF
consensus might possibly lie elsewhere.
Over the years, both before and after the creation of the IETF,
the RFC Editor process has provided an important check on
document quality, at least editorial quality and sometimes
technical quality. The more we move toward "whatever the IESG
wants, the IESG gets", the more we do two other things:
* we eliminate that check and reduce the need for a
publisher function that is capable of applying it.
* we make the IESG the final repository of editorial
skill and judgment.
Clearly, there are people in the community who believe that the
first of these would be A Good Thing. Personally, I think it is
an attempt to solve a set of problems with the bathwater by
discarding both the baby and most of the plumbing in the house.
As to the second, many of us have seen IESG nit-picking over
editorial matters as one of the major roadblocks to rapidly
progressing documents. Early editing experiments are useful in
addressing some of the issues there, as are IESG efforts to pin
down the justifications for "discuss" positions. But giving
the IESG the authority to say "publish this as is" pushes the
editorial job back on them, at least for whatever documents
someone can argue are Really Important. It is not clear to me
that we want to head in that direction without stronger
safeguards than "expectation ... that this will not be done
often". I'd be much more comfortable with the idea if two
additional things went with it:
(i) The proposal that a document will be fast-tracked in this
way must appear as part of the Last Call announcement so that
the community can comment on the necessity of doing that and on
the editorial readiness for publication "as is" as well as on
the technical substance of the document. I would hope that we
can trust the IESG to either bounce the document or drop the
fast-track plan if there is significant negative feedback on
expedited publication as-is, rather than trying to rewrite the
document themselves.
(ii) The decision to fast-track a document in this way must be
appealable by any impacted party in the community including, if
the document is judged unsatisfactory under our presumably-high
publication quality, by the technical publisher themselves.
regards,
john
_______________________________________________
Techspec mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/techspec
