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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sun, 02 December 2012 14:37 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 B1C4821F8431 for <ietf@ietfa.amsl.com>; Sun, 2 Dec 2012 06:37:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.483
X-Spam-Level:
X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 adY2sWFHBRsb for <ietf@ietfa.amsl.com>; Sun, 2 Dec 2012 06:37:40 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9379D21F8231 for <ietf@ietf.org>; Sun, 2 Dec 2012 06:37:40 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DCA08BE38; Sun, 2 Dec 2012 14:37:18 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djLOo4B63QXL; Sun, 2 Dec 2012 14:37:14 +0000 (GMT)
Received: from [10.87.48.3] (unknown [86.46.31.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7EDA3BE36; Sun, 2 Dec 2012 14:37:14 +0000 (GMT)
Message-ID: <50BB679A.5070406@cs.tcd.ie>
Date: Sun, 02 Dec 2012 14:37:14 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Hector Santos <hsantos@isdg.net>
Subject: Re: Idea for a process experiment to reward running code...
References: <50BA64AB.3010106@cs.tcd.ie> <50BAA518.1030208@isdg.net>
In-Reply-To: <50BAA518.1030208@isdg.net>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: IETF-Discussion <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: Sun, 02 Dec 2012 14:37:44 -0000

Hi Hector,

On 12/02/2012 12:47 AM, Hector Santos wrote:
> This proposal sounds interesting but couldn't it run into conflicts when
> there are competition in running code?   Who's running code do you fast
> track?  How does it apply in the protocol updates area, i.e. BIS work?

Good point. I clarified that its just drafts heading to PS and
-bis drafts are just fine. (Might actually be well-suited for those,
and I'd not thought about that.)

> This proposal and thread, similar to the recent others, all seem to be
> looking for endorsing methods for lack of a better term, "rubber
> stamping" and fast tracking work items, in particular when there are WG
> related barriers holding back the WG work item(s) production progress.

Well, I'm after something where fast-track != rubber-stamp, but I
do agree that that's a hard balance to achieve. I'm not claiming that
this draft does achieve that balance, but such a balance is a goal.

Cheers,
S.

> 
> I personally do not have an issue with expediting work when the proper
> protocol engineering is done and the adequate engineering reviews are
> done, in fact, I depend on the IETF/IESG engineering do this work.  I
> depend on the long time wisdom and engineering judgment of the IETF
> leaders and reviewers to watch over sensitive engineering issues,
> including conflict of interest related matters.
> 
> In the end, we are talking about trusting the process.  If IETF
> participants, especially those who don't attend meetings and long
> participated remotely or via mailing list, lose faith in the WG process,
> these process change proposals may expedite IETF work, but they may also
> handicap the potential of a proposed standard, change and industry
> following.
> 
> -- 
> HLS
> 
> Stephen Farrell wrote:
>> Hi all,
>>
>> I've just posted an idea [1] for a small process improvement.
>> If it doesn't seem crazy I'll try pursue it with the IESG as
>> an RFC 3933 process experiment. If its universally hated then
>> that's fine, it can die.
>>
>> The IESG have seen (more-or-less) this already but it hasn't
>> be discussed, so this is just a proposal from me and has no
>> "official" status whatsoever.
>>
>> Any comments, suggestions or better ideas are very welcome.
>> Feel free to send me comments off list for now, or on this
>> list I guess. If there's loads of email (always possible,
>> this being a process thing;-) we can move to some other list.
>>
>> Regards,
>> Stephen.
>>
>> [1] http://tools.ietf.org/id/draft-farrell-ft
>>
>>
>