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

Hector Santos <hsantos@isdg.net> Sun, 02 December 2012 00:47 UTC

Return-Path: <hsantos@isdg.net>
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 6A8601F0C69 for <ietf@ietfa.amsl.com>; Sat, 1 Dec 2012 16:47:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 t-JCPaqNdPhS for <ietf@ietfa.amsl.com>; Sat, 1 Dec 2012 16:47:20 -0800 (PST)
Received: from groups.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D065C1F0C5C for <ietf@ietf.org>; Sat, 1 Dec 2012 16:47:11 -0800 (PST)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2049; t=1354409217; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=xo2egkmw1w0bjutFbXyGgYl02Z4=; b=pq9NpHto4zEHI0aphtb/ wHwlVFLGZ9ekbdSHfASqqpSw4bb6EWqkO3fqQmad2Ckp7PML665TaIbtUflmtt7l +c+oesENoriiICJVx6iLiMur77/o+nbrqvDHAsgLr+xaQt02sKWTQwIJqBEOXR+0 Qr/rBdpF+r1NLAuTuCN7loI=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Sat, 01 Dec 2012 19:46:57 -0500
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com;
Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1840981055.8610.3948; Sat, 01 Dec 2012 19:46:56 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2049; t=1354408850; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=TAqC1Y1 m1zniKkRDA6GT6dIAKChoDcheTtY3CJ4nLKM=; b=Tl6tTqk10dJWRUH+TcepNyX AUprNOXJbPgAJ2JWaqo88udAf/0d93mdpdj/+MKAQfNKR/BA3WFKJ9L5bBhBPkMH 6hoG2T2hlkyMLHT4Bh+0WG+6fjjwxhXWJfi+7PXveRFQ9yq4lJKKOt3J8+LaTTNL kt2lHg/LUwBk3lsjHLKc=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Sat, 01 Dec 2012 19:40:50 -0500
Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2439713585.10.5552; Sat, 01 Dec 2012 19:40:49 -0500
Message-ID: <50BAA518.1030208@isdg.net>
Date: Sat, 01 Dec 2012 19:47:20 -0500
From: Hector Santos <hsantos@isdg.net>
Organization: Santronics Software, Inc.
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: Idea for a process experiment to reward running code...
References: <50BA64AB.3010106@cs.tcd.ie>
In-Reply-To: <50BA64AB.3010106@cs.tcd.ie>
Content-Type: text/plain; charset=UTF-8; format=flowed
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 00:47:21 -0000

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?

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.

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

-- 
HLS