On 08/21/2013 08:44 PM, Olafur Gudmundsson wrote: > > 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." > So what makes you think the above 4 points will not be a problem for the next protocol that comes along and needs (apex) RR data? And the one after that? While I appreciate the argument 'this works now, and it is used' (running code, and all that), I am very worried that we'll end up with what is essentially a free-form blob containing data for several protocols at the zone apexes instead of a structured DNS. So if this approach is taken, I suggest the wording be much stronger, in the hope this chicken/egg problem (with 5 levels of eggs. or chickens) will be somewhat mitigated at some point. Preferably with some higher-level strategy to support that goal. Jelte