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

Stephen Farrell <> Mon, 03 December 2012 10:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D45D21F85E2 for <>; Mon, 3 Dec 2012 02:49:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.581
X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yELDfGmGNv59 for <>; Mon, 3 Dec 2012 02:49:24 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 704F721F8581 for <>; Mon, 3 Dec 2012 02:49:24 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 85A00BE36; Mon, 3 Dec 2012 10:49:00 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id grbrK-Y0PoUv; Mon, 3 Dec 2012 10:48:57 +0000 (GMT)
Received: from [IPv6:2001:770:10:203:60a5:f3d6:2e7e:4b] (unknown [IPv6:2001:770:10:203:60a5:f3d6:2e7e:4b]) by (Postfix) with ESMTPSA id 471FEBE50; Mon, 3 Dec 2012 10:48:57 +0000 (GMT)
Message-ID: <>
Date: Mon, 03 Dec 2012 10:48:58 +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
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: Mon, 03 Dec 2012 10:49:25 -0000

Hi Stewart,

On 12/03/2012 08:06 AM, Stewart Bryant wrote:
> On 01/12/2012 20:12, 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]
> I find this a worrying proposal.

I hope I can convince you that its not.

> In the just-in-time world that we live in, too much of the review is
> already tail driven. 

I don't believe this touches on that at all (see below).

> Reducing the time that people have to notice that a
> doc is up for final review and then clear enough time in their calendar
> against a myriad of other tasks makes it more likely that the quality of
> review will diminish and hence the quality of our documents will diminish.

But this doesn't do that for IETF LC at all! Everyone
not involved in the WG gets just the same notice as now.

I guess I did assume that the chairs would not try surprise the
WG with this. I can add text along those lines.

So I don't think there's any bad effect here really.

> I would hate for us to act like an SDO that regards publication
> milestones as crucial and ship the draft regardless of the state of the
> technical design.

That's not at all what's proposed. Drafts still get worked
on in the WG and go through the same IESG evaluation and

What I hope is different is that drafts taking this optional
approach are higher quality, being based on running code.

> I would also note that sometimes it just takes time during review to
> mull over the full implications of the design and to surface the issues.
> With the current scheme if you miss a problem in WGLC, you can raise it
> during IETF LC.

Sure. And everyone is free to keep using that of course. To try
this process you need to get the WG chairs and have a happy AD
and running code. Really, I don't see that this would lower the
quality of our output (considering some of the drafts we do see
that may never have running code), rather the opposite. And the
main danger here I suspect is that this never gets used.

Does that make you less worried?


> - Stewart