making strategic problems concrete

[Marcus Brunner]

James,

I have not seen another standardization organization having a better 
solution. Agreeing is a long painful process, which we can not avoid.

Marcus

--On Sonntag, 24. August 2003 10:22 -0700 James Kempf 
<kempf at docomolabs-usa.com> wrote:

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



--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: brunner at ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
Phone: +49 (0) 6221 905 11 29
Mobile: +49 (0) 163 275 17 43
personal home page: http://www.brubers.org/marcus