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

Barry Leiba <> Mon, 03 December 2012 14:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E8D8521F84E9 for <>; Mon, 3 Dec 2012 06:25:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zCXV0SBhL23y for <>; Mon, 3 Dec 2012 06:25:18 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2692821F86C7 for <>; Mon, 3 Dec 2012 06:25:17 -0800 (PST)
Received: by with SMTP id y2so2462493lbk.31 for <>; Mon, 03 Dec 2012 06:25:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=y1P4fFCHkYTnNmHE0VdaEGI0jJkT+VviBqPKjxr4Dq4=; b=kC8C4ViXG+YF/zAgPKVD6tCfz39gYTq3Nly2Dzr74m/KA9lRNXj7pJgxbdbl7sn6hW XzkzRU9NgBfGgaU9OO9TNFWz1m+xmkNzVFpJSqHCTV6/v0u5M9KhKpsQPxqACecRxl+6 0mDMN6TjErMYnA0UOIg3fBQgnqOgJ/8vHu+o5F+5UgoqRpKarAI9CGMSk45TISxI+q0y B/Gg2+0JhAyGFpRE4NK0lVdsSEsvoR+xC0vFHa8lteFS0QaTCslaZimJ+firYXLRzEqz t84D9VgqwVKBnAIbASowULXO325aIXwk26vUO22srDEZnBKGUfQuJSB4ajIcu0fSTRW1 UlPA==
MIME-Version: 1.0
Received: by with SMTP id h5mr4473540lbi.3.1354544716990; Mon, 03 Dec 2012 06:25:16 -0800 (PST)
Received: by with HTTP; Mon, 3 Dec 2012 06:25:16 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Mon, 03 Dec 2012 09:25:16 -0500
X-Google-Sender-Auth: Yrjr5buz-dpH_Ju81r9HE_Wm6NY
Message-ID: <>
Subject: Re: Idea for a process experiment to reward running code...
From: Barry Leiba <>
To: Stephen Farrell <>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: IETF-Discussion <>, Stewart Bryant <>
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 14:25:19 -0000

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

This is true.

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

This is a stretch, and that *unprovable* assumption also bothers me.
We have lots of running code that implements specs badly.  We have
lots of running code that implements exactly what's in the spec and
misses everything that's missing (consider Martin's comment about
security and i18n).  We have lots of running code that doesn't
interoperate with other running code.  Your proposal specifically does
NOT require any testing of the running code, nor any interoperability
demonstrations (nor would I want it to).

Running code, when it's an organic part of the document development,
is undoubtedly a good thing -- it doesn't make everything right, but,
yes, it does do *some* spec validation and probably does help spec

But code that's written as part of a rote process, just to achieve
another check-box on the shepherd writeup and justify special handling
is not likely to provide any of those benefits.