making strategic problems concrete

Wed Jul 23 13:29:03 CEST 2003

Marcus - I think Jim has some strong points here that need to be captured
here. But the all boil down to whether the process of olde (that of the IETF
of 20 years ago) still makes sense or can even survive a rudimentary legal
attack for damages. My feeling is that today's IETF would be washed up the
first time someone sues it for any number of issues and problems it has
foist upon a group of its participants.

More inline below.

----- Original Message ----- 
From: "Marcus Brunner" <brunner at ccrle.nec.de>
To: "James Kempf" <kempf at docomolabs-usa.com>; "Bound, Jim"
<Jim.Bound at hp.com>; "Dave Crocker" <dhc at dcrocker.net>;
<problem-statement at alvestrand.no>
Sent: Wednesday, July 23, 2003 4:04 AM
Subject: Re: making strategic problems concrete

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

Yes this is true.

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

I would disagree here though, it is not the IETF's role to control or decide
what is and is not a standard. Its the IETF's role to see that all
initiative get the same opportunities and treatment within its defined
process.

Let me amplify on this a bit, the IETF is not the decision gate for what is
and what is not foisted or released onto the Internet, but rather an oracle
to testify as to how well "it" works and as to whether "it" is operational
with other protocols (the other "its").  The IETF then is not a lobby. It is
not a guild where only people that pay the price get to play, and more
importantly it IS the every-man's Internet Standards Group by its own
charter.

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

The other problem is that when you have a consensus based system you have a
responsibility to show that the consensus was achieved reasonably and
ethically and that there is a reliable history demonstrating this integrity.
The IETF has NONE of this and that is the issue. There is no reliable
accountability for the consensus process herein and that also is an issue...
The real question is, that since the IETF was founded as a free, and
open-to-all type of organization, as to whether it can continue to survive
as such in todays world, which BTW is very different from the world of 20
years ago when the IETF's processes made more sense than they do today.

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