On Wed, May 1, 2013 at 9:33 AM, Michael Richardson <mcr+i...@sandelman.ca>wrote:
> <#part sign=pgpmime> > > >>>>> "Jari" == Jari Arkko <jari.ar...@piuha.net> writes: > Jari> I wrote a blog article about how we do a fairly significant > Jari> amount of reviews and changes in the late stages of the IETF > Jari> process. Next week the IESG will be having a retreat in > Jari> Dublin, Ireland. As we brought this topic to our agenda, Pete > Jari> and I wanted to raise the issue here and call for feedback & > Jari> ideas for improving the situation with all of you. > > Jari> http://www.ietf.org/blog/2013/05/balancing-the-process/ > > I'll repeat what has been said repeatedly in the newtrk and related > discussions. The step from ID to "RFC" is too large because we are > essentially always aiming for "STD" rather than "PS". > > I don't think this helps. We want the highest quality documents possible for developers to translate into implementations. IMO, the answer is to identify cross-area issues early, and more importantly, get early cross-area reviewers to help avoid bad decisions that won't make it through IESG review. Maybe a cross-area expert needs to join a design team for awhile to make sure good decisions are made. The ADs need to make sure these early reviews get staffed and completed. Maybe additional people (directorate?) helps manage this process. Andy If we are unwilling to bring "RFC" back to a place were it does not > equal STD, then we need to create a new category of document which > amounts to "fully baked ID". Things like IANA allocations could occur > at that point. > > > In the days of dot-boom it was not unusual to see widespread > implementation very early in the ID process and even interop and > experimental deployment. While this still occurs for quite a number of > things (and sometimes it's a problem that the ID can not be changed as a > result), there is an equal amount of "wait for the RFC to come out". > > > I believe that we probably need to simply do less. > Or perhaps we've reached the n^2 overhead problem, and since resources > are less(%), if we can't increase resources allocated to overhead, then > it's time to reduce n: the IETF should fork and/or shard somehow. > > > (%)-it's not just about $$ invested, it's also, I think, that after > many years of caffeine and sugar, many of us are simply > immune to their effects, and/or have given them up. > > > (2)-by adding an intermediate step in the "ID" process, I haven't > removed the "heavy" part of the process, I've just redefined the > process so that it's no longer at the "tail" of the process. > This is, I admit, akin to adjusting the definition of unemployment. > > But, we can all agree when an ID is baked enough for the WG to > consider it deployable, then we will actually get to the "running > code" part sooner, which frankly is the only real way to get > real experience. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | network > architect [ > ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails > [ > > > >
