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 > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf