Re: [spfbis] Call for adoption: draft-kitterman-4408bis

[Hector Santos <[e-mail]>]

Andrew Sullivan wrote:

> We would like the working group to consider adopting
> draft-kitterman-4408bis as the basis for such a specification.  As the
> charter explicitly mentions that draft as a possible basis for work,
> it is the presumptive candidate for adoption.

+1, make sense.

> If you have any objections against adoption of the draft please send
> them to the mailing list before 18 June.  Please include an outline of
> what the alternative draft will be like or an alternative draft.  If
> there is such an objection, we will wait one additional week for that
> alternative draft to materialize before taking a decision.

I don't think we need a major change.  Three items come to mind:


1) Focus is a consolidation of concepts and functionality currently 
peppered throughout of the docs.

2) Opportunity to bring positive engineering conclusion to the 
"experimental" is an ideal document that considered the total SPF 
spectrum - the reality.  References are good enough, but I thought the 
single integrated piece - SUBMITTER as part of the check_host() 
function.  This was proposed in issue #4

       http://tools.ietf.org/wg/spfbis/trac/ticket/4

which seems to me to be mysteriously CLOSED for some reason. It seems 
all presumptuous without proper realistic integrated considerations. I 
hope you can understand ISSUE #4 should be reopen for a proper 
integrated SPF implementation engineering design consideration. Look 
at it this way, you can't ignore it and in the reality, 
implementations check_host() will be more than just two inputs, so at 
the very least, a text change to point that out is necessary.

3) To avoid high potential conflicts, draft-kitterman-4408bis has to 
start by removing talk about DKIM:

    In the interval since that statement, DKIM (see [RFC4871] was
    developed and achieved wide deployment.  Both Sender ID (as the
    protocol defined in RFC 4405, RFC 4406, and RFC 4407 was named) and
    DKIM target "message content", as described in [RFC5598], while SPF
    targets the "transit-handling envelope".  The success or failure of
    the Sender ID portion of this IESG experiment should be evaluated
    relative to DKIM.

DKIM is not SPF - two different models of reputation vs deterministic 
methods, respectively. Such integration needs to be done outside the 
SPF framework and specification.

Thanks

-- 
HLS