ietf
[Top] [All Lists]

Re: improving WG operation (was Re: Voting (again))

2005-04-28 17:40:49
 I certainly
 endorse the position that we could use resources more effectively if [we]
 exercised more care about which working groups [were] chartered.  But,
 again, the IESG makes those decisions:


More care about chartering is cited periodically, and I agree that it
is needed. But we seem able to get neither a clear, concrete sense of
what it means to use more care, nor the community resolve to pursue
it.  Not really.

On John's latter point that the IESG makes those decisions, I suggest
that it is at the core of at least two serious problems:  One is that
is abrogates the community's responsibilities and the second is that
it guarantees that the IESG remains overburdened.

More and more, we see the general IETF community lacking a sense of
responsibility for the health and utility of the IETF. Well, how can
we feel responsible if we are disenfranchised?

That is what it means to have others making the important decisions.
The more we march down the path of having a classic, hierarchical
authority structure, the more the IETF looks and acts like any other
stiff, bureaucratic, unproductive standards group.

The IETF's origins in rough consensus translated into community
action and community responsibility.  That goes directly against the
idea that it is some elite oligarchy's authority to make the
decisions.

There is a long way between the highly centralized authority
structure we now have, and the mayhem of an extreme literal
democracy, where everybody 'votes' on everything.

But the original style of the IESG was to facilitate processes of
developing community consensus.  Such a description is fundamentally
at odds with a model that has that the IESG have primary authority
for making the decisions.

On the question of burden, the issue is simple: ADs often feel
sufficiently essential, to what they view as the necessary details of
an outcome, that they are more and more inclined to inject themselves
into it.

(One of the more poignant examples of this is when an AD gets sucked
into "ensuring" quality by participating in the working group as if
they were a primary technical contributor. At that point they are an
individual advocate for particular details, and they cease to be able
to perform their higher-level job of oversight.)

Others in this thread have cited the IESG's job as assessing
community consensus.  This, I think, should be viewed as the core job
of the IESG:  coordinating macro processes based on assessments of
community rough consensus (and looking for ways to develop it.)

After all, any successful output from the IETF depends upon community
adoption.  In that regard, the rough consensus model is really the
process of acquiring community ownership of the output, with the
expectation that the ownership makes it more likely they will
actually use it.  Take away real community involvement in the
decision and we lose the benefit of facilitating adoption.

For all this, the technical expertise of an AD remains extremely
important, but not as the basis for an AD "decision".  Rather, it
permits the AD to see problems and recruit community concurrence that
there is a problem.  The AD may well have insight to its solutions,
but frankly that should be viewed as an unexpected benefit. Good
ideas come from lots of places; as good as any particular AD might
be, no one can expect that they will have special insight that is
better than all others.

Yet today we almost require it.  Certainly the recent structure and
history of IETF process "trains" ADs to view their personal
preferences as being an ultimate authority.  That is, after all, what
the power of a veto communicates.

If an AD is unable to recruit rough consensus to their view, then
what exactly is the benefit of their being given a veto?

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



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf