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