Just to echo in some form what others have said, I believe that an
intermediate stage between I-D and RFC is needed.
I don't have a name for it, but conceptually would be something like
'feature freeze', e.g. no more tweakings to the protocol, or base spec
are to be introduced (unless a major showstopper is discovered), and
just nits and maybe IANA considerations are left to add / discuss.
This would help by sending a clear signal to developers when it's
reasonable to start implementing a given I-D.
A couple of days ago I was part of an email exchange in WEIRDS where
something along this lines happened, when someone proposed an addition
to a base spec that, at least myself, considered already 'frozen'.
The confusion is understandable. Someone entering a WG at a later stage
during the development of an I-D has no way of knowing if the base spec
/ protocol has been agreed and considered stable by the rest of the
participants.
Yes, sure, he/she could comb the ML archives, but I don't think that's
either productive nor even viable in every case, since this 'freezing'
is (in my experience) more like a 'shared feeling' in the ML and not
(usually) explicitly signaled.
IMO, this could also help reducing the length of the overall process and
I would think such a signal would lead to more 'running code' earlier in
the process.
cheers!
~Carlos
On 5/1/13 12:33 PM, Jari Arkko wrote:
I wrote a blog article about how we do a fairly significant amount of reviews
and changes in the late stages of the IETF process. Next week the IESG will
be having a retreat in Dublin, Ireland. As we brought this topic to our
agenda, Pete and I wanted to raise the issue here and call for feedback &
ideas for improving the situation with all of you.
http://www.ietf.org/blog/2013/05/balancing-the-process/
Jari