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

Stephen Farrell <> Sat, 01 December 2012 22:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 97FE021F872C for <>; Sat, 1 Dec 2012 14:56:26 -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 LAPrwzAwGu8G for <>; Sat, 1 Dec 2012 14:56:26 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id ED29C21F8702 for <>; Sat, 1 Dec 2012 14:56:25 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 23B49BE4D; Sat, 1 Dec 2012 22:56:04 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6DS8yW2Tohdv; Sat, 1 Dec 2012 22:56:03 +0000 (GMT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 4AC3ABE49; Sat, 1 Dec 2012 22:56:03 +0000 (GMT)
Message-ID: <>
Date: Sat, 01 Dec 2012 22:56:03 +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 22:56:26 -0000

Hi Dave,

On 12/01/2012 10:13 PM, Dave Crocker wrote:
> On 12/1/2012 1:00 PM, Melinda Shore wrote:
>> On 12/1/12 11:36 AM, Dave Crocker wrote:
>>> What actual problem is this trying to solve?  I see the reference to a
>>> 'reward', but wasn't aware that there is a perceived problem needing
>>> incentive to solve.
>> I gather this is one of those "everybody knows" problems, where
>> "everybody knows" that it takes what's perceived as too long to
>> get documents through the post-wglc/pre-publication process.
> Yes.  Longstanding opinion held by many folk.  Might even be valid.
> The problem is a failure to look carefully at wg lifecycle and consider
> where meaningful -- as opposed to 'appealing' -- improvements can be made.
> 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..."

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.

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


>> There's probably some sort of sympathetic vibe running between
>> this document and recent discussion of nearly-cooked work being
>> brought to the IETF for standardization.
> rumblings of free-floating dis-ease, perhaps.  but are they really related?
>> If somebody hasn't already documented how long it takes to get
>> through the various steps once a document is into wglc, it
>> would be worthwhile to start taking notes.
> If a wg takes 2 years to get into wglc, a difference of a month doesn't
> matter, does it?  That's why I mean about total lifecycle.  Otherwise
> we're committing the classic system engineering error of inappropriate
> local optimization.
> d/