Re: Stuart's comments

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Folks,

What's happened is more complicated and more puzzling. Somehow the IETF process has run out of control, and taken on a life of its own, and taken us in a direction that makes little sense.

I agree with this, and unfortunately this is not the only instance.
...
In retrospect, the correct thing to have done at that point would have been to give up on the DNSEXT WG entirely in order to work with Stuart on a joint design, as was done with IPv4 link local (which successfully interoperated before the IETF became involved).


Successful IETF work begins by developing support to do the development work and support to use the output of that work. The work is then done for development and deployment.

The procedural simplicity and practical utility of this model tend to be vastly under-appreciated.

It requires essentially no bureaucracy -- other than to assess the support -- while still imposing a very substantial (but appropriate) barrier to approval. In its stead we have developed a mythology about "controlling" and "choosing" single solutions before the work is done, as if we -- the IETF community or the IESG -- have the prescience to make the choice.

I believe you folks are describing a really good example of why the more authority-based and pre-emptive pruning process -- before work is attempted -- is such a fundamental problem. It is based on theoretical analyses and hypothetical criteria, rather than... running code (and running community support.)

Successful "competition" relies mostly on this "productivity" filter/test. It is very, very rare that competing proposals both develop the necessary support and do the necessary work. Further, the competition has the obvious benefit of adding a timeliness factor. Efforts that do not make progress in a timely fashion are overtaken by those that do.

We used to trust the market to choose among competing proposals, so that the IETF process was primarily concerned with assuring a process of rational, open development. Instead, now, we purport to worry about the market getting confused by alternatives and about the market's inability to distinguish "bad" solutions.

The result tends to be that the IETF now serves to deprive the market of *any* (timely) solution and/or to provide overly complex, inappropriate ones.

As for the possible claim that the pruning is needed so that we don't waste IETF resources, folks really do need to take another look at how the IETF functions, since we do virtually nothing else to attend to efficiencies. If we were seriously worried about efficiencies, we would require working groups to sustain substantial community involvement, rather than devolving into having all meaningful activity done by only a small number of individuals. We also would worry far, far more about timeliness.

Certainly the random-walk of a popularity-based (ie, community support) filtering process can produce conflicting mechanisms that deploy simultaneously, where the conflict is either from competition or from unexpected interactions.

However it is simply not reasonable to let our fear of that eventuality take precedence to the extent that it defeats the basic utility of the IETF.

--

  d/

 Dave Crocker
 Brandenburg InternetWorking
 +1.408.246.8253
 dcrocker  a t ...
 WE'VE MOVED to:  www.bbiw.net

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]