Re: draft-kucherawy-greylisting-bcp
2011-10-27 23:46:02
On 10/26/11 11:37 PM, Murray S. Kucherawy wrote:
-----Original Message-----
From: owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Pete Resnick
Sent: Wednesday, October 26, 2011 8:08 AM
To: Keith Moore
Cc: dcrocker(_at_)bbiw(_dot_)net; ietf-smtp(_at_)imc(_dot_)org
Subject: Re: draft-kucherawy-greylisting-bcp
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".
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. 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.
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.
That sounds right, but some of it seems (to me) to conflict with the citations
you made. I suspect there's some (pardon the allusion) grey area in there that
makes it hard, for me at least, to see clearly when something should be a BCP
and something should be an AS.
The only grey area would be the guidelines for operators. But when I say
guidelines for operators, I'm thinking of things like the amount of
available disk space required to run a typical SMTP server getting 10's
of messages per second or the recommendation to get an SMTP server with
a robust logging facility because of the need to check error reports,
things that really aren't part of the implementation of the protocol,
but are local conventions for the use of implementations. Those usually
belong in BCPs, though sometimes we see such statements in standards
track documents too.
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). We make these statements all of the time as part of
standards track documents, and the act of separating them into a
standalone document apart from the technical specification doesn't mean
they don't belong on the standards track. BCPs should only be used when
putting something on the standards track makes no sense.
pr
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: 4yz Temporary Rejections is part of the SMTP Protocol, (continued)
- Re: draft-kucherawy-greylisting-bcp, Steve Atkins
- Re: draft-kucherawy-greylisting-bcp, Tim Kehres
- RE: draft-kucherawy-greylisting-bcp, Murray S. Kucherawy
- Re: draft-kucherawy-greylisting-bcp, Dave CROCKER
- Re: draft-kucherawy-greylisting-bcp, John C Klensin
- RE: draft-kucherawy-greylisting-bcp, Murray S. Kucherawy
- Re: draft-kucherawy-greylisting-bcp,
Pete Resnick <=
- Re: draft-kucherawy-greylisting-bcp, Dave CROCKER
- Re: draft-kucherawy-greylisting-bcp, Pete Resnick
|
|
|