Two document stages: Proposed and Full

Dave Crocker dcrocker at brandenburg.com
Tue Jun 10 15:14:58 CEST 2003


Charles,

First, many thanks for your earlier thread and the exchange with John K.
I think that you've developed an issue that is serious and poses a real
dilemma.

One thought on component-vs-system is that we might want to make that
distinction more explicitly and even formally, making it relatively easy
to do component specifications, but still difficult to do system
specifications.


With respect to your suggestion on standards classifications:

CEP> Proposed Standard: requires working group approval.  IESG comments
CEP> taken into account, but full IESG approval not needed before
CEP> publication.  Interoperability testing completed, no known
CEP> flaws that present danger to the Internet.  Component protocols
CEP> are O.K., as long as applicability (usefulness) is documented.

This is rather interesting.  Most Proposed specs, today, are not
required to demonstrate interoperability, whereas Draft is.

The question is whether the working group's reliably exert enough
quality control on their output. For all that one might express
legitimate concern about IESG push-back, there is also a legitimate
concern about some working groups that produce poor work.


CEP> Full Standard: Full IESG approval required, according to current
CEP> procedures.  Component protocols published as part of
CEP> document suites, or separately, according to IESG discretion.

What is the market motivation for anyone to pursue this classification?

Note that the world lives on Proposed Standard now.  Though we might
want to change the meaning of the term, so that it carries less import,
but we have no assurance that the market will notice or respond to that
change.

What about using existing language for Proposed, but adding the
interoperability requirement, and changing the enforcement back to "no
known bugs" rather than "no known bugs and contains full system
features".

And for Full, simply require only: 1) substantial deployment and use,
and 2) the specification accurately documents what is deployed.


d/
--
 Dave Crocker <mailto:dcrocker at brandenburg.com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>



More information about the Problem-statement mailing list