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
- Re: Running Code Scott Lawrence
- RE: Running Code Hallam-Baker, Phillip
- Running Code Marc Petit-Huguenin
- Re: Running Code Brian E Carpenter
- Re: Running Code Peter Saint-Andre
- Re: Running Code Marc Petit-Huguenin
- Re: Running Code Harald Alvestrand
- Re: Running Code Marc Petit-Huguenin
- Re: Running Code Henning Schulzrinne
- Re: Running Code Masataka Ohta
- Re: Running Code Gary E. Miller
- Re: Running Code Andy Bierman
- Re: Running Code ned+ietf
- Re: Running Code Masataka Ohta
- Re: Running Code Marc Petit-Huguenin
- Re: Running Code Marc Petit-Huguenin
- RE: Running Code Hannes Tschofenig
- Re: Running Code Alessandro Vesely
- Re: Running Code Lars Eggert
- Re: Running Code Jari Arkko
- Re: Running Code Andrew Sullivan
- Re: Running Code ned+ietf
- Re: Running Code Peter Saint-Andre
- RE: Running Code Hannes Tschofenig
- Re: Running Code Andy Bierman
- Re: Running Code Marc Petit-Huguenin
- Re: Running Code Marc Petit-Huguenin
- Re: Running Code Marc Petit-Huguenin
- Re: Running Code Henry Sinnreich
- Re: Running Code Henning Schulzrinne
- Re: Running Code Melinda Shore
- Re: Running Code Marc Petit-Huguenin
- Re: Running Code Melinda Shore
- RE: Running Code Hannes Tschofenig
- Re: Running Code ned+ietf
- Re: Running Code ned+ietf
- Early implementers motivations [was Re: Running C… Marc Petit-Huguenin
- Re: Running Code Pete Resnick
- Re: Running Code Henning Schulzrinne
- Re: Early implementers motivations [was Re: Runni… Doug Ewell
- Re: Early implementers motivations [was Re: Runni… ned+ietf
- Re: Running Code Marc Petit-Huguenin
- Re: Running Code Marc Petit-Huguenin
- Re: Running Code Doug Ewell
- Re: Running Code Cullen Jennings
- Re: Running Code ned+ietf
- Re: Running Code Marc Petit-Huguenin
- Re: Running Code Marc Petit-Huguenin
- Re: Running Code ned+ietf
- Re: Running Code Marc Petit-Huguenin
- Re: Early implementers motivations [was Re: Runni… Alexandru Petrescu
- Re: Running Code Philip Matthews