making strategic problems concrete

[James Kempf]

I'm not proposing any. However, I believe that we need to be aware of the
problems with concensus when the number of people involved is larger than can
comfortably be accommodated by small group interaction, where concensus works
best.

            jak

----- Original Message -----
From: "Bound, Jim" <Jim.Bound at hp.com>
To: "James Kempf" <kempf at docomolabs-usa.com>; "Dave Crocker" <dhc at dcrocker.net>;
<problem-statement at alvestrand.no>
Sent: Monday, March 24, 2003 11:05 AM
Subject: RE: making strategic problems concrete


> James,
>
> What alternative do we have to consensus?
>
> /jim
>
>
>
>
> > -----Original Message-----
> > From: James Kempf [mailto:kempf at docomolabs-usa.com]
> > Sent: Sunday, August 24, 2003 1:22 PM
> > To: Bound, Jim; Dave Crocker; problem-statement at alvestrand.no
> > Subject: Re: making strategic problems concrete
> >
> >
> > Jim,
> >
> > I think another problem is sometimes there are just multiple
> > possible designs with equally good technical properties, with
> > minor tradeoffs in one direction or another. From an
> > engineering standpoint, any of them might make sense. From a
> > market standpoint however, people want one to avoid costly
> > investments in multiple different kinds of infrastructure.
> > The difficulty is how to select one. Using concensus may
> > ultimately lead to the different parties simply failing to
> > yield, or incorporating different parts of each design
> > resulting in an overall design that is much more complex than
> > really necessary.
> >
> >             jak
> >
> >
> >
> > ----- Original Message -----
> > From: "Bound, Jim" <Jim.Bound at hp.com>
> > To: "Dave Crocker" <dhc at dcrocker.net>;
> > <problem-statement at alvestrand.no>
> > Sent: Sunday, March 23, 2003 9:24 PM
> > Subject: RE: making strategic problems concrete
> >
> >
> > >
> > >
> > >
> > > >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
> > >
> > >
> >
> >
>
>