Document Series

[Dave Crocker]

Keith,

And lastly...


KM> 4. We need to reorganize our document series.

Again, this is something we have lots of agreement about, at this level
of statement.  But then we get bogged down in the details.

So I suggest that people pursue the topic in terms of what stages of a
document are *useful* to the community.  That is, where is community
motivation for changes in a document or a document's status?  If we can
figure that out, then we will have stages the community actually uses.

Here is my own thought on useful stages:

1.  Technical discussion and convergence -- form community consensus
2.  Technical refinement -- lock down the details
3.  Proof of concept and debugging
4.  Stability -- community operational acceptance

The first is pure mayhem, and that's good. People explore, suggest,
debate. Eventually, they should start to form group preferences and
focus on getting the details worked into a specification that provides
detail which readers can understand and see as coherent and sufficient
for achieving a specific set of useful functions. Then they test the
thing, to see whether interoperable implementations can be developed.
Then they actually use the thing, eventually achieving some sort of
critical mass of deployment.

Now, the clever reader will observe that we already have exactly these
stages. (Personal I-D, WG ID -> PS, Draft, Full.) Yet the latter 2 are
virtually unused.

The community does not care about demonstrated ability to operate or
demonstrated deployment and use?  Or is it that they merely do not need
the IETF to tell them (anymore)?

As to whether the barrier to PS is too high, I strongly suspect that the
more serious problem is that we are not getting scope correct.  We are
tending to try to deliver specifications that cover too much, and
thereby any reasonable requirement for completeness, manageability,
security, etc., becomes onerous.

Yes, there well may be a problem with requiring perfection in PS.  The
language "no known defects" can be used as a bludgeon.  But I keep
thinking that that is better fixed by divide-and-conquor than lack of
detail.

We might also want to consider whether the effort to attain Draft or
Full are too high.  Historically, we simply took folks' word that
adequate interoperability had been achieved.  These days we often
required an auditor's accounting that every single feature was tested.

We might also want to consider enforcing time-outs.  If a document is PS
and has not reached Draft after awhile, move it to historic...

Oh.  We already have that rule:

   RFC 2026
   
   6.2  Advancing in the Standards Track
   ...
   When a standards-track specification has not reached the Internet
   Standard level but has remained at the same maturity level for
   twenty-four (24) months, and every twelve (12) months thereafter
   until the status is changed, the IESG shall review the viability of
   the standardization effort responsible for that specification and the
   usefulness of the technology. Following each such review, the IESG
   shall approve termination or continuation of the development effort,

So, once again, it appears the problem is that we are not using the
tools we already have.

Why is that?  Does it really mean that somehow, different rules will
work better?  Or does it mean that we need to organize our
administration of those rules differently?


KM> Some SDOs have a numbering scheme that reflects categories,

Sounds to me like you are describing what STD numbering was intended
for.

My guess is that we do not use it because we do not maintain it. Or
perhaps there is another reason?


KM> and I think we
KM> might do well to consider such a scheme for IETF documents.  This probably
KM> means abandoning the linear RFC numbering scheme entirely, though it doesn't
KM> mean that we have to stop calling them RFCs.

No.  The linear numbering scheme ensures unique reference.  We all like
unique references.  The problem is that we also like stable references.

The idea behind the STD series was to provide both stability of
reference and aggregation of related specifications.


SD> The hurdle I see is that there actually is an "editor role" that's missing
SD> - not today's draft editors, and not today's "rfc editor", but an editor
SD> that takes the output of successful Document Actions and merging
SD> them into existing specifications, where this is applicable.

Localized versions of aggregations are the meta-specifications that are
mostly a vehicle for citing components.  Frankly I like these a lot.

But they do not operate well over multi-working group efforts.  Again,
that's what STDs were intended for.

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>