Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Scott Kitterman wrote:
On Wednesday, August 21, 2013 14:44:41 Olafur Gudmundsson wrote:
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).

Consider that those specifications were written by the same author and group of folks. In no special meaning in any way, they all have had the same engineering mindset when it came the DKIM, VBR, ADSP and now even yet another DMARC proposed protocol. Same engineers, same engineering synergism. Thats not a negative commentary. This is desirable in an integrated world, but it can also locked down certain views as it has this case.

DKIM learned from the SPF success with TXT. I specifically recall the WG decision discussion and it made practical sense. It allowed for an immediate entry point and fast proof of concept industry wide by using a TXT-based protocol, not only for DKIM but also for its original companion protocol ADSP (formerly SSP). Overall, I had sense a growing change in TXT-based protocol acceptability with many folks who otherwise were against it and this was quite apparent to me being highly considerate and cognizant of the technical design issue.

It was for this reason I asked the question in the DNSEXT list and IETF before LC about where the industry stood in regards to TXT based solutions. I always had several ideas of my own for TXT-based DNS proposals such as DSAP (DKIM Signature Authorization Protocol) and a few others and if the IETF/DNS community was going to changed its belief and now endorse the TXT ideas, I didn't want to propose anything that would be controversial such as a new RR type, although that would most likely appease the DNS folks.

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.

I don't agree with the SPF exception. If you believe in the future infrastructure to support new RR types, then there is no sensible reason to remove the SPF type and migration path from an updated RFC-4408BIS document.

I don't see any harm in keeping the migration path IFF there is confidence a supportive infrastructure will be available in the future.


--
HLS






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]