On Sat, Sep 10, 2011 at 5:47 PM, Dave CROCKER <dhc@xxxxxxxxxxxx> wrote: > > > On 9/9/2011 10:47 AM, Jari Arkko wrote: >> >> It was also very >> difficult to make a full determination, because a lot of the discussion >> has been >> on tangential topics, because in many cases it has been hard to see if a >> person >> is on the "no objection", "absolutely not", or "I have these additional >> ideas" >> camp, and because not all points raised in the discussion got responses. > > > The pattern of failure to make changes to IETF process and structure has > involved many people and many years. This means that there is an underlying > problem with making change that has nothing to do with particular > individuals or particular proposals. Another way of looking at it might be that people in general try to solve everything and make thing perfect... and in that process forget that it really is all of those small steps that matter. One good proposal that address and solve one problem in a good way is one of those small steps. ... and btw, I haven't read this entire proposal all the way through, but if it do address one problem and solve/fix it, then this proposal for sure is a good thing. One of those small steps :-) --- Roger J --- > Whatever the details in any one case, there's been an overriding consistency > to my eyes: Proposals die from the death of a thousand criticisms. Rather > than work to a common proposal, there is always a pattern of decrying a > proposal's lack of perfection and a variety of different proposals are put > forward, none garnering a base of support. > > That is, rather than displaying the usual IETF style of seeking compromise > to make progress, efforts are killed by individual, rigid idealism. (In > terms of project management, I think there also tends to be a failure to > develop a core of supporters to provide vigorous aid in making progress, but > there have been exceptions that still failed.) > > In the current case, it's been particularly impressive to see criticisms > against the proposal because it does not solve problems it is not trying to > solve and because other problems are deemed "higher priority". > > Nevermind whether the proposal does something constructive, let's complain > that it doesn't do enough. > > Before the jointly-authored draft was released, I lobbied to have it contain > a longer list of possible justifications, specifically to reduce the danger > of relying on everyone's agreeing with any specific justification. We > stalled on releasing the document because of this and I finally decided that > since the more challenging, normative content had agreement among the > authors, we should not hold the document back on this non-normative point. > > No matter the document's own efforts at justification, there is a basic > reality we have a non-functioning standards sequence that ought to embarrass > us, and an effort to get it better aligned with reality ought to be > intuitively appealing. > > There's a good argument for simply going to a one-step process; the argument > against it is that there might be benefit in the proposed two-step and we > will never know if we directly jump to one-step. Personally, I think a > low-hurdle step that permits recording the actual success of a protocol is > worthwhile and warrants the second step. > > Folk who put forward a proposal tend to be absolutely certain that it will > make everything -- or at least quite a bit -- better. I certainly have held > that view for mine and we've been seeing others demonstrating equal > certitude about theirs. > > The problem is that when it comes to organizational change, it's rare that > anyone can legitimately be certain of efficacy, nevermind the details of > unintended -- and usually deleterious -- consequences. (This well-enough > established to be a cliche when teaching organizational behavior and the > like.) > > That's the reason initial changes should be small and simple. It's even > more important when the community is not well-aligned. > > The current draft makes relatively small changes, but includes > clarifications that ought to be helpful in both lowering some actual > barriers and explaining purpose. While I'm not in the camp that expects > this to change working group or Area Director behavior all that much, > regarding new Proposed, it might, and that would be nice. > > More, it provides substantive clarifications for cycling at Proposed and for > the criteria to reach Full. I view both of these as significant. > > The most important requirement in making systemic change is creating > momentum for being productive. For "interesting" systems needing > significant change, this is best done by starting with a baby step. > Instead, the IETF seems intent on throwing the baby of progress out with > the bath water of perfection. > > d/ > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > -- Roger Jorgensen | rogerj@xxxxxxxxx | - IPv6 is The Key! http://www.jorgensen.no ; | roger@xxxxxxxxxxxx _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf