Straw process outline for dealing with structural and practices problems

[Dave Crocker]

Folks,

JCK> And that brings me back to my Thursday evening comment.  I
JCK> think it is time to _do_ something, not design structures for
JCK> talking about what to do.    I think we should go through the

John and others have raised a number of concerns about a number of
proposals, notably the one coming from a subset of the problem-statement
editors' team. I was/am part of that team, but did not contribute to the
proposal, except for a quick, late-stage review.

I think we need to pursue some very separate lines of discussion, to
give this whole topic proper consideration.  What follows separates
discussion of the timing of change, the source of proposals for change,
and the authority for making decisions about change.


1.  TIMING OF CHANGE

I keep pointing out how long it has been since Yokohama, because this
much passage of time, with no change, suggests that the actual operation
of the IETF is proving to be more interested in discussing process than
in improving our work... by making changes that will have real and
useful effect. (No, I don't believe anyone actually intends this to be
true, but so far, our actions show the truth of that fact.)

I also point it out because it means that we are suffering the same
problem with timeliness in our change effort as we do in our protocol
development: loss of market window. In other words, loss of opportunity
and relevance.

In this case, the "market window" has to do with the attitudes of
participants. When folks feel a deep sense of frustration and the
frustration does not get resolved anytime soon, folks will typically
give up. This fact plays heavily on the interpretations and validity we
can assert, about "feedback" we are getting during our continuing
process. (For the statistically inclined, think of this as biasing the
sample.)

So, the calls from a number of folks to start making changes, rather
than to continue talking about the process of change, seems is entirely
appropriate. The fact that it is coming from a number of independent
participants -- and I continue to be amused when John K. and I agree on
a topic's recommendation phase, not just its analysis phase -- should
carry some weight.


2.  SOURCE OF CHANGE PROPOSALS

At this point, quite a few people/groups are suggesting that the source
of useful proposals for change need to come from... The IETF populace
and not from specially "authorized" representatives.

There is an key, implicit message here, folks.  Ultimately, this is
"our" organization and we call for the specifics of change, not just the
concept of change.  Yokohama made clear that change is needed, but it
did not specify the details.  The details are in the specifics of
careful proposals.  They must come from us.

The fact that this perspective seems to be coming from a number of very
independent sources suggests that it is not all that controversial. At
the least, I haven't seen a serious alternative to it proposed recently.

The bottom line from this is that we need concrete, detailed proposals
for concrete, specific changes, backed by their rationale.  Some are
starting to emerge.

What is essential is that anyone having an idea that is not yet written
down and available for review needs to do that work.

Anyone.

As in, not just our "leaders" and not just some designated committee.

Anyone and Everyone.


3.  AUTHORITY TO ADOPT SPECIFIC CHANGES

So, given a panoply of concrete, detailed, serious proposals, how does
the IETF choose ones to implement?  Here lies the divergence of views.
(And frankly, I was getting tired of agreeing with John so much.)

Some suggest the IESG.  Some suggest a blue-ribbon committee.  Some
suggest the IETF Plenary.

I now believe all those ideas are fundamentally flawed, though I remain
somewhat biased towards the last of these, though it too is flawed.

The universal flaw is that all of them ignore the real need for real,
broad, community support. Whatever is chosen, the community has to
embrace it. This being a community of rather independent personalities,
embracing does not occur because someone dictates it.

The IESG has no history deciding what process changes are best for the
IETF. Further, its members have no special expertise in such design and
selection. Choosing some decision mechanism other than the IESG does not
imply that we are in melt-down or that the IESG is incompetent. It
suggests that that is a body with different skills and perspective than
is appropriate for this category of decision-making.

A select, "blue-ribbon" committee is always an appealing idea, and
always suspect.  It, too, has no track record of success for the
decision it is making.   Unfortunately, there is no existing
IETF-related body that does have that track record or that even
obviously has the necessary skills about organizational design and
change.

The Elwyn-et-al proposal invokes an multi-source sampling mechanism for
populating the committee. I've come to cherish the benefit of ANY
diverse sampling technique, for populating a decision-making group that
is intended to represent a larger community, as long as it has any
reasonable basis. In particular, there needs to be some assurance that
the folks being chosen are likely to be clueful. Its key strength is
that it ensures a real diversity of views (and agendas.) Hence, it works
on independent contributions. This forces a negotiation and compromise
process.

The problem with using an IETF Plenary session as the decision-making
body is that it may well be too highly biased (limited) a sample of the
population.

Ultimately, however, I believe that the real decision-making needs to be
done by garnering strong support from the community. I won't go as far
as invoking the usual "rough consensus" criterion, because we now have
quite a bit of experience showing how difficult that can be to acquire
or gauge, for "social" decisions.

And let's be clear that that is the realm we are in. This is human and
group stuff, not technical. So, few if any of us have any real skills in
this. Worse, finding folks who *do* have those skills does not solve the
problem. In fact, there is no way to guarantee that any proposal will
work as intended or even that it will work well. That is the sad fact of
life about this type of organizational change, especially for a group
this diverse and diffuse.

To me, that means the only thing we can do is to make sure that the
decision is as broadly-shared as we can make it. This begins by
developing a constituency of support for a candidate proposal.

The nice things about such a direction of effort is that it lessens the
import of choosing the best group to make the "final" decision.

d/
--
 Dave Crocker <mailto:dcrocker at brandenburg.com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>