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

[HLS <[e-mail]>]

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 <[e-mail]>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
> [e-mail]
>



-- 
hls