Re: Guidelines for authors and reviewers

[Suresh Krishnan <[e-mail]>]

Hi Ted,
   Thanks for your comments. Please see responses inline.

Ted Hardie wrote:
> 	I looked at it, and, while I laud any efforts to get folks to review
> things effectively, I have to say that I found this to be a pretty drafty draft.
> It does not reference the Tao, 2026, or any of the developed educational materials;
> its only listed reference, in fact, is 2119 and that does not seem to be referenced
> within the text.  That means that this comes across as pretty context free.
> It needs anchoring to the rest of our processes.

I do share your sentiment, but this is not what we set out to do 
originally. We set out to document the review process(es) and provide 
some guidelines to effectively use the received reviews. I think the 
right document to weave the stuff together would be the Tao. But I do 
agree that adding references to the Tao and 2026 make sense. The 
dangling reference to 2119 is an editorial oversight :-).

> 	One of the things that I believe that anchoring should provide
> is a pretty significant change of perspective.  As this reads now,
> it implies a lot of power in the hands of reviews to elicit (or even require)
> change.   It seems to want document authors to accede to requests for
> tutorial material as a matter of course and to significant technical changes

I am sorry you feel that way. It was not the intent of the document. The 
document just states that a concern raised in the review deserves a 
response (not necessarily a change). One valid response is "Mr. 
reviewer, what you raised is not a problem. This was a design decision 
taken by the WG and the discussion thread about this is at 
http://mlarchive.invalid/msgfoo.html".

> with a modicum of fuss.  That's not the right approach.  The outcome of our
> document development should not be a negotiation between the authors
> and the assigned reviewers.  It should be a conversation in the working group
> among those who will actually develop the implementations, those who
> will deploy it, and those who are affected by the system of which the
> documented technology  is a part. 

Agree. And hence this text in section 3.5

"   After the author and reviewer agree that the issues have been fixed,
    for working group documents, substantial issues need to be confirmed
    on the mailing list.  Once the document has entered IESG processing,
    new versions should not be posted unless the document shepherd or AD
    explicitly says so."

> 	Reviews that work to relate a particular document's technology
> to the larger whole of which it is a part (asking: how does this impact
> congestion control in the access network or core, use deployed security systems,
> relate to the identifier mechanisms common to URIs, etc.) are very valuable.
> But many reviews represent questions about decisions that come down to
> design choices that working groups should have the power to make without
> extensive second-guessing.  Folks who want to have a say at the level can and
> should do so with the simple method of joining the working group list and commenting
> as part of the general development.  That's not "review" (of someone else's work)
> it is "participation" (in joint work), and it is fundamentally more valuable.

Agree in principle. But a "late" reviewer usually gets documents from 
multiple wgs and subscribing to the MLs just to raise one issue can get 
to be a tiring endeavor. Last year, I reviewed documents from 20 
different WGs (apart from the ones I am usually involved in). I cannot 
handle mailing list traffic from 20 more mailing lists. If this were 
mandated, I would rather not review the document. I would also like to 
point out that most of the reviews received during IETF Last Call are of 
the nature you describe.

> Without the context of how "participation" works, your documents description
> of "review" comes off very badly indeed.  I hope that future versions can correct
> that and place review within a broader, more productive context.

I personally feel that the TAO (4677 and descendants) should be the 
document that sets the various pieces in context, but I am open to 
suggestions on how to go about fitting this document into a broader 
context.

Thanks
Suresh
_______________________________________________
IETF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf