Re: "why I quit writing internet standards"

Jari Arkko <> Tue, 15 April 2014 18:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 90C1A1A03D7 for <>; Tue, 15 Apr 2014 11:10:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.528
X-Spam-Level: **
X-Spam-Status: No, score=2.528 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_MUTUALBENEFIT=2, RP_MATCHES_RCVD=-0.272] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9-t2W0bRK0qy for <>; Tue, 15 Apr 2014 11:10:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EC2491A04F1 for <>; Tue, 15 Apr 2014 11:10:43 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D18482CC95 for <>; Tue, 15 Apr 2014 21:10:39 +0300 (EEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3m7_3nLJeq8b for <>; Tue, 15 Apr 2014 21:10:39 +0300 (EEST)
Received: from [] ( [IPv6:2a00:1d50:2::130]) by (Postfix) with ESMTP id 0ADF52CC48 for <>; Tue, 15 Apr 2014 21:10:39 +0300 (EEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: "why I quit writing internet standards"
From: Jari Arkko <>
In-Reply-To: <>
Date: Tue, 15 Apr 2014 21:10:38 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: " List" <>
X-Mailer: Apple Mail (2.1510)
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: Tue, 15 Apr 2014 18:10:48 -0000

Vidya brings up some interesting points, some of it IETF-related but also some that relates how the world is evolving. For instance, the open source trend. 

But to pick another trend, so many things can now be built without any permission from anyone - including SDOs. We call this permissionless innovation, and it is a good thing. The Internet has grown, and it is not our task at the IETF to do everything, we should, however, care about evolving the core protocols.

One of Vidya's examples was the Internet of Things, and she wondered how little standards work is needed. But that is not an accident, it is by design. From my perspective what happened was that link layer technology developed to make the physical level connectivity possible and existing Internet protocols were sufficient to do 98% of what was needed. As an example, I see most of Internet of Things gadgets running on the web protocol stack. Because it just works, it is widely available, goes through every firewall, and so on. These are good things. As a consequence, places like IETF or IEEE are not developing thousands of applications for the Internet of Things, the vendors are. The union of the meter manufacturers are. And so on. There is still some core standards development necessary - as witnessed at the IETF in the form of mesh routing protocol work, various IPv6 over Foo working groups, the 6LO* working groups, the lightweight web/security protocol working groups, and so on. Fundamental and necessary efforts, but in numbers 1000x less than efforts higher up.

The IETF has its place, but it is more about being useful to the open source efforts, the permissionless innovators, and the like than trying to compete with them. How can we do this best? One avenue is working on tools that the permissionless innovation, SDN, virtualisation, IOT, and web development revolutions need underneath. We have active developments at the IETF on all of those fronts, and I suspect more is coming.

There are certainly also IETF process/organisation things that we should work on to improve. We do. Here are some things that I would like to see:

  o  Are there ways to work to mutual benefit with open source efforts (those that would benefit from an IETF-like environment)?

  o  Recognising that many successful cases of Internet technology development have been about some people somewhere making something that later required standards at which point the IETF took over. Learning to do this, and learning to do it well is important.

  o  How can we better build specs to (rough) consensus, including making sure that (an understood) vocal minority opinion does not block progress?

  o  More focus on running code.

(All my personal opinions, of course.)