--On Wednesday, October 26, 2011 10:08 -0500 Pete Resnick
<presnick(_at_)qualcomm(_dot_)com> wrote:
...
I think Keith has it pretty spot-on. BCPs are for documents
where it makes no sense to talk about the concepts of (to
quote 2026) "protocol, service, procedure, convention, or
format", "particular methods of using a [technical
specification]", "specify particular values or ranges, of TS
parameters or subfunctions of a TS protocol that must be
implemented", "interoperability", and "implementation and/or
operational experience". If it can be deployed and you get get
incremental implementation experience, it should be on the
Standards Track; it shouldn't be a second class citizen of
being a BCP. My personal take is that BCPs should be reserved
to guidelines for operators and administrators, statements of
architectural principles, and documentation of procedures and
operations of the IETF itself.
Agree, with one qualification. I don't see BCPs as "second
class citizens" even though some of the things that have been
published as BCPs push the whole category in that direction.
But, especially since we now have only a two-step standards
track, if the effect of a document is to modify or give
supplemental instructions about a technical specification or
protocol (or any of the other phrases Pete quotes above), then
we probably owe it to ourselves and the community to use that
two-step mechanism to increase the odds that ideas are exposed
to the wider community before we finalize them.
Dave wrote:
Greylisting is not a protocol, according to any definition I
know.
It isn't. Depending on one's point of view, it is either a
clever and unanticipated way to use a particular feature/
characteristic of a protocol specification or it is a horrible
abuse of a protocol feature that was intended for another
purpose. Either way, it extends the originally-intended use of
the protocol. And, not only is interoperability testing (at
scale, not just two implementations in the lab) relevant to
determine the ways in which the technique interacts with
implementations that are not aware of it, its effects on the
network are in need of continuing and ongoing evaluation.
john