Re: A note about draft-ietf-spfbis-4408bis

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

 



Andrew (and Pete, since he raised a similar issue),

On 05/02/2013 12:50 PM, Andrew Sullivan wrote:
Doug,

No hat.

On Thu, May 02, 2013 at 12:22:03PM -0700, Doug Barton wrote:
Given that you can be 100% confident that the issue will be raised
during IETF LC, wouldn't it be better to hash it out in the WG (as
we have attempted to do)? Or is the WG's position, "we have no
intention of dealing with this unless we're forced to?"

We _have_ hashed this out in the WG.  As I have noted to you -- now on
three separate lists -- the problem is that we have an actual
interoperability bug in RFC 4408, and we need to fix it.  The WG
evaluated the various alternatives for how to solve that, and having
performed the evaluation the group came to the conclusion that, _in
this specific case_, deprecating RRTYPE 99 is the most reasonable
course of action.

I understand the conclusion the WG has come to, and I have a pretty good understanding as to why. At Pete's request I reviewed the threads related to this issue in the spfbis archive. I also understand that the WG (which you co-chaired, although I will accept your "no hat" statement above at face value) desperately wants this issue to go away.

The problem is that the WG came to a very bad conclusion. A conclusion that is not only bad for SPF, it's bad for the future of innovation in the DNS, contrary to 5507, and arguably contrary to the group's own charter.

I am not saying that the WG members (or chairs) should be given the wet-noodle treatment over having reached a bad decision, but what is cross-area review for if not to catch cases where the WG echo chamber/tunnel vision/what have you -- resulted in a bad outcome?

It would be different if the right solution were hard, or if I were the only one objecting. But neither is true.

I am not happy about this, but other analyses do not seem to be
supported by any facts,

I'm not sure what facts you're looking for beyond what I've already provided. But in no particular order:

1. "Deprecate SPF/99" is in violation of 5507
2. Numerous people smarter than I have pointed out detailed technical reasons why overloading TXT generally, and particularly at the zone apex, is a horrible idea.

Furthermore, 2 of us presented detailed analyses of the arguments raised in spfbis, and found them severely lacking. In summary, "We tried doing SPF/99 10 years ago and it didn't work, so we stopped." I (and others) have several times now offered detailed responses explaining that in a post-3597 world that shouldn't be an issue anymore. "There are still some firewalls or other middleboxes that don't handle DNS properly" is a truism, but as pointed out by myself and Mark Andrews the value of "some" has been reduced to the margins by IPv6 and DNSSEC. Both that issue, and the issue of updating provisioning systems are things that need to be dealt with, but they are going to be true for whatever advances we want to make in the DNS. As an organization we have stated that we're not willing to be held hostage to those issues (5507), a position with which I maintain full agreement and support.

Further-furthermore, after I suggested that the way forward is to query SPF/99 first, it came to light that 2 of the major implementations (Mail::SPF and libspf2) _already do that_. A fact that the WG seems to be conveniently ignoring.

Frankly at this point I'm wondering what the fuss is about.

nor by any argument that leads to the
conclusion that an arrangement we would all like better has any chance
of deployment.

If your argument here is, "The SPF literati have spoken, don't intend to change, and wish you to stop bothering them by pointing out that they've come to the wrong conclusion," I'm sure you can imagine my response. However, given that 2 of the major implementations _have already switched to doing what I suggested_, what we're really talking about here is winning over the hearts and minds of "the masses" who do this stuff, write up the docs, etc. Personally I can't think of a better way to continue that ball rolling than to publish an spfbis document that documents how to do v=spf1 the way it should have been done in the first place, and specifies that future versions of SPF will be SPF/99 only.

Doug





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