Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

[Phillip Hallam-Baker <[e-mail]>]

On Thu, Aug 29, 2013 at 12:31 PM, John C Klensin <[e-mail]> wrote:

>
>
> --On Wednesday, August 28, 2013 07:21 -0700 Dave Crocker
> <[e-mail]> wrote:
>
> >> RFC 5507 primarily raises three concerns about TXT records:
> >
> > RFC 5507 is irrelevant to consideration of the SPFbis draft.
> >
> > Really.
> >
> > RFC 5507 concerns approaches to design.  However the SPFbis
> > draft is not designing a new capability.  It is documenting a
> > mechanism that has existed for quite a long time, is very
> > widely deployed, and has become an essential part of Internet
> > Mail's operational infrastructure that works to counter abuse.
> >...
>
> Dave.
>
> However, it seems to me that, for anything that is proposed to
> be a normal standards track document, the community necessarily
> ought to be able to take at least one whack at it on IETF LC.
>

+1



> That "one whack" principle suggests that one cannot say "this
> was developed and deployed elsewhere and is being published as
> Experimental" (which is what, IIR, was one thing that happened
> in the discussion of 4408) and then say "now the design quality
> of SPF is not a relevant consideration because it has been
> considered elsewhere and widely deployed".


That is something that seems to me to happen rather a lot. When I made
private comments on the CBOR draft I was told that the authors felt free to
ignore them because they were not engaged in an official IETF standards
action. Then when I complained about the Proposed Standard status I was
told that I was being rude for implying improper use of process.

My view is that if an AD is going to sponsor an individual submission as
standards track then this should be because the issue involved is of such
narrow interest that only the individual submitter and a few others are
interested in that type of proposal.


> If the IETF doesn't
> get a chance to evaluate design quality and even, if
> appropriate, to consider the tradeoffs between letting a
> possibly-odious specification be standardized and causing a fork
> between deployed-SPF and IETF-SPF, then the IETF's statements
> about what its standards mean become meaningless (at least in
> this particular type of case).
>

I think that is a fair point but I don't think it is a fair
characterization of the nature of the design objections being raised at the
time which were:

1) 'Policy is hard so we should't do it'
2) Receivers must not infringe the rights of email senders

I don't have a lot of tolerance for either objection. The first in
particular led me to tell several people that if they don't consider
themselves competent to solve a problem won't they kindly shut up and leave
it to the people who do.

But the outcome of the objections was that whether with justification or
not, it was decided that these are objections that would be fully answered
by running code. SPF was deployed and it works pretty much as the creators
expected. And one of the reasons it was a good idea to get SPF dispatched
quickly as Experimental was so that the rest of us could concentrate on
DKIM.


I think it is entirely reasonable to demand that when the IETF assists
parties trying to deploy a proposal by endorsing it as a Proposed Standard
then there should be an IETF consensus that the design is good. But that
isn't the case here. Meng and co achieved deployment of their scheme
without IETF endorsement.

So what the IETF is now being asked to do is to recognize the fact that if
you want to send email reliably on the Internet then you had better
configure your systems for SPF and/or DKIM.


-- 
Website: http://hallambaker.com/