Re: draft-kucherawy-greylisting-bcp

[Dave CROCKER <[e-mail]>]

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