--On Tuesday, August 30, 2011 23:17 +0300 Jari Arkko
<jari.arkko@xxxxxxxxx> wrote:
> I have reviewed the discussion from the last call on this
> document.
>
> My conclusion as the sponsoring AD is that we have consensus
> to move forward. There was clearly a constituency who believed
> this is a good (albeit small) step forward. A number of other
> people did not care so much; did not believe there was either
> harm or benefit. I also saw a couple of opposing opinions,
> though some of them were more about a desire to do something
> else than specific objections about this proposal. I will be
> recommending that the IESG approve the draft.
Jari,
Like Scott, I wonder if there is some misunderstanding here.
Part of the problem is the way that this draft was developed and
the discussion has been handled, despite your heroic efforts.
For example:
(1) If someone says "we should be looking in this different
direction instead", the response has been "irrelevant to
consideration to this proposal, so it should go forward". The
irrelevancy is debatable, but that may be another issue.
(2) If someone says "the proposal claims to solve problem X, but
there is no evidence for that", the assertion about what
problems are being solved is removed, but there is no
substantive change to the draft.
(3) If someone says "this solves no problem", the response has
been that things have been broken for years and therefore this
proposal should be approved. (The difficulty with that logic
should be clear.) Sometimes that has been accompanied by a
claim that it is the only proposal on the table and should
therefore be adopted (even though that statement isn't true and,
true or not, would never even be considered if we were
considering a protocol specification). One of the co-authors
has recently argued for a very high standard of compelling
necessity to make changes to important processes or related
documents, but that criterion obviously does not apply to this
document.
(4) There have been a few arguments made that making this sort
of change --without compelling justification and without
evidence that it would accomplish anything-- would actually be
harmful. There has been no substantive response to those
arguments. In normal Last Calls, such comments are known as
"unresolved issues" and the sponsoring AD does not move the
document forward until they are addressed (or even dismissed) in
some substantive way.
(5) This is probably off-topic unless someone decides to appeal,
but, to a certain extent, the processing of this document points
out a far more significant problem with the handling of process
change suggestions in the IETF. The IESG holds a discussion.
An IESG member prepares a draft. An IESG member (the same one
or a different one - it makes a difference, but not much)
decides what other process change proposals can be considered
(either at the same time or otherwise). While the IESG would
normally decide that anything that has produced this much
controversy needs a Working Group to consider alternatives and
get a real consensus determination, the IESG decides that no WG
will be considered for this work (the claim that previous WGs
addressed to process issues have been a problem --one with which
I personally agree-- may not be relevant unless the IESG is
ready to consider other review and mechanisms). The IESG gets
to pick and choose which arguments for and against the proposal
"count" -- normal, but see (4) above and the many "solves no
problem" comments. And then the IESG decides to advance the
document.
(6) Unfortunately, although the document has improved
significantly since -00 --by removing material for which there
was little or no support and some question about relevance and
by removing unsupportable claims-- the basic pattern outlined in
(5) has been perceived as inevitable, i.e., that this
AD-produced draft, produces in response to a discussion and
conclusion already reached by the IESG, was going to go through
because the IESG had prejudged the ultimate outcome before the
draft was written. Whether that perception is correct or not,
it leads all but the most persistent members of the community to
tune out and stop making comments, either early on or after
several rounds. I am not going to take a position about
consensus among some silent majority because I simply don't know
how those who are not speaking up feel, but I think the
community should exercise caution about the possibility of
consensus-by-exhaustion in any discussion that has dragged on as
long as this document and its predecessors have been debated on
the IETF list.
regards,
john
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf