On Monday, August 19, 2013 14:54:44 David Conrad wrote: > Hi, > > On Aug 19, 2013, at 12:10 PM, Scott Kitterman <scott@xxxxxxxxxxxxx> 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. Possibly because your 'a' and 'b' strawman don't reflect the working group's rationale. As previously mentioned, it's in the archives. Scott K
Attachment:
signature.asc
Description: This is a digitally signed message part.