making strategic problems concrete

[Bound, Jim]

James,

I am very honest person.  So let me try to be very honest and you tell
me if I have it wrong.

I hear you saying if consensus does not work then we may need an
alternative to decision process?

Yes or No?

Thanks
/jim

 


> -----Original Message-----
> From: James Kempf [mailto:kempf at docomolabs-usa.com] 
> Sent: Monday, March 24, 2003 2:33 PM
> To: Bound, Jim; Dave Crocker; problem-statement at alvestrand.no
> Subject: Re: making strategic problems concrete
> 
> 
> 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
> > > >
> > > >
> > >
> > >
> >
> >
> 
>