On Thu, Aug 29, 2013 at 12:31 PM, John C Klensin <john-ietf@xxxxxxx> wrote:
--On Wednesday, August 28, 2013 07:21 -0700 Dave Crocker
<dhc@xxxxxxxxxxxx> 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/