--On Thursday, September 03, 2009 11:55 +0300 Jari Arkko
<jari(_dot_)arkko(_at_)piuha(_dot_)net> wrote:
...
In particular, when I have been an AD it has always been a
pleasure to work with the RFC Editor, and they have always
made exactly the right decisions. In my honest opinion of
course.
And I'd rather count on that and think about ways to deal with
any patterns of deviation if they should occur than start
devising ways for one stream to tell another one what it must do.
But I did want to bring up a couple of other angles. First of
all, all the streams get their share of garbage. And sometimes
the right decision is to publish the document despite it
having some faults, or at least differences of opinion to
established IETF practice. However, in such cases the notes
that we are talking about really can be necessary (e.g., when
a document redefines RADIUS Access-Reject as Access-Accept, to
cite one real example from a few years back).
And that is perhaps exactly an example for the other side.
First, it is at the very margin between the "procedural review
for conflicts with ongoing IETF work" that both 3932 and 4846
call for and the "technical review" that both documents more or
less indicate should be handled on an individual review basis.
I suggest that it is not so much a conflict with the ongoing
work of an IETF WG, but a flat technical error. The right
solution for such errors is to fix them, or at least ask the
authors to include a detailed discussion of why the terminology
needs to be different, not a "note"... especially, IMO, one
that, per the current interpretations of the current RFC 3932,
is closer to "nah, nah, we don't like this" than a useful
explanation that identifies the specific problem. I believe
that, if an ISE were to ignore reviews/input on a subject like
that, or fail to push the authors very hard after getting it, we
would have a very serious problem on our hands... whether that
review came from the IESG, from a single AD, from within some
relevant WG, or from a moderately random IETF participant or
onlooker.
So I don't see that "notes" are the right solution to that
problem. At worst, they become a crutch that reduces the ISE's
belief that it is the responsibility of the authors and the RFC
Editor function to actually get these documents right.
The second point was that in general, human organizations are
prone to occasional failures. I at least prefer designs that
are inherently capable of dealing with such failures (e.g.,
appeals path, way to fix a bad decision).
We agree about that, which is one of the reasons why
institutionalizing the current practice of telling the IESG why
comments are being rejected (if that happens) strikes me as a
good idea. But, to paraphrase (I think) Joel, I'll prefer to
see things work in a way that gets documents improved rather
than ones that drop cross-stream notes into them (mandatory or
not). And that is especially so after many decades of
experience in watching people's eyes glaze over as they notice
what appears to be boilerplate and skip it... getting the text
right, or getting it to clearly note that there are dissenting
views and why, is just a much better way to get the point across
than note-inserting.
However, I still
want to see the RFC Editor as a simple journal-like function;
please don't take my comment as an indication that board
members should be selected by Nomcom, publication decisions
should have public last calls or anything like that. We
already have the IETF which runs in a community driven manner.
Good. And thanks.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf