--On Wednesday, 27 April, 2005 08:41 -0700 Dave Crocker
<dhc2(_at_)dcrocker(_dot_)net> wrote:
Proposals for upgrading/streamlining standards track in
discussion (i.e. newtrk and specifically the ISD proposal,
but there's certainly more to do in newtrk)
Another derailed activity. Another activity that has nothing
to do with quality, timeliness or relevance.
Go ahead, explain how it does.
Dave,
Here we disagree, or I most assuredly would not be spending time
on it. I believe that, properly implemented and used, the ISD
work could result in much faster track processes for corrections
and minor alterations to standards-track materials. By avoiding
the need to create new RFCs and perhaps lowering the frequency
with which we need to spin up WGs to deal with issues on which
consensus is already fairly clear, we should be able to improve
quality and timeliness and, in the process, free up cycles to
invest in quality and timeliness in other areas.
Explain how current document labeling practises hurt the
IETF's utility to the Internet community.
I am far less convinced of it than the above, but I suggest that
"labeling practices" that we don't use as documented create
confusion about the appropriate time and circumstances under
which a standard should be implemented, how mature the
specification actually is, and so on. We've encountered a few
situations in which organizations have refused to implement
standards, or argued for substituting their own specifications,
because our "standards" are only "Proposed". It is a matter of
debate, of course, how frequent those situations actually are
and how often, when that claim is made, the organization
involved would just hunt for a different excuse when that one
was not available. But I suggest that cleaning things up --as
long as the marginal cost is low-- would eliminate a source of
reduced utility.
I consider the timeliness and quality issues above, and the one
discussed below, to be far stronger justifications for the ISD
idea and spending time on it.
Explain how the utility of the IETF to the community will be
improved by our fixing this.
We are in a situation today in which many of our specifications
are not really self-contained. Some might even suggest that few
are. This has created a procurement nightmare in which
organizations who would like to procure and specify products
against IETF standards have few ways to figure out what to
specify. That results in either their using third-party guides
(which we might or might not view as correct), guessing (and
some spectacularly silly errors have been made as a result), or
looking to other bodies whose specifications are more
comprehensible. In theory, we could solve that problem with
comprehensive Applicability Statements, but, in practice, those
have turned out to be too heavyweight an effort and almost
impossible to get produced. The hope is that, by use of prose,
cross-references, unification of related specifications under a
single umbrella document, and so on, the ISDs will provide us a
tool to improve on this situation and will actually do so. And
that would, indeed, significantly improve utility.
Now, whether or not the ISD idea will actually accomplish
anything is very much an open question. A great deal depends
on whether the IESG (particularly) and the community generally
get behind it. The idea can easily be starved to death in all
sorts of major and minor ways. But the people who have
advocated it and been working on it have been motivated
precisely by issues of timeliness, quality, and
comprehensibility of our work and, at least on many days, remain
optimistic about its actually solving real and critical-path
problems.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf