John, While I agree that the IESG unlikely to change how it behaves I still don't think you have explained why it should resist changing the process so that it describes how it behaves in actual practice. Phill > -----Original Message----- > From: John C Klensin [mailto:john-ietf@xxxxxxx] > 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@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 mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf