ietf
[Top] [All Lists]

Re: Conclusions on draft-housley-two-maturity-levels

2011-09-10 12:14:47
On Sat, Sep 10, 2011 at 5:47 PM, Dave CROCKER <dhc(_at_)dcrocker(_dot_)net> 
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf




-- 

Roger Jorgensen           |
rogerj(_at_)gmail(_dot_)com          | - IPv6 is The Key!
http://www.jorgensen.no  ; | roger(_at_)jorgensen(_dot_)no
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf