Hi.
As mentioned in the analysis of
draft-housley-two-maturity-levels I posted yesterday, I've made
a pass through the old (NEWTRK-vintage) ISD specification. A
new version is in the posting queue as draft-klensin-isdbis-00.
While the flavor and much of the text of the old version is
still present, it has been significantly revised to address both
some of the issues raised in the last few weeks and the concerns
about workload raised by the IESG of five years ago.
In particular:
* The "providing information about a document" (the
maturity level issue) and the "grouping documents" (the
STD issue) are given equal weight.
* A lighter-weight transition plan is incorporated.
* ISD numbers (to be assigned to anything reaching the
standards-track) and ISD documents are separated (we may
want to change the name if this goes anywhere). The
latter are required only for specifications for which
information that supplements the RFC is, or should be,
required anyway, e.g., interoperability reports,
descriptions of relationships to older versions,
descriptions of relationships of multiple documents that
make up a single standard.
* The minimum information required in an ISD document
(if one is required at all) is capable of being
automatically generated.
As the last NEWTRK ISD document and discussions indicated, it is
always possible to dispose of a proposal like this by
nit-picking at the details and ignoring the larger picture or by
complaining that insufficient details have been provided. I've
tried to strike a better balance in this version than the
earlier one had, but I can only hope that people will try to
understand the principles and that, while I've proposed a
combination of details that I believe will work, details can
always be tuned.
It is long (largely as a result of including enough detail to be
taken seriously), but, if one believes that the problems with
the system run a little deeper than the descriptions in
draft-housley-two-maturity-levels and that they deserve a more
comprehensive approach rather than slapping on patches of
terminology and levesl, it may be worth having a look.
regards,
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf