draft-klensin-overload-00.txt

["Spencer Dawkins" <spencer@mcsr-labs.org>]

Thanks to John Loughney for putting this draft on the COACH agenda,
and calling my attention to it.

If I understand the proposal, it can be summarized as:

-  Kill two working groups for every working group created in an area,
   until the number of working groups in the area has fallen by 25%.

This may be the best way of reducing IESG overload that we can
actually adopt, and if that's the case, we should adopt it. I've managed
to prod a couple of sitting ADs into saying "yes, I'm overloaded", and
that's the way I'm reading Erik's "Stepping Down" note, at
http://www1.ietf.org/mail-archive/ietf-announce/Current/msg24487.html.
We owe it to these folk who've given so much of themselves to help
them have something left for themselves.

Having said this, I hope we can come up with something better.

I apologize for discussing this proposal from a TSV perspective - that's
the area I'm most familiar with - but my home area contains a variety of
working groups, some doing classic transport (tsvwg, dccp, pilc),
but others doing telephone URLs (enum), emergency preparedness
(ieprep), and a variety of very application-ish work (sip and especially
sipping, mmusic), USING transports. My recollection (others?) was that
pwe3 was put in TSV simply to make sure that they thought about
congestion avoidance.

I'm seeing draft-klensin-overload-00.txt as a "hard ceiling" for at least a
year in TSV,
If there's no other way, great. Is there no other way?

I'm not telling ANYONE that I'm smarter than the IESG. I'm saying that
before we adopt a pretty Procrustean measure based on NOT changing
the current areas (or at least not changing them much), I'd like for us
to think about what the areas might look like, if we started with a clean
sheet.

There are two things getting conflated here - how big does an area need
to be, and how big the IESG needs to be (since all the ADs sit on the IESG).
I asked Harald about a month ago about pre-NOMCOMing ADs, so that
the IESG has "bench strength" when the IETF creates a "temporary area",
or an AD steps down (or simply dies while in office), and Harald said the
IESG was too big for his tastes today.

Have we ever found a way to solve a problem like this, that didn't involve
inserting a level of hierarchy/indirection?

Spencer