--On Thursday, 13 April, 2006 16:40 -0500 "Stephen Hayes
(TX/EUS)" <[EMAIL PROTECTED]> wrote:
> 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.
Stephen, I don't think either of those conclusions follows.
There are almost certainly people in the wider community who
believe that they have the level of knowledge and understanding
needed to do exactly the job the RFC Editor does today. Whether
they are correct or not is, fortunately, one of those things the
bidding process might sort out. What such a requirement does
is to effectively prevent "Joe's Pizza, Used Car Parts, Web
Design, and Copy-Editing Company" from submitting a credible
bid. That "high level decision" -- the questions of whether we
want bids from Joe, or only from some entities significantly
further up the skill/ knowledge chain (and, if so, how far up)
-- may be ones for which the answers were assumed when TechSpec
was created. But, as far as I know, those answers have never
been specifically articulated and written down, much less
discussed in the broader community.
In that context, TechSpec could be viewed as an effort to figure
out what the technical publisher role would look like given some
fairly low, but not specifically identified, skill level. No
opportunity has been identified for similar exercises at other
skill levels or under other assumptions.
As to whether this will result in "improved performance"
depends, of course, in how one defines and measures those terms.
If the only criterion to be applied is time to publish a
document after IESG approval, then it is obvious how to get
"improved performance": automate the process of turning I-D
structure and boilerplate into RFC-like structure and
boilerplate and let someone bid a collection of tools and a
low-level operator for the technical publisher role. But I
don't think that is what any of us want.
Personally, I want to see the best performance possible
consistent with quality that is no worse than what we have
today. That balance is, inevitably, somewhat subjective. And
I'm not sure that the current document helps very much in
finding that optimal balance.
>> 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.
Temporarily putting myself into the role of someone who might be
interested in bidding on this, who understood the job that has
been done by the RFC Editor for the last 35 years, and, more
important, understood the quality of some of the documents that
emerge from the IESG, if I saw "appropriate checks should be
established...", I would be deterred from bidding. It would be
ok if the process post-mankin-pub-req but before an RFP was
issued defined those checks, but I point out that there is not
much time and that serious checks are IETF process issues, not
IASA administrative procedures. We don't have a history of
being able to make and ratify IETF process changes quickly.
That is why I'd prefer to avoid the handwaving implicit in
"should be established" and make sure that these decisions are
subject to the usual appeals procedures: that, at least,
provides a minimum level of safety.
john
_______________________________________________
Techspec mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/techspec
