On 16 Apr 2014, at 18:08, Carsten Bormann <cabo@xxxxxxx> wrote: > On 16 Apr 2014, at 16:19, Thomas Clausen <ietf@xxxxxxxxxxxxxxxxx> wrote: > >> That "something" could conveniently be Experimental. > > Experimental means something different in the IETF, as in: > > “This is a finished specification, but we are really not sure this will work until we have run an experiment. > Don’t base any plans on the assumption that this experiment will succeed.” I'd submit that that would be true for /any/ specification that has not been implemented and experimented with. So I think that it exactly means what I say ;) > Implementation draft means: > > “This is still subject to change, but we promise to be frugal in the changes we make from here on. > We are pretty sure this will work, no major experiments required, just implementation experience to maybe tweak it some more. > This will be done soon, so go ahead and build the products.” > > Conflating these two almost diametrally opposed sets of features into a single class of document increases confusion. <sarcasm> Oh, oh, oh, I have an idea. This "implementation draft" that you talk about, we could call that "Proposed Standard" then, because that is what we really "propose (after some implementation experience) becomes a standard". And when the implementation experiences and tweaks have been done, we will then publish a "Draft Standard" based on it -- and later, once we're absolutely sure, we'll promote it as an "Internet Standard". I think that I remember a process like this, from somewhere, where might that have been .... ;) </sarcasm> Being serious for a moment....the IESG/IETF/IAB/someone recently decided that we needed to reduce the std. track from 3 to 2 levels. This is proposing adding the third level back, perhaps perceived "below" Proposed Standard ... In your definitions above, "Experimental" and "Implementation Draft" both are ways of saying "Look, this is not mature enough to be a standard yet, but we're at a breaking point where we think we have something stable, that we want to get coded up, and played with". Either we're ready to "propose a standard" and we hit std. track -- or, we're not, and need to build up some more implementation and experimental basis, in which case Experimental is the way to go. I much prefer using that which the RTG ADs have imposed on the RTG Area, which is for Experimental protocols to have a section discussing the experiment. It gives the flexibility to say exactly what the document is, and why it is written -- without re-introducing a 3rd level on the std. track. Having an "implementation draft" status that is declared by a WG alone (or by WG chairs, or perhaps the responsible AD) isn't terribly helpful in terms of overall document quality: it excludes the (often extremely valuable) cross-area reviews that occur as part of the IESG processing -- and which almost never occurs before IESG processing -- and which, occasionally, causes design decisions to be revisited profoundly..... Sure, we can come up with a special status and process for "Implementation Draft" which captures cross-area reviews, etc -- but that'd look a lot like the process for Experimental, and would involve many of the same people. As I always say: "if it walks like a duck, and it quacks like a duck -- then, it probably tastes good served in orange sauce" > Yes, we need to find a way for implementation drafts to get IANA numbers. > (The IANA numbers problem is bigger, e.g., downrefs from finished specs should also be in a position to get numbers immediately even if not all i’s are crossed and t’s are dotted in the downref spec.) That, to me, seems to be a much simpler problem to manage ;) Thomas > Grüße, Carsten >