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 >