The IETF's problems

[Spencer Dawkins]

Ummm, but we DO have competing documents. I think we're more likely
to do them in parallel working groups (see IMPP/SIMPLE/XMPP for
running code), and that's probably better anyway (less mud-slinging
within a working group), but don't even START on how many IPv6
transition mechanisms we have, or how many MANETs we have, or ...

Spencer

----- Original Message ----- 
From: "todd glassey" <todd.glassey at worldnet.att.net>
To: "Melinda Shore" <mshore at cisco.com>; "Iljitsch van Beijnum"
<iljitsch at muada.com>
Cc: <problem-statement at alvestrand.no>
Sent: Tuesday, July 22, 2003 10:20 AM
Subject: Re: The IETF's problems


> Melinda - All -
> I have a question, and that is "do you consider the IETF's not formally
> allowing more than one standard track item per/WG per/initiative-scope" a
> problem?, because I do, and I consider it a serious one at that. What I am
> referring to is the fundamental issue of whether WG's should be allowed to
> limit the number of initiatives on any one track to one, and my take is
that
> the answer here is NO.
>
> My reasons for asking this are that RFC2026 and 2223 as well as 2418 all
> talk about the scope and process of the standards model, but none of them
> really have any process for one effort to supersede another unless that
> effort is done by the people "owning" that spot originally. There are no
> "hostile takeover guidelines" or processes, and that means that any
> evolution of challenge of a commercially used protocol has to have the
> blessings of the WG Chair and those that already own that standing in a WG
> (This of course pertains to existing protocols predominantly).
>
> So look - here is an example, Say I have a protocol for "Whiz-Banging" and
> there is already a protocol on track inside a WG that Whiz-Bangs but in a
> different manner. So the question is whether the IETF can support two or
> more Whiz-Banging implementations, or only one, because if the answer is
> "only one" then we need to also have a method for how would anyone
introduce
> the second Whiz-Banging protocol to the IETF to compete with the other?
>
> The problem is that the answer is today that functionally that this will
> never happen. And it is because it is very very unlikely that the folks
with
> their Whiz-Banging Protocol are going to want to roll-over and die...
>
> So then what happens??? The challenging Whiz-Banger is submitted to the
I-D
> staff as a disclosure. The I-D staff go to the WG Chair who makes a
judgment
> that they will not allow that protocol to harm the one that has already
> gotten investment from them and the others in their WG, so now the WG
Chair
> takes an active role in suppressing the challenging effort. But say the
I-D
> issues get past the WG Chair, so then perhaps with the current model the
I-D
> staff also decide that they don't want to publish this draft because it
> competes with an already in-process or existing standard or
standards-track
> participant. So this is yet another hurdle to publication and an issue. So
> now they as well are part of a restraint of trade development process as
> well.
>
> So the question simply is where does this end?  Just how does the IETF
allow
> for a competitive effort, since anything else seems to have serious legal
> issues with restraint of market development (the building of standards is
a
> key part of this). Or is this just not of importance to this IETF?
>
> Todd Glassey
> ----- Original Message ----- 
> From: "Iljitsch van Beijnum" <iljitsch at muada.com>
> To: "Melinda Shore" <mshore at cisco.com>
> Cc: <problem-statement at alvestrand.no>
> Sent: Tuesday, July 22, 2003 6:35 AM
> Subject: Re: The IETF's problems
>
>
> > On zondag, jul 20, 2003, at 19:28 Europe/Amsterdam, Melinda Shore wrote:
> >
> > > The discussion itself isn't doing much to distill the topic
> > > down to document text, and we need to stay focused.  Do you
> > > feel that existing text regarding scope in the problem
> > > statement document is inadequate?
> >
> > Not sure what you mean by scope.
> >
> > However, many of the "root" problems in the problems draft aren't that
> > fundamental. The three most fundamental problems I see are:
> >
> > - the IETF doesn't know what it wants to be: a "real" standards
> > organization or some kind of a grass roots movement
> > - inability to make decisions other than just wait until there is
> > agreement or come up with convoluted processes that only work because
> > people are forced to interact until they somehow solve the problem
> > - inability to manage resources effectively and efficiently
> >
> > Iljitsch
> >
>