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
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf