Trusting the IESG to manage the reform process (was: Re: Doing the Right Things?)

Bound, Jim Jim.Bound at hp.com
Mon Jun 9 16:02:15 CEST 2003


maybe we should make a list of what the ideal IESG member and the group
should do and how they behave as IESG with IESG hats?  this way it is
not finger pointing.

but saying there is no fix needed for the IESG is simply not dealing
with reality IMO.  There are problems and they are all not perceived.

If all we are going to do is fix everything but the IESG I am going to
leave this list because the goal of fixing the IETF will not get done.

The IESG needs a fix.  I don't know what it is but it needs fixing as
other parts of our community.

/jim

> -----Original Message-----
> From: John C Klensin [mailto:john at jck.com] 
> Sent: Monday, June 02, 2003 3:21 PM
> To: problem-statement at alvestrand.no
> Subject: Trusting the IESG to manage the reform process (was: 
> Re: Doing the Right Things?)
> 
> 
> In writing the note about an accelerated process, I realized I'm 
> making an assumption that needs a bit of explanation.  Several 
> of the issues here, and what processes might and might not work, 
> are ultimately about whether or not IESG is completely broken 
> and/or in some "us versus them" mode that implies we can't trust 
> them with much of anything, especially anything involving reform 
> or evolution.
> 
> There are clearly people in the community who believe that the 
> current IESG has formed a closed circle, developed a "them 
> against us" mentality, and cannot be trusted.  I don't know how 
> large that group is (although I suspect "not very" would be a 
> good guess).  But, if they are right, we don't need incremental 
> procedural suggestions, we need really radical reform.  Why? 
> Because at least two consecutive nomcoms, acting independently, 
> have selected (or reselected) the current IESG members.  If they 
> have managed to select people who would engage in that sort of 
> conspiracy of untrustworthy behavior, and to do it so 
> successfully that, not only can the IESG behave in undesirable 
> ways, but that no one on the IESG has been willing to speak up 
> in public and say "I see a problem here, but it is all those 
> other folks, not me", then there is something hopelessly broken 
> about the nomcom model, probably to the point that we need to 
> discard it and start over.
> 
> No one has suggested that yet, but, if people seriously believe 
> that the IESG can no longer be trusted to manage the standards 
> process, or a reform process, or both, I think it is time to 
> move past "list problems only" and get that on the table.
> 
> Why can't we, instead, just make up some new rules and 
> procedures to "control" the IESG?  Because our enforcement 
> mechanisms are almost non-existent if the IESG is unwilling. 
> The IESG has already demonstrated that, under their general 
> responsibility and authority to manage the process, they can and 
> will make up procedural rules that bend written procedures 
> pretty severely.  If we trust them, that process may need to be 
> tuned and constrained (as I believe it does) to make our 
> expectations about the limits of what they can do without 
> consulting the community more clear.  But, if the trust isn't 
> there, any effort to make more/different rules and procedures is 
> just to give them additional things that they can ignore.
> 
> So, whether it be about a final decision on a new AD, or on 
> figuring out which process suggestions can just be accepted and 
> deployed without going through a long and complex process, or on 
> managing the process in other ways, I think we need to trust 
> them to make management-level decisions about how best to move 
> forward and hold them accountable for doing that acceptably 
> well.  And, if we can't trust them, or at least their good 
> intentions and willingness to do what the community wants and 
> needs, that far, then we had best stop the process of examining 
> the leaves on the forest floor while the place goes up in flames 
> around us.
> 
>      john
> 
> 


More information about the Problem-statement mailing list