Re: Uneccesary slowness.

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

 



David,

> >  For example, as you note, the IESG approves working groups and working
> >  group
> >  charters.  So the IESG does, in fact, have the ability to control the
> >  later
> >  demand placed on it.
> >
>  Are you suggesting that we start disapproving new working groups
>  since they cause work for the IESG ?

That does sound pretty silly, doesn't it?  

But, then, it sounds pretty silly to have a pattern of filling up with working 
groups when we cannot provide adequate support to them.  (Note, for example, 
that having too many working groups means we have too many parallel sessions 
and cannot get the breadth and depth of participation we need.)

As I said, we do not tolerate that sort of continued congestion in an Internet 
service, so why do we fail to attend to the problem in the IETF?


>  We can help to fine tune charters. We can engage the community to
>  scope the work better. However, we are explicitly not chartered to
>  review charters for the amount of work that they cause for the IESG.

Working groups are expensive.  Very expensive.

Not just in iesg time, of course, but in quite a variety of resources 
consumed.  Having lots of working groups seems to mean that a) we give very 
poor support to them, and b) we hassle them when they are done.

If the IESG is really concerned about quality, then it needs to both faciliate 
and apply pressure at the beginning of the working group and continue these 
during the life of the working group.  

The silliest thing we can do is permit poor charters, floundering working 
groups and then veto their documents after 3-10 years.

So, what sort of support?

1. Much, much better charters.  For example, we do not even try to enforce the 
requirements specified in the Working Group Guidelines RFC.

2. Much better oversight of new working group chairs, to ensure that the 
group gets traction on its effort.

3. Insistence on review of major decisions along the way.  

4. Reorganization of IETF management to handle the current load and 
diversity of participation better, with a particular eye on finding ways 
to prevent single-person vetos.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net



_______________________________________________

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]