Re: draft-kucherawy-greylisting-bcp

[Pete Resnick <[e-mail]>]

On 10/26/11 11:37 PM, Murray S. Kucherawy wrote:

>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Pete Resnick
>> Sent: Wednesday, October 26, 2011 8:08 AM
>> To: Keith Moore
>> Cc: [e-mail]; [e-mail]
>> 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: [phone], Fax: [phone]