making strategic problems concrete

[Bound, Jim]

>1) state precisely what fundamental operational problems they see
>
>            eg., not just "we've gotten big" but rather "our getting
>            big means attendees are not always seeking timely
>            productive outcome" or "it takes too long to hear
>            everyone's views" or...)
>2) state precisely what fundamental organizational or 
>operational changes they believe are called for (and how it 
>will fix> the problem.)

Technical work that has been accepted within the working group, which
also has strong technical proponents with different solutions, takes a
very long time to achieve compromise, and creates time-to-market barrier
for that technical work to achieve Proposed Standard, BCP, or even
Informational status.

Not sure what the solution is totally but thinking, but I think the
complexity as was pointed out in the plenary on this topic at the podium
was that problems are interrelated and why this job here is hard. Trying
to fix it with SIRs is not going to work.

A lot of the problems in the IETF are systemic from lack of trust.  Here
are a few, that in turn creates operational problems.

Consensus is not well defined, it permits a persistent reviewing of the
same topic over and over.  It is good to revisit our ideas, but after
first agreement, having defined checkpoints, similar to project change
control in industry, would assist with when a previous consensus point
can be open for review.  Or at least a process to do this so it is not
random and ad hoc.  This would also permit a bad consensus decision to
be revisited and prevent it not being revisited if it has become broken.

It is "perceived" that Design Teams, IESG, and just about everything we
do is a good ole boy network.  I believe this is not done on purpose nor
the majority of efforts.  But perception is reality.   This creates
distrust and machavellian moves by factions within the working group to
do end run around the good ole boy network.  This slows up the process
for any subject.  We need an open and documented process for any ad hoc
groups like SIR. 

IESG members should not have anything to do with the Nom-Com it is like
the Government being in the voting booth with you.  This creates a
distrust of our POISED process and a simple thing to fix.  No one near
the NOMCOM from the IESG or IAB except for formal questions. If having
knowledge at the meeting then use past IESG/IAB members or ISOC
Trustees.

Elistism.  For example, when an AD says "this list" don't have this
expertise that's really bad unless that AD knows everyone really really
well on that list.  I would argue that is not possible given the breadth
our ADs have to cover.  Better they don't say things like this, and its
rude. 

Most specs run into WG trouble when the mission, goals, objective,
assumptions, and problem being addressed are not known until far to late
in the process. This causes a longer time to reach consensus for each
point with the proposed work.  If each spec puts each of the above
attributes in the first section of its spec it will go a long way to
create a faster process.  Specs should be able to define those in no
more than 4 sentences.  It is also critical that assumptions be
discussed across the topic areas, because we often spend to much time in
debate of the solution when we did not realize our assumptions were
different.

I will stop here for now.

/jim