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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F1DF21F8757 for <>; Mon, 3 Dec 2012 06:50:42 -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=[AWL=-0.000, 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 LWDrAZ1ZIXPm for <>; Mon, 3 Dec 2012 06:50:42 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id AB5DC21F870D for <>; Mon, 3 Dec 2012 06:50:41 -0800 (PST)
Received: by with SMTP id y2so2488282lbk.31 for <>; Mon, 03 Dec 2012 06:50:38 -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:content-type; bh=lNPncZIpytETQvg/nC6/cHWOyuag4NVfLw9pfIZ64yA=; b=q8k2ftSiCh6WLAvkBpmPEyknkcbxuipZD1msHYwrWRRhd2Wf+nN0lheXdfqjdqv6qs GuXn7AiY1++0v0SWJfvKUq3Uoda3p/sTAn5Dy/C7HB0nX0ZfbCbrKu9DSco326QBfE/p iaNsV0z5AKyWhw+CrI+UcKilQIkKQWxks+uI7psf8hopEGEKHItQcPj5Gs3FF667D8o8 Wp3OaUJS2a8qlkKyN5aO845PAY0oYIEEK7moVrHfpN6uVCOFIjljxW/6FpCvo1Zz3iiY MyhUSslDUruUNB6f1JPsWdsVEaQvV1TCppdONkRjksljaJXQiehw8iI6B1KJ3PwGTDtf yimA==
MIME-Version: 1.0
Received: by with SMTP id fa3mr4536172lbb.38.1354546238821; Mon, 03 Dec 2012 06:50:38 -0800 (PST)
Received: by with HTTP; Mon, 3 Dec 2012 06:50:38 -0800 (PST)
In-Reply-To: <1354545525.11916.744.camel@mightyatom>
References: <> <> <> <1354545525.11916.744.camel@mightyatom>
Date: Mon, 03 Dec 2012 09:50:38 -0500
X-Google-Sender-Auth: 0Mk3Kz9E6PJ_0ZJaHox4hIMuHio
Message-ID: <>
Subject: Re: Idea for a process experiment to reward running code...
From: Barry Leiba <>
To: IETF-Discussion <>
Content-Type: text/plain; charset="ISO-8859-1"
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:50:42 -0000

Elwyn says...

> However, I don't think that a short last call cycle need necessarily
> compromise cross-area review. There has always been the possibility for
> authors or wg chairs to request a early gen-art review with a view to
> checking out whether something is in good shape cross-area and for
> non-specialists.  This facility is not much used (I think I have done 3
> in 8 years on the gen-art team) but it is there, and I guess the team
> could cope with a few more since it doesn't drastically alter the total
> workload. So it would be entirely possible for a draft that might be
> fast-tracked to get some early review.

Do you really think it's likely that a chair who's trying to
fast-track a document will likely go out asking for early GenART,
SecDir, AppDir, and OpsDir reviews?

> Given that there is also open source code, reviewers have the chance to
> take a look at that and see the degree of hackiness involved.

This brings up something else that I've discussed with Stephen off list:

This proposal requires an *open source* implementation.  A robust set
of proprietary implementations, along with several interoperability
testing events, would not qualify.  But some untested open source that
someone knocked off in an afternoon would.  I find that odd.

I understand the desire to be able to inspect the implemented code,
but that would seem to rule out too many things, including stuff at
lower stack layers.  If the AD can look at the
implementations/deployments and talk with the implementors, the
openness of the source code is not an issue.  I'd be happy -- ecstatic
-- to have two or three proprietary, very-closed-source
implementations of most of the IMAP extensions, and have *no* need to
see the source code.  And I suspect that having shipping code in
routers is a good thing for validating new routing protocols, and also
suspect that we're not likely to be inspecting the source code of

I'd really prefer if we'd talk about open source being desirable, but
not having it be necessary.