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

Stephen Farrell <> Mon, 03 December 2012 13:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF82421F8596 for <>; Mon, 3 Dec 2012 05:43:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.526
X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wp5ZjS4QFZ8i for <>; Mon, 3 Dec 2012 05:43:10 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DDEA621F84C1 for <>; Mon, 3 Dec 2012 05:43:09 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 31841BE3C; Mon, 3 Dec 2012 13:42:48 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eVdbql1GbptE; Mon, 3 Dec 2012 13:42:47 +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 64809BE38; Mon, 3 Dec 2012 13:42:47 +0000 (GMT)
Message-ID: <>
Date: Mon, 03 Dec 2012 13:42:48 +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: John C Klensin <>
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 13:43:10 -0000

Hi John,

On 12/03/2012 12:29 PM, John C Klensin wrote:
> --On Monday, December 03, 2012 11:28 +0000 Stephen Farrell
> <> wrote:
>>> Encouraging running code is a Good Thing. Publishing sloppy
>>> specifications is a Bad Thing.
>> Sure. I guess I'd hope that we push back on sloppy specs as
>> usual, but that the running code might make that less likely,
>> or at least more likely to be just editorial.
> Stephen,
> I agree with Brian, but want to reinforce thinking about this a
> little differently and in a way that may draw several other
> sub-threads together.  The IETF is functioning here as a
> standards body, not an certification body for implementability.
> Knowing that something can be implemented, and implemented at
> production quality, has traditionally been an IETF hallmark (and
> hence part of Dave Clark's slogan) relative to other bodies who
> have standardized the un-implementable.  IMO, when we approve
> something as a Proposed Standard, it suggests that we have
> evaluated and approved it along three quite separate dimensions:
> 	(1) Utility of the idea as something that should be
> 	implemented (or at least as a decent and reasonable way
> 	to do something)
> 	(2) Quality of the protocol and whether the
> 	specification adequately describes it.
> 	(3) Whether the specification can be implemented
> Failures are possible on any of the three.  It is possible for a
> well-specified and implementable idea to be utterly useless.  It
> is possible to have a useful and well-designed protocol, with
> implementations by insiders, to be so badly described that it is
> unlikely that anyone else could figure out how to implement it.
> It is, as Brian pointed out in his recent note, possibly to have
> a hack-level implementation and/or one that doesn't work in the
> edge cases.
> Using any of those three in a way that enables shortcuts around
> the other two puts us at risk or creating bad standards.  Even a
> few bad standards could be used to hold the IETF up to ridicule
> in ways that would weaken everything else that we do for a long
> time... and the fact that we saw them as the result of a process
> experience would be no protection at all.  Worse from the
> standpoint of a speed-up procedure, someone's discovering a
> problem after a hasty IESG approval could easily lead to an
> appeal on the grounds that the process used did not allow for
> adequate review, a result that would cost far more time than the
> difference between the current and proposed procedure.
> As others have pointed out, there are lots of other ways to
> speed things up, most of which fall within the discretion of
> individual WGs, ADs, and the IESG without any changes at all.
> At least a few of them would involve "changes" back to what RFC
> 2026 already specifies, including treating Proposed Standards as
> Proposed Standards, and eliminating, e.g., days or weeks or
> post-IETF-Last-Call AD nitpicking over text in favor of
> practicing the intent of the "no known technical defects" rule
> of 2026 and letting the RFC Editor do their job.  But "you claim
> to have done consideration 3, therefore you get to shortcut
> considerations 1 and 2" should not be one of them.

So are "hasty" and "shortcut" maybe pejorative ways of
saying that we cut out some of the "nitpicking" ;-)

Anyway, I'm not suggesting we forget #1 or #2 at all and
yes some or maybe all of what's proposed could already
be done but I think its notable that that is not being
done, so the proposal is a 3933 experiment to see if
putting some more emphasis on #3 will work or not.

So I do hope we run the experiment.


> best,
>    john