Dear colleagues, especially Mark,
On Sun, Mar 09, 2025 at 08:47:57AM -0500, Mark Andrews wrote:
SPF was never given enough time for the transition to happen. The software
that looked up SPF records was just starting to be deployed when people
complained that it had failed.
As I noted in my message to the list yesterday, that was not the basis on which
the SPFBIS WG reached the conclusion it did. As I suggested then, I think it
would be something short of a good use of everyone's time to re-hash that
discussion here, but I encourage anyone who wishes to re-live that exciting
chapter in IETF history to review the archives at
https://mailarchive.ietf.org/arch/browse/spfbis.
As for the FUD that was thrown around about the two types not working together.
I don't believe that is what I said yesterday, and I don't believe that is what I said at the time;
moreover, Mark, I think it is irresponsible of you to claim that a consensus of a WG is FUD. My
co-chair and I at the time determined (I believe correctly) that there was a consensus in the WG
that two fully-conforming implementations of the extant SPF RFC could be deployed that nevertheless
would not interoperate. That is not the same thing as the two types "not working
together". The WG determined that a formally backward-incompatible version of the
specification was needed in any case. Your remark about what one "just had to do" was,
of course, one way to solve that problem, but it was not what the specification required.
Requiring what you suggest would also have been a formal change to the specification. The WG had a
consensus to make a different change than the one you wanted. I'm sorry you didn't get what you
wanted, but that's the way rough consensus sometimes is.
I wouldn't belabour this point, except that it gets to the core of the draft under discussion. In
the best worked example anyone can think of, where something very much along the lines of the draft
was tried, people just didn't move away from TXT. Now, you and I can wish, all day long, about
some alternative future where, if we waited long enough (which might be "heat death of the
universe" or maybe just "DNS is fully replaced", whichever is sooner) TYPE99 would
have been widely deployed and TXT would be on the way out.[*] The reality is, however, that there
just wasn't much in the way of positive evidence that TYPE99 was rising in deployment. If there
was the kind of desire to move to a data-specific RRTYPE for a use like this, then we should have
seen that movement. And that is a principal objection to a mechanism like the draft before us
proposes. It all but guarantees a backward-compatibility mechanism gets deployed, and that lessons
the pressure to deploy any new RRTYPE.
[*] Of course, publishing an RFC (as you wished for SPF and as the draft under consideration proposes for other types) that would guarantee both TYPE_N_ and TXT records in the DNS for the same use is pretty unlikely to hurry along the state of affairs in which TYPE_N_ alone appears. This seems to me to be another way of making the same point.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
