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

Dave Crocker <> Sat, 01 December 2012 22:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EAE9E21F8B5D for <>; Sat, 1 Dec 2012 14:13:35 -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 Z2chNJ4OE-Ih for <>; Sat, 1 Dec 2012 14:13:35 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 73CDA21F8B5C for <>; Sat, 1 Dec 2012 14:13:35 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id qB1MDYBc019500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 1 Dec 2012 14:13:34 -0800
Message-ID: <>
Date: Sat, 01 Dec 2012 14:13:26 -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: Melinda Shore <>
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 14:13:34 -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 22:13:36 -0000

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

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

  Dave Crocker
  Brandenburg InternetWorking