Re: [dnsext] Obsoleting SPF RRTYPE

[Ted Lemon <[e-mail]>]

On Apr 25, 2013, at 12:01 PM, Ted Lemon <[e-mail]> wrote:
> It seems to be the case that there are rather a lot of people on the dnsext mailing list who are on the rough side of the consensus here.   That suggests that perhaps the consensus isn't in the direction that we are presuming it is.

There have been a number of rather stiff comments sent to me privately about this statement, particularly with respect to the fact that as AD, I might have some influence on the consensus call on the SPF document.   One person said that I should be very clear about whether I am wearing my AD hat when I make comments like this, which I think is a valid point, and that further, I probably shouldn't make statements like this at all, which I am not sure is a valid point; neither am I sure it is not.

So to be clear here, the document in question is not a DNSEXT document, and I am not responsible area director for the working group in which the document has been considered.

Someone proposed that I might be threatening to use my influence as one member of the IESG to influence the outcome of the consensus call on this document.   To be clear, I was not threatening to do that, and it hadn't occurred to me that someone would think I was threatening to do that. I do understand why someone might have been concerned that I was threatening to do that, and I apologize for having given that impression.

As to what I did mean here, what I meant is that I think this is a matter that DNSEXT people are clearly interested in, and there are a lot of DNSEXT people who think deprecating the SPF record in favor of the TXT record is exactly the wrong thing to do, including me with my AD hat off.

With my AD hat on, I actually have no clue how to resolve this question.   I've been in working groups where another working group has dogpiled on an issue.   It's certainly appropriate for people who do not agree with the deprecation of the spf record to participate in the spfbis last call, although you ought to read the document and review the history first.

However, there is also an IETF last call, and the purpose of the IETF last call, as I understand it, is to evaluate whether a document that a working group has produced actually has consensus within the IETF.   As far as I understand it, it is entirely in scope for participants on the dnsext mailing list to speak up at the IETF last call and say "hey, this is a really bad idea, here's why."

It's my understanding that the responsible AD for the working group whose document got pushback in IETF last call is supposed to evaluate consensus on that document; that would be Pete Resnick, not me, so you don't have to worry about my corrupt influence on that process.

I don't think IETF last calls often fail to produce consensus, but it did happen recently with the MIF DHCP Default Route option.   Like this document, the DHCP Default Route option was in the MIF charter, which had been through IETF last call.   But when the document itself went though IETF last call, there was substantial pushback.   As a result of this, the document did not advance.

It might be worth considering another related case.   Years ago, the DHC working group proposed a new RRtype, the DHCID RRtype.   At the time, existing DHCP servers were using TXT records to record identifiers on names so that they could tell whether or not it was safe to do a DNS Update on that name on behalf of a client that was claiming the name.   We wrote up a single, thorough document explaining how to do it, brought it to DNSEXT, and got the rotten tomato treatment.

Eventually we broke the document up into three pieces, published one as a DNSEXT (or was it DNSIND?) document, one I think as a DNSOP document, and one as a DHC document.   At the time of publication, and for many years after, 100% of implementations used the TXT record, not DHCID.

I do not know what the prevalence of DHCID in the field is at this point.   I don't actually care.  The standard says the right thing.   If existing implementations do something different, that's okay, as long as it works.   Eventually the implementations will get fixed.   I think this is the right outcome for DHCID.   It's not exactly analogous to the situation with SPF, though, where the text record is actually documented in RFC4408.

I think you can make an argument for letting this go, or for trying to argue the point.   I honestly don't know what the right move is—this debate really should have happened when the spfbis charter was last called.   Perhaps we should take this as a lesson to follow the IETF mailing list more closely—I certainly didn't notice this when it went by, and I wish I had.   This kind of ships-passing-in-the-night problem happens a lot in the IETF, and I've never seen a good proposal for how to solve it.