A ceiling on the number of working groups

John C Klensin john-ietf@jck.com
Tue, 10 Dec 2002 19:54:52 -0500


--On Wednesday, 11 December, 2002 02:15 +0200 Jari Arkko
<jari.arkko@piuha.net> wrote:

> The IETF and the Internet would be a much better place if there
> weren't for the damn users. And their requirements! And those
> new applications. We did fine with just ftp and telnet on our
> time. Let's give them the Internet busy signal, no more users
> needed and no more applications allowed. After all, if the
> choice is between better management structures, better
> architecture, and more people at IETF versus not giving the
> humankind what it wants -- clearly its easier for the
> humankind to adapt than for the IETF to deliver more.
> 
># sarcasm mode off

Jari,

Sarcasm aside, the above is pretty close to an assertion that it
is IETF's responsibility to address all needs and solve all
problems.  I do not believe that.  I believe that there are some
things we are good at and have the skills for, and some we are
not so good at (or completely terrible at) and that we should be
quite willing to do fewer of the second group in order to do the
first group better and/or faster.

> Seriously though, I do agree that in some cases WGs got
> chartered that they should not have. However, I see this
> more as a technical mistake rather than a volume issue.

It may be that we would draw the line differently, but I suggest
to you that it is often neither a technical mistake (in the
narrowest sense) nor a volume issue.   We have a long history of
people coming to the IETF and saying, more or less, "there are a
bunch of us, and we are interested in this, and, while we could
as well take it to the FooForum, we like the IETF's procedures
and reputation better".  When they are told "this doesn't belong
in the IETF", their response is "look at how many people stood
up at the BOF when we asked whether a WG should be created".  At
present, the IESG has no guidelines and few incentives to push
back on such groups.  And the IESG members end up in the middle:
the group continues to scream that they are entitled to a WG,
and the rest of the community says, usually quietly, "well, if
they want to do it, why not let them".  So the group gets
created, and the attention of the relevant IESG member gets
further diluted, and then people complain that other WGs aren't
getting as much attention as they deserve on a timely basis.

As I said in Atlanta, one has to be at least mildly crazy to
take an IESG position under these circumstances and we should
all be really grateful that we have some many competent and
caring slightly crazy people around.   But I don't think there
is an infinite supply.

> If there's demand for Foo then there has to be sufficient
> number of serious contributors, expected large-scale usage,
> and Foo will happen if our structure can scale to contain it.
> And I don't see any fundamental reason why we couldn't scale
> if we wanted to.

And I believe we are already operating above the scale at which
we can do work that is both competent (high quality) and timely.
The IESG is pretty close to, or past, the maximum size that
management theory and experience predict can function well as a
collegial/ consensus small group.

So, I don't know what you would consider a fundamental reason,
but I suggest that, if you know how to make things scale to a
larger number of WGs, you should start suggesting them in very
explicit terms.   The alternative is to seek other ways to
reduce the workload and stress.

> So, please, let's talk about qualitative controls that we
> could e.g. enforce on WG creation. Require document editors
> and reviewers beforehand.

Done that.  Hasn't helped much.

> Check market estimates for the user space of the technology.

I'd be really interested in how you would propose that a
standards body do this in a meaningful way without violating
various "antitrust" or "competitiveness" rules.   And remember
that inflating market estimates to promote a would-be product or
idea is an old, and well-established sport, so I'm interested in
how you would propose to evaluate the estimates you get, ideally
without adding to IESG workload.

> Require earlier implementations.

Good idea in principle, but one that has proven impractical for
many IETF efforts, sometimes due to market issues of the form of
"if you wait for implementations, we will go our own way and
ignore you entirely".

> But let's not focus so much on quantitative, artificial
> limits.

Please stop complaining and make specific and implementable
suggestions starting with explaining what problem(s) you really
think we have.

regards,
    john