Document Series

[Keith Moore]

> 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.

Well, to the extent I was suggesting details, I intended them merely
as examples, not as concrete suggestions.  I don't pretend to have 
worked out enough details to make a credible proposal, and I think that
is the job of the follow-on group rather than the problem statement group.

> So I suggest that people pursue the topic in terms of what stages of a
> document are *useful* to the community. 

I'm thinking that we need to understand what stages of a document will be used
by implementors.  i.e. at what point of apparent stability, maturity, and
buy-in will implementors start prototyping?  At what point will they start
interop testing?  At what point will they start shipping product?  

Once we understand implementors' needs and expectations, we will be in a
better position to decide what the criteria for acceptance of those stages
should be.  Of course we also have to reconcile that understanding
with WG energies and expectations, and with the engineering roadmap.

> 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.

I strongly disagree.  If anything, I'm convinced that we are not covering
enough bases - we are producing too many protocols that work at cross-purposes
with our other efforts.

> 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.

I have serious doubts about that.

> 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.

I've never seen an "auditor's accounting" required; only a simple list.

When protocols have large feature sets it really does seem worth examining
which features are implementable and which ones are used.  I'm not sure how
much good it does to try to test the interoperability of each feature
individually, though - I suspect that this about as useful as doing
conformance testing.  So yes, I think our testing criteria are worth
looking at.

But I don't think it's terribly helpful to think in terms of tweaking
the existing PS, DS, and FS levels.  I think we need to start with a
clean white board and figure out what levels we really need, because
currently only one of these levels seems very useful, and there are
arguments that even PS has a poor impedance match with what implementors need
and expect.

> KM> Some SDOs have a numbering scheme that reflects categories,
> 
> Sounds to me like you are describing what STD numbering was intended
> for.

Not really.  STD is just another kind of document serial number, except that
if you revise a document it can keep the old serial number.   But it doesn't
serve as any kind of classification scheme; it doesn't help you group related
documents together.
 
> My guess is that we do not use it because we do not maintain it. Or
> perhaps there is another reason?

My guess is that STD is not used because STD numbers are only assigned at
FS.  Of course, that hardly ever happens, and the practice of citing
RFC numbers is too well-entrenched to be displaced by a practice of citing
STD numbers that are rarely assigned.

We can't solve this problem by merely creating a new numbering scheme
alongside RFC numbers.  We either need to abandon the "RFC" name entirely
or we need to start numbering them differently.

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

There are other ways to get unique references.  e.g. Dates work well. 

But again, this isn't the place to try to work out the details - I cited these
merely as examples of things we need to look at.

Keith