Moving the process document forward

Jeanette Hofmann jeanette at wz-berlin.de
Fri Sep 5 00:59:37 CEST 2003


On 4 Sep 2003 at 15:57, Brian E Carpenter wrote:

> Reading draft-ietf-problem-process-02.txt and 
> draft-davies-structural-rev-process-00.txt, I'm concerned that we
> are falling into our own trap (i.e. over-engineering).
> 
> To me things are not so complicated. We have a list of problems
> ready to publish. We have a measure of agreement that the current
> leaders (IESG + IAB) ultimately have to show leadership in
> implementing change to solve those problems, without fixing what
> isn't broken. So we should basically send the list of problems to the
> IESG and tell them to set up design teams to fix them.

Your proposal touches upon several of the problems documented in the 
problem issue draft. To list the obvious ones: 

2.6.1 Span of authority: Overt authority in the IETF is concentrated in the 
small number of people sitting on the IESG...

2.6.2 Workload of the IESG: With the current structure of the IETF and IESG, 
it is clear that the workload imposed on each of the Area Directors (ADs) is 
well beyond the capabilities....

2.6.6 Concentration of Influence in Too Few Hands: ... the IETF appeared to 
have created an affinity group system which tended to re-select the same 
leaders from a limited pool of people...

2.6.7 Excessive Reliance on Personal Relationships: ...the IETF is built on a 
particular kind of one-to-one personal trust relationships. This is a  very 
powerful model but it does not scale well...

I wonder what we gain if we set up a resolution process which basically 
repeats or even exacerbates the problems the process is meant to solve.

jeanette

 The
> decomposition in draft-ietf-problem-process-02.txt is certainly
> useful because it suggests a structure of design teams,
> but I think this WG would be best advised to stop there.
> 
>    Brian
> 
> Melinda Shore wrote:
> > 
> > On Tuesday, September 2, 2003, at 04:33 PM, Harald Tveit Alvestrand
> > wrote:
> > > are you asking for input on how we should structure the process for
> > > achieving at a set of changes, or on what the changes should be?
> > 
> > The latter is, strictly speaking, out of scope.  But
> > we do need input on the question of how to tackle the
> > restructuring (if it's agreed that it's necessary) question,
> > whether it's details on how to construct a blue-ribbon panel
> > or to recommend kicking the whole thing over to the IESG.
> > 
> > Melinda




More information about the Problem-statement mailing list