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@xxxxxxxxx> 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf