RE: Running Code

["Hannes Tschofenig" <[e-mail]>]

Hi Jari, 

>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!
Nope. That's also what I thought. 

> 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-ti
>ming.html

2 years and 8 months -- super fast in comparison with other documents. 

>-- what can we do to make the process smoother?


Good that you ask (and this was not arranged). Here is the draft with
throughts from Henning, Markus and myself: 
http://www.ietf.org/internet-drafts/draft-tschofenig-rai-reducing-delays-00.
txt

>
>> 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.

Maybe this is just reflecting a bit my frustration. 

My recent example: 
http://www.ietf.org/mail-archive/web/emu/current/msg01111.html

Timeline for that document: 
http://www.arkko.com/tools/lifecycle/draft-ietf-geopriv-radius-lo-timing.htm
l

> 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.

I agree. It is certainly not black and white. 

> 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.
You are certainly correct. 

I am certainly not asking for instant publication of everything. I would,
however, like to reduce the publication delay from 5+ years down to
something more reasonable. 

Ciao
Hannes

>
>Jari
>