On Wednesday, August 21, 2013 14:44:41 Olafur Gudmundsson wrote: > On Aug 19, 2013, at 5:41 PM, Andrew Sullivan <ajs@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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