Re: When is a 3933 experiment necessary? [Was: Last Call: <draft-farrell-ft-03.txt> (A Fast-Track way to RFC with Running Code) to Experimental RFC]

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

 



>      We are a diverse community.  Absent very, very strong consensus that a
> problem is serious enough to warrant a change, the community is not likely
> to line up automatically behind a proposal.  We will always have some people
> who prefer no change and some who offer their different, favorite
> approaches, or and some who offer a zillion tweaks.  In the aggregate, that
> makes for entropy, not consensus.
...
>    1. A wg has a committed core of participants who have agreed on a common
> goal.
>    2. A wg process is managed.
>
> On the average, proposals for IETF process change benefit from neither of
> these.

These are good observations; I agree with them, as well as with your
suggested approach to it.

I want to make a related point (which Dave's recommendation of classic
group facilitation can cut through if we allow it to):

We often pick on every suggested change and point out every possible
flaw, with different people holding out behind different flaws, and we
get stuck there.  There seems to be some assumption, when we do this,
that our current process doesn't also have significant flaws.  But the
very reason we're trying to change something is that we *already* have
a process with flaws.

We know that no process we ever come up with will be perfect, and
agreeing to change is a question of deciding what the flaw balance is.
 We need to allow ourselves to move from one (known, "comfortable")
set of flaws to a new set, *if* we can come to a reasonable agreement
that we've improved things in a useful way.

Barry


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