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

Stephen Farrell <> Sun, 02 December 2012 14:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B1C4821F8431 for <>; Sun, 2 Dec 2012 06:37:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.483
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id adY2sWFHBRsb for <>; Sun, 2 Dec 2012 06:37:40 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9379D21F8231 for <>; Sun, 2 Dec 2012 06:37:40 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DCA08BE38; Sun, 2 Dec 2012 14:37:18 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id djLOo4B63QXL; Sun, 2 Dec 2012 14:37:14 +0000 (GMT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 7EDA3BE36; Sun, 2 Dec 2012 14:37:14 +0000 (GMT)
Message-ID: <>
Date: Sun, 02 Dec 2012 14:37:14 +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
To: Hector Santos <>
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
Cc: IETF-Discussion <>
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: 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.


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