Re: Idea for a process experiment to reward running code...

Stephen Farrell <> Sat, 01 December 2012 23:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A7D7D21F869B for <>; Sat, 1 Dec 2012 15:21:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VXZCLdvKqOYN for <>; Sat, 1 Dec 2012 15:21:41 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9DDB521F86A9 for <>; Sat, 1 Dec 2012 15:21:40 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 91815BE58; Sat, 1 Dec 2012 23:21:18 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U-ZG0BUQQLCF; Sat, 1 Dec 2012 23:21:17 +0000 (GMT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 8A7ACBE53; Sat, 1 Dec 2012 23:21:17 +0000 (GMT)
Message-ID: <>
Date: Sat, 01 Dec 2012 23:21:17 +0000
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
Subject: Re: Idea for a process experiment to reward running code...
References: <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 01 Dec 2012 23:21:41 -0000

On 12/01/2012 11:13 PM, Dave Crocker wrote:
> Stephen,
> On 12/1/2012 2:56 PM, Stephen Farrell wrote:
>>> At a minimum, any proposal for change should be expected to justify the
>>> specific problem it is claiming to solve --
>> Disagree. RFC 3933 says:
>> "A statement of the problem expected to be resolved is
>>        desirable but not required..."
> The IETF has become a curious place.  This is twice in two days I've
> cited pragmatics and been taken for citing formal requirements. Believe
> it or not "should be expected" is pretty lousy language to invoke for
> citing formal organizational requirements.
> IMO a proposal that does not justify itself with a clear statement of
> the problem, the seriousness of the problem, and a basis for believing
> that the proposed solution will matter is frankly not a very serious
> proposal.  It has done none of the hard work of distinguishing itself
> from myriad other, appealing proposals that might randomly be generated.
> I do realize that IETF culture has come to enjoy making and pursuing
> proposals that satisfy none of these criteria.  That's why I've taken to
> noting that we use the word "experiment" to justify a failure to do
> adequate homework or be accountable for the outcome.  (Or even be able
> to measure the outcome.)

IMO IETF culture has become too process-driven. And yes, I do
interpret your question (which is not unreasonable on its face)
to be saying that a justification is formally required.

My reluctance to get into this is based on an opinion that process
change proposals with more words attached tend to just not happen,
so fewer words is better. And I also think you and many others are
well placed to decide if you think this is a worthwhile change or
not, independent of any reasons for which I propose it. So I really
do think all the motivation text that'd be perfect fodder for
endless discussion is neither necessary nor useful here.


>> There's a reason for that IMO - all proposed process changes seem
>> to generate *lots* of comment that there's a better problem to
>> solve elsewhere.
> Stephen, what you seem to be saying is that it isn't reasonable to
> expect serious analysis in the formulation of a proposal, when it is put
> forward, because other folk might/will prefer a different -- and equally
> ill-formulated proposal?
> It certainly is a pain to have to provide meaningful justification.
> On the other hand, it's pretty irresponsible not to.
>>> that is, to establish the
>>> context that makes clear the problem is real and serious -- and that the
>>> proposed solution is also likely to have meaningful benefit.
>>> I share the frustration about lengthy standardization, and particularly
>>> with delays at the end.  And certainly there is nothing wrong with
>>> adding parallelism where it makes sense.
>>> However absent a consideration of the lifecycle, the current proposal is
>>> a random point change, quite possibly an example of looking for lost
>>> keys under a lamppost because that's where it's easiest to see.
>> You may be right, I don't make any claim that this is going to
>> be super-good. OTOH maybe this is worth trying to see if we like
>> it or not.
> Maybe more cookies at breaks will produce better IETF work.
> Maybe a posting limit of one message per day will produce better IETF work.
> Maybe...
> There's an infinite number of stray proposals any of us could formulate.
>  But they aren't free to pursue.
> And relying on the whim of popular fashion -- oh, let's all follow
> today's pretty flashing proposal -- is mostly distracting from finding
> and fixing real, strategic issues.
> d/