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]

Randy Bush <randy@psg.com> Fri, 01 February 2013 05:14 UTC

Return-Path: <randy@psg.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4995821F8971 for <ietf@ietfa.amsl.com>; Thu, 31 Jan 2013 21:14:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMvI5RLdvLnH for <ietf@ietfa.amsl.com>; Thu, 31 Jan 2013 21:14:55 -0800 (PST)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id E219621F895B for <ietf@ietf.org>; Thu, 31 Jan 2013 21:14:55 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from <randy@psg.com>) id 1U18xi-000HMD-9q; Fri, 01 Feb 2013 05:14:54 +0000
Date: Fri, 01 Feb 2013 14:14:53 +0900
Message-ID: <m28v78linm.wl%randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Barry Leiba <barryleiba@computer.org>
Subject: 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]
In-Reply-To: <CAC4RtVCipnE2q-91eVJq0aEt_sr+J5DmgQQWH5qkE+QmTvoscw@mail.gmail.com>
References: <008501cdfeca$59a77cd0$0cf67670$@olddog.co.uk> <5109680A.1040400@dcrocker.net> <CAC4RtVCipnE2q-91eVJq0aEt_sr+J5DmgQQWH5qkE+QmTvoscw@mail.gmail.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
Cc: IETF Disgust <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Feb 2013 05:14:56 -0000

> 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.

perfection is the enemy of good

and adding complexity to overcome objections is an engineer's disease

randy