John Klensin wrote:
> 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.
The dumbing down of the editor role is somewhat implied when you open up the
process for outside bids. You can't assume another editor will have the same
knowledge as the RFC editor or trust that they will make the right judgements.
So I view this requirements document as a low level result of a high level
decision. In any case, the result should eventually lead to improved
performance.
>
> 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.
>
The current requirement on publishing verbatim gives IESG (or IAB or IRSG)
absolute power over the publisher. As you point out this is a dangerous thing.
I think this capability is needed in the case of conflicts, but checks and
balances are needed to prevent it from becoming a common path to get documents
out quickly. Your comment reminded me that I had also forgotten to delete the
2nd bullet in section 5
o Post Approval Editorial Cleanup: IETF must define under what
conditions the publisher should be instructed to bypass post
approval editing.
I propose to alter this to:
o Post Approval Editorial Cleanup: IETF must define under what
conditions the publisher should be instructed to bypass post
approval editing of sections of text. Appropriate checks should be
established to ensure this an exceptional case.
> regards,
> john
>
>
_______________________________________________
Techspec mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/techspec
