Pete,
On 10/28/2011 6:28 AM, Pete Resnick wrote:
> Herein lies my confusion. What is a Best Current Practices document if not one
that talks about conventions, particular methods of using the thing a
specification defines, [improved] interoperability, or relating of operational
experience?
I say it just below: A BCP document gives guidelines to operators and
administrators, gives statements of architectural principle, or documents
procedures and operations of the IETF itself. BCPs ought not have conventions
and particular methods of using a technical specification, etc.
> If a document is
defines conventions and particular methods of using a technical specification,
then there can be implementations of the document, and therefore incremental
experience with it, and it therefore should be on the standards track.
> If a
document defines ways of being interoperable with a technical specification,
then there can be implementations of the document, and therefore incremental
experience with it, and it therefore should be on the standards track.
You think BCP 23, 24, 28, 34, ... involve no software and do not change the
behavior of protocol engines?
By your personal definitions, these seem to have been mis-assigned and ought to
be required to be standards track.
> All of
these kinds of statements (and the additional ones I cite above) are
applicability statements, and those statements can be implemented, and we can
get incremental experience with those statements, and therefore documents with
those statements belong on the standards track.
There is a core problem: you appear to be using your personal terminology and
definitions, rather than reflecting community practice. In all likelihood, your
terms and definitions are more reasonable, consistent and practical than the
community's, but that's irrelevant.
What is relevant is established practice. It's fine to seek a change in
established practice, but not as a sole voice in a management position, invoking
personal and distinct language and requirements. That's not supposed to be the
way things work around here.
My query about applicability statements was not about documents that effectively
serve that role but about documents that are formally assigned that status AND
are effective. Established practice, not personal assessment.
The distinction I want to make is: If you're giving implementation
specifications or guidance for the protocol, those belongs as part of a
standards track document, whether they are statements in the protocol document
itself or statements in a standalone document (which I've been calling an AS).
Please get the consensus of the community about this. Please then re-label the
documents that have been misassigned.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net