On 16 Apr 2014, at 16:01, Wesley Eddy <wes@xxxxxxxxxxxxxxx> wrote: > On 4/16/2014 9:31 AM, Thomas Clausen wrote: >> >> FWIW, my personal belief is that "running code" should be a >> requirement for anything going std. track -- and that a (mandatory) >> period as Experimental prior to go std. track would yield the stable >> spec against which to reasonably build code, and run >> (interoperability) tests, fix bugs, etc. If after (pulling a number >> out my hat here) a year as Experimental there's no running code, then >> that's probably a good indicator, also, as to if this is something >> the IETF should bother doing.... >> > > > If there's no running code, or pretty concrete plans and commitments > to get there, then there's really no need for an Experimental RFC that > will get a number and last forever. An I-D that expires in direct > conjunction with the interest and energy in it is just fine. > > Experimental RFCs are for things that we're encouraging folks to get > out and play with in multiple implementations, Isn't that *exactly* what we want to see happen before we propose things as standards? I think that Spencer's thesis was that it didn't happen because "implementing towards something that isn't stable and which expires" (and I-D) wasn't attractive, and the bar for std.track was too high, so "something with a lower bar, which is stable and archival, but which isn't a PS" would be helpful? That "something" could conveniently be Experimental. Experimental exists already, and the experiment targeted (at least, the RTG ADs insist on Exp RFCs carrying an explicit section describing that) would simply be "to build a few implementations and see if they interoperate". (Of course, things with "sharp edges" or "things to figure out" would have a different "The Experiment" section ... ) The only required "process change" would be, that ADs treat "Experimental" as "Experimental" in their evaluation, and not at std. track (which they, currently, do). > perhaps on the real > Internet or under some specific conditions, but which may have sharp > edges or explode on impact, and need a bit more work to figure out > if we can seriously recommend the world to depend on them as Standards. Fair enough, but almost orthogonal to the point I am trying to make: going std. track without running code (it has happened, and it is happening) makes even less sense than going experimental without running code.