Re: "why I quit writing internet standards"

Miles Fidelman <> Wed, 16 April 2014 14:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0D6741A0204 for <>; Wed, 16 Apr 2014 07:32:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.281
X-Spam-Status: No, score=-0.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, MISSING_HEADERS=1.021, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rfmmpRjbIA5m for <>; Wed, 16 Apr 2014 07:32:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8CA401A01F5 for <>; Wed, 16 Apr 2014 07:32:45 -0700 (PDT)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id 37E53CC0B0 for <>; Wed, 16 Apr 2014 10:32:42 -0400 (EDT)
X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id O0cSvKarlP6N for <>; Wed, 16 Apr 2014 10:32:33 -0400 (EDT)
Received: from new-host.home ( []) by (Postfix) with ESMTPSA id 6A3DDCC0A8 for <>; Wed, 16 Apr 2014 10:32:33 -0400 (EDT)
Message-ID: <>
Date: Wed, 16 Apr 2014 10:32:33 -0400
From: Miles Fidelman <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:28.0) Gecko/20100101 Firefox/28.0 SeaMonkey/2.25
MIME-Version: 1.0
CC: " List" <>
Subject: Re: "why I quit writing internet standards"
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Apr 2014 14:32:47 -0000

Thomas Clausen wrote:
> On 16 Apr 2014, at 16:01, Wesley Eddy <> wrote:
>> On 4/16/2014 9:31 AM, Thomas Clausen wrote:
>>> FWIW, my personal belief is that "running code" should be a
>>> requirement for anything going std. track -- and that a (mandatory)
>>> period as Experimental prior to go std. track would yield the stable
>>> spec against which to reasonably build code, and run
>>> (interoperability) tests, fix bugs, etc. If after (pulling a number
>>> out my hat here) a year as Experimental there's no running code, then
>>> that's probably a good indicator, also, as to if this is something
>>> the IETF should bother doing....
>> If there's no running code, or pretty concrete plans and commitments
>> to get there, then there's really no need for an Experimental RFC that
>> will get a number and last forever.  An I-D that expires in direct
>> conjunction with the interest and energy in it is just fine.
>> Experimental RFCs are for things that we're encouraging folks to get
>> out and play with in multiple implementations,
> Isn't that *exactly* what we want to see happen before we propose things as standards?
> I think that Spencer's thesis was that it didn't happen because "implementing towards something that isn't stable and which expires" (and I-D) wasn't attractive, and the bar for std.track was too high, so "something with a lower bar, which is stable and archival, but which isn't a PS" would be helpful?
> That "something" could conveniently be Experimental.
> Experimental exists already, and the experiment targeted (at least, the RTG ADs insist on Exp RFCs carrying an explicit section describing that) would simply be "to build a few implementations and see if they interoperate". (Of course, things with "sharp edges" or "things to figure out" would have a different "The Experiment" section ... )
> The only required "process change" would be, that ADs treat "Experimental" as "Experimental" in their evaluation, and not at std. track (which they, currently, do).
>> perhaps on the real
>> Internet or under some specific conditions, but which may have sharp
>> edges or explode on impact, and need a bit more work to figure out
>> if we can seriously recommend the world to depend on them as Standards.
> Fair enough, but almost orthogonal to the point I am trying to make: going std. track without running code (it has happened, and it is happening) makes even less sense than going experimental without running code.

With DMARC as a really clear-and-present example of the dangers of not 
being more explicit about the process.

Miles Fidelman

In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra