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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf