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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I'm having a hard time with both sides of the argument, especially the supposed existence of a "interop problem" which seems to only to be highlighted to "procedurally" stump the SPF type advocates.  I don't believe there was an adequate answer from the advocates of removing the SPF RR type and the repeated assertion that its been discussed at length has not resolved the issue because it really hasn't been appropriately address.  Its not convincing. This is the reason the issue will not go away.  

My take is that the the initial MARID design expectations where being met and to me, that is a very important design consideration in all this; what were the original expectations with a TXT/SPF migration. Although very slowly, there were some deployments administratively and technically. 

In my estimation, the WG did receive positive support that there was sincere interest in adding support for the SPF record type primarily because there was some level of adoption discovered during the "interop" report work.  You can include us (SSI) as having interest in enabling/adding SPF record support.   

I  recommend the following to basically allow IMPLEMENTATORS to decide:

1) Continue with the TXT/SPF migration plan,

2) Address any technical protocol issue with using an SPF type,

3) Add implementation designs notes on the pros and cons. 

This will allow coders to add the optimized logic for usage.  It will also allow for new problem solving seeds to be laid down. It will hopefully get the DNS software vendors to finally add direct support for unnamed TYPE support (query and passthru).

Finally, which is what I have been trying to get - why hasn't the IETF taking this issue (unnamed type support) very serious? The reason I wonder because if the DNS vendors don't address this, then to me, that should be the only reason to remove the SPF type or even bother with any new RR type concept.  The interop problem cited about RFC 4408 is not convincing to me. The only reason my package as an early adopter didn't have SPF support was purely for short term optimizations and lack of servers with unnamed type processing  support reasons - no mas.

--
HLS



On Mon, Aug 19, 2013 at 4:08 PM, Andrew Sullivan <ajs@xxxxxxxxxxxxxxxxxx> wrote:
Note that I am not the shepherd for this draft, but I am the WG
co-chair.

On Mon, Aug 19, 2013 at 05:05:21PM +0200, Måns Nilsson wrote:

> * The charter disallows major protocol changes -- removing the SPF RR type
> is a direct charter violation; since SPF is being used on the Internet.

That argument doesn't work, because the WG had to make a major
protocol change in this area no matter what, since 4408 has an
interoperability problem.  If you wish to argue that the WG decided on
the wrong protocol change, that line is open to you; but nobody can
argue that the change is wrong because of our charter.

Best regards,

A

--
Andrew Sullivan
ajs@xxxxxxxxxxxxxxxxxx



--
hls

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]