ietf
[Top] [All Lists]

SPF TYPE support

2013-08-19 16:15:07
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


<Prev in Thread] Current Thread [Next in Thread>