Re: what happened to newtrk?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]