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
