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

Dave Crocker <> Sat, 01 December 2012 23:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4845611E80CC for <>; Sat, 1 Dec 2012 15:14:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jZMYyEGSiEFO for <>; Sat, 1 Dec 2012 15:14:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A9A0B11E80A5 for <>; Sat, 1 Dec 2012 15:14:08 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id qB1NE5Kh026572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 1 Dec 2012 15:14:05 -0800
Message-ID: <>
Date: Sat, 01 Dec 2012 15:13:58 -0800
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Stephen Farrell <>
Subject: Re: Idea for a process experiment to reward running code...
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 ( []); Sat, 01 Dec 2012 15:14:06 -0800 (PST)
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:14:09 -0000


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

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


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.


  Dave Crocker
  Brandenburg InternetWorking