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

Hi,

On Aug 19, 2013, at 12:10 PM, Scott Kitterman <scott(_at_)kitterman(_dot_)com> 
wrote:
> Operationally, there are far more problems associated with actually trying to 
> use Type 99 than there are with SPF records in Type TXT.
Given the abysmal state of implementation of middleboxes _today_, this isn't 
surprising.  I'm unsure this sad state applies for all future time to come.

> As Michael Hammer mentioned, we've been through all this before and people 
> might want to review the previous WG discussion on the topic.
+1

However, despite the operational issues mentioned above and the fact that this 
has been discussed to death, I also strongly oppose the deprecation of the SPF 
record. AFAICT, no one is arguing that overloading TXT in the way recommended 
by this draft is a good idea, rather the best arguments appear to be that it is 
a pragmatic "least bad" solution to the fact that (a) people often implement 
(poorly) the very least they can get away with and (b) it can take a very long 
time to fix mistakes on the Internet. 

Of course, both (a) and (b) can be improved over time.  The argument that "it's 
already been X years and only Y% of implementers have supported SPF so we 
should throw in the towel now" seems specious to me since:

1) the SPF type code has been allocated -- it isn't going away or going to be 
reused: deprecation gains nothing from a DNS perspective;
2) pretty much every implementation of name servers supports SPF (to one degree 
or another);
3) there exist implementations of DNS frontend UIs that support SPF and since 
the semantics are identical to TXT, future implementation would seem to be 
trivial if a UI supports TXT; and
4) deprecation of SPF imposes additional complexity on every other protocol 
implementation that uses TXT at the zone apex either now or in the future.

In the past, the IETF/IESG has frowned on 'squatting' on port numbers, 
addresses, etc., regardless of the potential operational implications of 
accepting that squattage. I personally feel the use of TXT in this context is 
only marginally different than squatting. In my view, deprecating SPF only 
makes sense if the protocol that would use SPF is not going to see further 
deployment.  Since as far as I know, the point of 4408bis is to clarify 
implementation requirements for future implementations, deprecation makes no 
sense to me.

Regards,
-drc

signature.asc
Description: Message signed with OpenPGP using GPGMail