Re: draft-kucherawy-greylisting-bcp

[Pete Resnick <[e-mail]>]

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.

pr

On 10/26/11 7:12 AM, Keith Moore wrote:
> IMO, BCPs are a way for IETF to endorse desirable practices for which the 2026 advancement criteria (e.g. interoperability tests) are not applicable.
>
> On Oct 26, 2011, at 4:24 AM, Dave CROCKER wrote:
>
>    
>> Pete,
>>
>> I don't understand, either.  While it lists a /set/ of alternative or complementary best practices, it /is/ about best practices.  Please explain.
>>
>> d/
>>
>> On 10/25/2011 7:12 PM, Pete Resnick wrote:
>>      
>>> (a) This shouldn't be labeled as a BCP. It's an A/S Standards Track draft if
>>> ever there was one.
>>> (b) Given this and the extension, is it worth spinning up a Greylisting WG?
>>>
>>> pr
>>>
>>> On 10/23/11 3:40 PM, Murray S. Kucherawy wrote:
>>>        
>>>> Maybe a new thread Subject: would help here...
>>>>
>>>> Given the interest, I've started putting together a BCP. It's now posted as
>>>> draft-kucherawy-greylisting-bcp; comments welcome (and thanks to those of you
>>>> that already did). It is only an outline right now, and I'll fill it in as
>>>> people make suggestions about topics it should cover and/or start providing
>>>> text to include.
>>>>
>>>> It doesn't touch the SMTP extension people are discussing. Someone else can
>>>> champion that one if so inclined. That shouldn't go in a BCP because it
>>>> doesn't even exist yet. This document will only describe current and historic
>>>> practices.
>>>>
>>>> Maybe we can get it on the docket for Taipei. I'll send out some friendly pings.
>>>>
>>>> -MSK
>>>>          

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: [phone], Fax: [phone]