The need for smaller protocol specifications

[Dean Willis]

Erik said:
> While prptocols that don't have all of the above might be 
> useful to specify and implement as part of a better 
> understanding of the problem and solution spaces, it would 
> seem odd to call somethhing an IETF standard it is doesn't 
> fit into the puzzle of existing standards.

Aha! You prove my point. Today, (as you ilustrate above) we seem to think
that any RFC is "an IETF standard". 

By the current official process, a proposed standard is a relatively stable
work that is acknowledged to be incomplete and not expected to be widely
implemented. A draft standard is considered pretty much complete and widely
enough implemented that we know it works (two implementations of each
feature). Only a full standard is expected to be really complete. Does that
line up with the real world's perception, or with the quotation above?

I propose that the four-tracks of RFCs combined with three tiers on the
standards track (Total= seven kinds of RFCs) confuse not only the external
consumers of our work, but have confused us as well. We don't know whether
we're delivering "standards" or instructions about "how to try something at
home, kids."  Result: a Catch-22 where we can't know something works right
until we've tried it, can't try it until it's a standards-track RFC, and
can't write it up as a standards-track RFC until we know it works right.
Result: the dining philosophers have no fork and soon starve.

I think this is a problem. I know it's a pain in the behind. 

Would it be going too far to equate the seven kinds of RFC with the seven
deadly sins?

--
Dean