-----Original Message-----
From: John C Klensin [mailto:john-ietf(_at_)jck(_dot_)com]
Sent: Tuesday, September 12, 2006 2:51 PM
To: Eliot Lear
Cc: IETF Discussion
Subject: Re: what happened to newtrk?
Eliot,
The discussion of the question you asked here seems to have
been immediately sidetracked. I, at least, believe the
original question is worth some community discussion and
possibly a conclusion. More below.
--On Tuesday, September 05, 2006 4:39 PM +0200 Eliot Lear
<lear(_at_)cisco(_dot_)com> wrote:
All,
As a participant in the newtrk working group and someone
who actually
ran one of the only reasonably successful experiments in
that group, I
think the community is owed a better accounting of why WG
failed, and
that steps should be taken to see that such efforts do not
fail in the
future. The newtrk working group was chartered to revise the
standards track, with an understanding that the current one is
demonstrably not working as it should.
...
However, the end result was that we had a working group
chartered to
do a specific task, do the task, and then have the work rejected.
Quite frankly we don't have the resources to have that happen. I
suspect anyone who had any involvement with that group will be
extremely reticent to work on process proposals in the
future, because
they will assume that any given IESG is likely to reject any output.
That is certainly the conclusion to which I, and at least
some others who put energy into Newtrk and related work, have come.
What I would like to know is what we could have done to
prevent this
from happening. Was the newtrk charter not sufficiently narrow to
accomplish a task for which there was community consensus? Is a
working group the appropriate place to make process changes? I am
leaning heavily toward "no" on that last one. Should the
IESG simply
both propose and dispose? Perhaps the IAB has a role of proposing
changes.
I do not believe that WG-or-not is the key issue, even though
I continue to have doubts as to whether a regular WG is
adequately representative of the IETF participants impacted
by significant
process changes to be the ideal final review mechanism. Within
limits, a WG may be a reasonable mechanism for proposing
approaches and solutions and/or working through details of
them, but we do need to be careful about creating WGs that
are dominated by would-be process experts with little actual
experience in the technical work of the IETF.
Eventually, as I wrote in a previous note, we must circle back and
actually fix the standards process to reflect reality.
But how that is to be done remains to me an open question.
I think the lesson to be drawn is that one that you have implied
above: it is unlikely that any serious process changes will
succeed as long as the IESG is the body that must approve
such changes. This is not a criticism of any particular IESG
or IESG member. Instead, it is the result of observation and
experience: the IESG is appointed to do a particular job, is
under huge pressures to do that job, and tends to "train" new
members about how that job works. Any new model of the job
to be done naturally leads to a very conservative reaction:
doing things differently will always involve more work, if
only in developing new detailed procedures and non-disruptive
transition mechanisms, and we tend (properly) to select IESG
members whose primary commitment is to the short-term
objective of processing as much of the IETF's technical work
as possible.
The consequence is that it is unreasonable to expect the IESG
to evaluate and agree to non-trivial process changes. Even
if I had not been convinced of that after the Newtrk
meltdown, the recent response to draft-klensin-norm-ref would
have been completely persuasive. That response isn't wrong
-- both the model in RFC 3933 and the I-D were written to
give the IESG the discretion to reach the conclusion they
reached -- but it shows a response so conservative as to make
the writing of the proposal not worth the effort, at least IMO.
That, I think, leaves two questions for the community:
(1) How should things be arranged so that the IESG does not make
the final decisions about process changes? And,
(2) If the community can reach some rough consensus on the
answer to that question, how does one get the IESG --which
has not been sympathetic to efforts to reduce their perceived
authority-- to approve it or how does it get adopted without
IESG approval.
I am not yet to the point that I would try to get the
community to convince the Nomcom that a promise to approve a
proposal to transfer approval of process changes away from
the IESG should be a precondition for appointment (or
reappointment) to the IESG but, if the community is serious
about process changes, it could come to that.
Just my opinion
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf