On Wednesday, August 21, 2013 14:44:41 Olafur Gudmundsson wrote:
On Aug 19, 2013, at 5:41 PM, Andrew Sullivan
<ajs(_at_)anvilwalrusden(_dot_)com> wrote:
I'm not going to copy the spfbis WG list on this, because this is part
of the IETF last call. No hat.
On Mon, Aug 19, 2013 at 02:04:10PM -0700, Murray S. Kucherawy wrote:
On Mon, Aug 19, 2013 at 1:59 PM, Dave Crocker
<dhc(_at_)dcrocker(_dot_)net> wrote:
From earlier exchanges about this concern, the assertion that I recall
is
that 7 years is not long enough, to determine whether a feature will be
adopted.
What is the premise for seven years being "not long enough"? And what
does
constitute "long enough"? And upon what is that last answer based?
I have two observations about this. First, EDNS0, which is of
significantly greater benefit to DNS operators than the mere addition
of an RRTYPE, took well over 10 years to get widespread adoption.
Second, we all know where IPv6 adoption stands today, and that has
certainly been around longer than 7 years. So I think it _is_ fair to
say that adoption of features in core infrastructure takes a very long
time, and if one wants to add such features one has to be prepared to
wait.
But, second, I think all of that is irrelevant anyway. The plain fact
is that, once 4408 offered more than one way to publish a record, the
easiest publication approach was going to prevail. That's the
approach that uses a TXT record.
For the record I think SPF RRtype retirement is not in the good-idea
category, but nor is it in the bad-idea category, it falls in the we
need-to-do-something-that-works.
Most of the recent arguments against SPF type have come down to the
following (as far as I can tell): a) I can not add SPF RRtype via my
provisioning system into my DNS servers b) My firewall doesl not let SPF
Records through
c) My DNS library does not return SPF records through or does not
understand it, thus the application can not receive it. d) Looking up SPF
is a waste of time as they do not get through, thus we only look up TXT
So what I have taken from this is that the DNS infrastructure is agnostic to
RRtype=99 but the edges have problems.
As to the arguments 7 years is not long enough to reach conclusion and force
the changes through the infrastructure and to the edges. The "need" for SPF
has been blunted by the "DUAL SPF/TXT" strategy and thus we are basically
in the place where the path of lowest-resistence has taken us.
What I want the IESG to add a note to the document is that says something
like the following: "The retirement of SPF from specification is not to be
taken that new RRtypes can not be used by applications, the retirement is
consequence of the dual "quick-deploy" strategy. The IETF will continue to
advocate application specific RRtypes applications/firewalls/libraries
SHOULD support that approach."
I'm a bit unsure that continue is the right word. DKIM moved to the TXT with
underscore approach and, IIRC, never considered a new RRTYPE, nor did anyone
ever suggest they should. DMARC, which has had a BoF and for which a WG is
being considered will do the same (there's no variant of proposed charter text
floating around that would allow them to consider otherwise).
I agree with that the notion of a statement that SPF is what it is for a
variety of reasons and shouldn't be considered as a precedent for the future
might be a reasonable thing to add. I don't think the IETF has been very
consistent about what one ought to do instead.
Scott K