Re: draft-kucherawy-greylisting-bcp

[Dave CROCKER <[e-mail]>]

Pete,

On 10/26/2011 6:16 PM, Pete Resnick wrote:
>> You have just defined an interoperability criterion that includes all sources
>> of software misbehavior, daemon sleep times, and anything else that can cause
>> delays.
>
> I notice you conveniently snipped my example of using a status code that caused

I clipped enough to provide context for my reply.  No other intent was present. 
  If I snipped too much, please add it back and explain its relevant.  (Your 
observational text about the snipping didn't explain the relevance.)


> trouble. But yes, timeouts are commonly put into standards track documents, and
> reasonably so. Implementation parameters do cause interoperability problems and
> many of those are observable from the net. I have no idea how you can claim
> these aren't "interoperability criteria".

The new work does not change the protocol definition, including timeouts.  It 
works in the grey area of operational choice.  Operations, not protocol. 
Operations = practice.


> Let's go back to my initial claims: If it implementation experience would cause
> changes to the instructions we give in a document to implementers, then it
> deserves to be on the standards track. If it's a "protocol, service, procedure,
> convention, or format" [2026, 3.1], it belongs in a technical specification. If

We have a very consistent tendency in the IETF to argue only one side of an 
issue and to quite literally ignore or flatly deny counter-points.  To remedy 
that, in this case:

RFC 2026, Section 5:

    "The BCP subseries of the RFC series is designed to be a way to
     standardize practices...community's best current thinking on a statement of
     principle or on what is believed to be the best way to perform some
     operations or IETF process function."

Anyone who thinks that the IETF's use of the words procedure, convention and 
practices are completely precise and completely orthogonal should please let me 
know what their repertoire of drugs is, because I really would like to see the 
world that way.  Absent the drugs, the world we are living in is rather more 
messy and ambiguous than your line of argument would suggest.

Equally, I suggest that the draft under consideration is a "way to perform" SMTP 
processing.  It does not change SMTP at all, but pertains to internal 
operational issues in HOW the protocol is used, not in WHAT is does.


> it gives implementation instructions (values for parameters, how the protocol
> ought be implemented, etc.), then it belongs in an applicability statement. Both
> TSs and ASs go on the standards track.

Now is the time for noting that the suggestion to use Applicability Statement is 
rubbish.  ASs are not used and have no practical meaning in the current IETF. 
They were a fine idea.  I wish they had succeeded.  But they didn't.

You are encouraged to demonstrate that my perception is incorrect, such as by 
citing a /pattern/ of AS assignments over the last 5 years and by describing 
their real-world utility.  To the extent that you wish to change the reality of 
their non-use, please do it through a collaborative process that gets people to 
sign up for it before risking their work with a process experiment, rather than 
by suddenly foisting it on a document not intended for the process experiment.


>>> Greylisting is far more obviously a protocol with testable interoperability
>>> than is, say, RFC 5234 or 5322.
>
> [To clarify: I am not committed to greylisting being a protocol. I'm just saying
> it looks more like a protocol than do 5234 or 5322. It is the claim that there
> is no way to test interoperability that I reject..]

5234 and 5322 define things that need direct processing by whoever receives the 
data.  There is no intermediary.  The interaction between data generation and 
data parsing/processing is exactly that, an interaction.  In addition, some of 
the data with 5322 specify actual, honest to goodness protocol behaviors. 
Reply-to directs the construction of a portion of a new email message, for example.

The effect of the proposed capability, in contrast, is entirely indirect.  It 
does not define a new format or a new protocol command or a new protocol 
response.  Rather, it uses /existing/ ones in a particular way.  As such, sorry, 
but those other specs are "more like a protocol" than this one is.


>> 5322 and other format specs explicitly entail parsing and processing (and in
>> the case of From: and Reply-to:, replying) by the remote engine. That's
>> essential interoperability.
>
> How does one "test interoperability" in the case of parsing that is going on in
> a local implementation like 5322? How is that different than greylisting? And
> for ANBF...?

You think that the inability to produce a successful parse of data does not 
demonstrate an interoperability failure?


>> In other words, formats are inherently bilateral. Greylisting is unilateral.
>
> Formats are bilateral, but only in the sense that both sides have a common
> understanding of the semantics of the parsed format.

That 'only' is pretty substantial, since its the essence of interoperation.


>  Greylisting is bilateral
> for those who actually participate: That is, if I receive 4xx status code, I
> know to wait a while and resend.

That's a requirement for processing SMTP.  The client SMTP is not required to 
know or care that greylisting is happening.  As such, the client SMTP engine is 
not "participating" in greylisting.  It is participating in SMTP.


>  Successful delivery happens if we both do our
> parts correctly. It is certainly the case that if I am a poorly implemented SMTP
> client, I will not try again and my mail will not be delivered (the point of the

That's an SMTP failure, whether greylisting is being done by the server SMTP or not.

Note the key point:  The success and failure conditions you cite apply to ANY 
SMTP interaction, independent of greylisting.  As such, they do not test 
greylisting "interoperability".


>> Again: since my view is rubbish, please define an interoperability test for it.
>
> (I don't think I am making any statement about *your* *view*. I apologize for
> this coming across as a personal attack. I used "rubbish" only to mean, "I

Well, I was the one who introduced the personal language in that last round but 
it wasn't intentional.  I am concerned with calling the substance rubbish, not 
the speaker.  (I am pretty sure that I was vetted as rubbish long enough ago and 
publicly enough to make it a waste of everyone's time to repeat it now, so it 
didn't occur to me that that might have been what you intended...)

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net