making strategic problems concrete

[Bound, Jim]

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
> >
> >
> 
>