Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Polic

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