On 16 Apr 2014, at 18:08, Carsten Bormann <cabo(_at_)tzi(_dot_)org> wrote:
On 16 Apr 2014, at 16:19, Thomas Clausen <ietf(_at_)thomasclausen(_dot_)org>
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