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

Bound, Jim Jim.Bound at
Mon Jun 9 16:04:44 CEST 2003

Well put.  I would say its worst than middle management but "program"
management and that is even less authority.

> -----Original Message-----
> From: James Kempf [mailto:kempf at] 
> Sent: Monday, June 09, 2003 11:47 AM
> To: Randy Bush; Bound, Jim
> Cc: Margaret Wasserman; problem-statement at; 
> Brian E Carpenter
> Subject: Re: Trusting the IESG to manage the reform process 
> (was:Re:DoingtheRight Things?)
> Randy,
> > that is not the problem i see day to day.  what i see is chairs not 
> > wanting to take a stand against weak documents, ersatz 
> populism being 
> > easier, and preferring to let it through to ietf last call 
> and iesg, 
> > letting the iesg take the heat.
> >
> Putting on my WG chair hat, it is not so simple. WG chairs 
> are essentially middle management, and they have all the 
> problems associated with responsibility without authority 
> that middle management has. In my experience, a WG chair that 
> tries to make a technical argument about a document is viewed 
> as being "just another WG member". WG members with different 
> opinions feel they can endlessly quibble with the chair, go 
> to the AD and complain that the chair is being "uncooperative 
> and blocking WG concensus", etc., if the chair says that they 
> won't release the document to the IESG. If the WG member 
> couches their opposition in terms of what the AD says or the 
> IESG may say, the resistence evaporates, because the IESG has 
> the ultimate authority to block the document. WG chairs only 
> authority is to hire and fire WG document editors, call 
> concensus, and prune the mailing list of people who are 
> really disruptive (at the cost of a long email exchange 
> beforehand to warn the person). They of course control the 
> agenda at meetings, but they need to be careful to be 
> evenhanded here, or risk being accused of bias.
> If you think that WG chairs should have the authority to 
> block documents, then it needs to be explicitly written into 
> RFC 2418bis.
>             jak

More information about the Problem-statement mailing list