SPF TYPE support

[Hector Santos <[e-mail]>]

Hi,

I'm having a hard time with both sides of the argument, especially the 
supposed existence of an "interop problem" which seems to only highlight 
how to "procedurally" stump the SPF type advocates with a "error 
correction" standpoint.   What is that error by the way?

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 been convincing it was appropriately 
addressed. It all seem to be a "Shut up" approach to the problem (always 
suggest that its been discussed already). This seems to be one of the 
reasons why the issue will not go away.

My take is that the initial MARID design expectations were being met. 
This fact is a very important design consideration in all this; the 
original expectation for a TXT/SPF migration, although very slowly, 
there were some deployments administratively (publishers) and 
technically (processors). I would like to point out the lack of a 
majority does not/should not represent a lack of interest.

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

I recommend the following to be considered to basically allow 
implementators to decide:

1) Continue with the TXT/SPF migration plan, fix up this 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) not only for SPF but for 
future DNS application protocols.

Finally, which is what I have been trying to get - why hasn't the IETF 
taking this issue (unnamed type support) very serious?

This is an integration DNS issue - not just an SPF issue. If the DNS 
vendors don't address this, this, to me, would be the only logical and 
feasible reason to remove the SPF type or even bother with any new RR 
type concept.  The interop problem cited to exist within RFC 4408 is not 
convincing to me.

Overall, as an early adopter, the only reason my package doesn't have 
SPF support was purely for short term optimizations and lack of servers 
with unnamed type processing support - no mas.   If we remove SPF 
support, then we lost it forever.  I don't think we have viewed a 
possible long term solution from an integrated protocol standpoint.

--
HLS



On 8/19/2013 4:48 PM, Pete Resnick wrote:
> Speaking in my capacity as responsible AD for this WG and document, and
> the one who is going to have to judge the consensus of this Last Call
> and report to the IESG.
>
> On 8/19/13 3:08 PM, Andrew Sullivan 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.
>
> To reinforce this point: Nowhere does the charter "disallow major
> protocol changes"; words to that effect do not appear in the charter. It
> does say that features in current use cannot be removed, but it also
> says that errors can be corrected. In this case the WG concluded that
> fixing the interoperability problem fell under the auspices of
> "correction of errors". The chairs agreed, and I saw no reason to disagree.
>
>>> * The overloading of the TXT record is a hack at best, aimed at
>>> circumventing DNS management systems vendors that fail to ship
>>> support. Breaking the DNS model with specific resource records is not
>>> the way to get better application support. (besides, the major argument
>>> at the time was "it's so hard and takes ages to get a RR type", which
>>> isn't true anymore and also, the RRtype is allocated, what's the fuss? )
>
> This issue *was* considered and extensively discussed on the spfbis
> list. AFAICT, the conclusion the WG came to was *not* based on the
> argument that "it's so hard and takes ages to get an RR type". (Yes, the
> original decision to use TXT included that argument, but that was not
> the basis for the decision in the current WG.) And I don't know that
> anyone in the WG would disagree that "the use of the TXT record is a
> hack". The conclusion was that it was a hack that we are stuck with due
> to the current deployment profile. I think you will have to find
> something that the WG missed in that discussion to be convincing that a
> substantial change is needed.
>
> There is no doubt the consensus in the WG was rough on the above two
> issues, but it was, by my reading, solid.
>
>>> * The empirical data that was gathered and the conclusions from which
>>> that where published as RFC 6686 are IMNSHO flawed and rushed in that
>>> they
>>> set far too optimistic deadlines for adaptation before declaring
>>> failure.
>
> I think you're going to need substantially more explanation (and perhaps
> some data) to make a convincing case that RFC 6686 needs to be
> reconsidered, thereby affecting this last call. The above states a
> conclusion, but provides no data or explanation. I don't know how to
> evaluation this.
>
> pr
>