Re: "why I quit writing internet standards"

Ted Lemon <> Mon, 14 April 2014 16:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5992B1A0667 for <>; Mon, 14 Apr 2014 09:20:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.528
X-Spam-Status: No, score=0.528 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dPIPndD5JAee for <>; Mon, 14 Apr 2014 09:20:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 97B5E1A065F for <>; Mon, 14 Apr 2014 09:19:36 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by (Postfix) with ESMTP id 58AA01B805A for <>; Mon, 14 Apr 2014 09:19:34 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by (Postfix) with ESMTP id 3A5C819005C; Mon, 14 Apr 2014 09:19:34 -0700 (PDT)
Received: from [] ( by CAS-01.WIN.NOMINUM.COM ( with Microsoft SMTP Server (TLS) id; Mon, 14 Apr 2014 09:19:33 -0700
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
Subject: Re: "why I quit writing internet standards"
From: Ted Lemon <>
In-Reply-To: <>
Date: Mon, 14 Apr 2014 11:19:32 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <>
References: <> <> <>
To: Miles Fidelman <>
X-Mailer: Apple Mail (2.1874)
X-Originating-IP: []
Cc: "" <>
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: Mon, 14 Apr 2014 16:20:05 -0000

The IETF, when it is functioning well, does a good job of documenting, debugging and refining work that is brought to us.   When we innovate, it's usually some team of individuals who has the innovative idea, and then they decide they want to do it in the context of the IETF.   There's nothing wrong with doing this, but there is a cost to doing it.   We can certainly work to minimize the cost that we impose, but I don't think we ought to change the basic mechanism whereby we do standards in order to optimize this use case: in doing so we would be letting go of what we do well.

An open source project that gets a prototype working well may or may not actually have something.   To the extent that they have made an incremental change to an existing standard, or layered what they have done on top of existing standards, there may well be little left to do.   Then the IETF process may feel like a straitjacket.

On the other hand, consider a project like Diaspora (in the abstract, please—I am not suggesting the IETF take it on).   Diaspora was invented by people who didn't entirely know what they were doing, and exists essentially as an implementation, not as a standard.   When I've looked at hacking on it, I've thrown my hands up in disgust because there's no documentation at the level that would allow me to do an independent implementation.   I think the security is also half-baked, and could have benefited from some IETF process.

Projects _like_ this can definitely benefit from IETF process.   Up to a point, you are innovating and learning, and probably the most heavyweight IETF-like process you can afford is to publish work in progress through the ISE, or as individual submissions.   But at some point you have something that you think is a result, and then it's time to write an interoperable implementation and get some peer review to shake out issues.   This is when the IETF can help, and when the IETF should help.

So I don't mean to say there's no problem here to solve, but I think the basic idea that because open source is innovating without us, we need to fundamentally change what we do, is mistaken.

To put it more positively, I think that IETF is an enabling technology for open source, and that there is a strong positive feedback loop between a successful open source project and a successful, related IETF process.   And this is true even in cases where some participants are doing closed-source projects.

So I think the things Wes outlined as weaknesses in the IETF are quite correct, and we should work on them, but let's not throw the baby out with the bathwater.