Re: Running Code

Jari Arkko <jari.arkko@piuha.net> Wed, 04 March 2009 12:23 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03E243A677D for <ietf@core3.amsl.com>; Wed, 4 Mar 2009 04:23:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tbl2vkwFDEwI for <ietf@core3.amsl.com>; Wed, 4 Mar 2009 04:23:10 -0800 (PST)
Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 61C803A6AFB for <ietf@ietf.org>; Wed, 4 Mar 2009 04:22:54 -0800 (PST)
Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 474ED198702; Wed, 4 Mar 2009 14:23:21 +0200 (EET)
Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id E71DE198671; Wed, 4 Mar 2009 14:23:20 +0200 (EET)
Message-ID: <49AE72AC.5020409@piuha.net>
Date: Wed, 04 Mar 2009 13:23:08 +0100
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Subject: Re: Running Code
References: <49AD9E53.3040003@acm.org> <49ADC04A.10707@alvestrand.no><49ADD715.3060905@acm.org> <E8F9B711-B672-45CB-B013-85822A1B3BA6@cs.columbia.edu> <020101c99c9e$40789560$2fb4b70a@nsnintra.net>
In-Reply-To: <020101c99c9e$40789560$2fb4b70a@nsnintra.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Mar 2009 12:23:12 -0000

Hannes,

> The work was done in a design team, it took a very long time (the first
> design team draft dates back to May 2006). 
>
> Jouni Malinen implemented the protocol in 8 hours!

Not a good spec time / implementation time ratio! There are also 
examples of people starting and *finishing* their PhD on the topic of an 
RFC *before* the RFC comes out. Not a good sign of the effort required 
to publish an RFC...

Picture about the process for this particular draft can be found in 
http://www.arkko.com/tools/lifecycle/draft-ietf-emu-eap-gpsk-timing.html 
-- what can we do to make the process smoother?

> There are three main problems: 
>
> * Almost random changes to the specification make early implementation work
> almost useless (if your goal is to produce code that aims having code for a
> specific RFC after all). Since it takes so long to finish the
> standardization work it is often not possible to wait till the RFC comes
> out. 
>
> * Nobody cares if you have running code. Requests to substantially change
> the specification often come at a late stage. Even IESG members have already
> re-written specifications during IETF Last Call. As a joke, I suggested to
> just submit the table of contents to the IESG and then start the work there.
>
> * Finally, because it takes so long to finish specifications the 3-level
> Standards Track process is rarely utilized anymore. That process considers
> interoperable code but what does it help? 
>   
These are issues. And my opinion is that we have to take implementation 
experience very seriously. I would like to disagree with you on the 
assertion "nobody cares if you have running code", however. I think all 
of us care. But running code does not necessarily override ALL other 
concerns. If there's a serious bug in the spec, it needs to be fixed, 
even if it is noticed late in the process. Personally, I find that we 
waste most of the time waiting (for reviews, for the author to revise a 
spec, for the AD to respond, etc). If we reduce that we can get the 
process much faster.

The entire value of the IETF specification effort is that you get 
comments and as a result the specification improves. That necessarily 
implies that there may be changes from your initial implementation. If 
the  goal is absolute minimum publication time and no changes to 
implementation, we should all just be publishing protocol specifications 
on our web pages or talking to the RFC Editor -- and this is what we do 
in many cases, but it is not the right approach for producing a standard.

Jari