> In the previous message it was suggested that people who use a hosted DNS > service should switch if their service doesn't support Type SPF. The problem > is that, as far as I'm aware, none of them do. Perhaps in some cases it's because the person or persons who want to publish SPF records are not the ones who make the decision about which hosted DNS service provider to use, and are unable to make a sufficient case for a change to those who do have the authority to make it. It's also the case that even when the ability to publish such records exists, the person or persons who want to do so may not have the necessary access or authority and have no way to get it. Only today we were dealing with a customer who was asking about what options our product provides for overriding entries in his own DNS domain with local information. Yes, you read that right: The companies DNS has bogus stuff in it that cannot or will not be corrected. Such requests are unfortunately not uncommon. All that said, a suggestion: Patrik published a pretty good list of most of the issues that arise when attempting to deploy new RRTYPEs. Some of those, like the lack of GUI pulldowns in some hosting provider web interfaces, are clearly beyond the IETF's purview to address. But others, like the formatting issues in zone master files that arise when a new RRTYPE is defined, are things we can address. (And no, external scripts to do the format conversion are not a sufficient solution to this problem.) So might I suggest that instead of arging about the operational realities of deploying new RRTYPEs - which appears to be turning into yet another retelling of the parable about the blind men and the elephant - we instead turn our attention to activities that would actually address parts of the problem. In particular, John Levine has already written a draft that attempts to address the formatting issues by defining a simple format extension language. That might be a good place to start. (I've already sent him my review comments in private email.) Ned _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf