ietf
[Top] [All Lists]

Re: "why I quit writing internet standards"

2014-04-16 11:32:27

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