On 28 Oct 2010, at 13:29 , Dave CROCKER wrote: > On 10/28/2010 9:22 AM, RJ Atkinson wrote: >> Most times it would be better if IETF WGs initially create >> an Experimental status RFC, possibly doing so quite rapidly, >> and then later revise that (based on at experience) and >> publish the revision on the IETF standards-track. > > > 1. Getting /any/ RFC through the IETF process is very high overhead, > including Experimental.
I believe that publishing an Experimental RFC is visibly easier than publishing a standards-track RFC. > 2. Why does what you've suggested not qualify > for the IRTF rather than the IETF? As my note clearly said, in text you chose not to quote above, it is already sometimes the case that the IRTF track is used. HIP and ILNP are recent/current examples of this. I believe that most often the IETF often would benefit from publishing initially as experimental, then publishing a revised/clarified specification on the IETF standards-track. There are a range of examples where this has been done over the years, with visible success, by various IETF WGs. At the moment, the HIP WG is a good example. As another example, my understanding, possibly outdated, is that parts of the "TCP Multi-Path" work intend to go out directly on the IETF standards-track, while other parts intend to go out initially as Experimental. > Shouldn't a standards process be able to sit down and do a standard, > rather than iterate on experimental designs? The above seems to reflect a mis-reading of what I wrote. I merely suggested that often an IETF WG would find it more productive to go to Experimental RFC first, then later to the standards-track. There are a number of worked examples of this historically, going back some number of years. I provided a handful of recent or current examples. This suggestion is not in any way novel or strange. Indeed, I'm merely echoing the suggestions of other folks -- this is not an idea that I originated. Cheers, Ran _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf