Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE

[Ted Lemon <[e-mail]>]

[This is really long, because I've spent a lot of time thinking about this and reading the discussion; the tl;dr is that I don't intend to contest the obsoleting of the SPF RRtype any further, but <ad hat off>would not fault others for doing so</>, and <ad hat on>I think there are lessons to be learned about how the process went this time</>, which, if you are interested in that, might be a good reason to continue reading.]

On Apr 25, 2013, at 8:22 PM, S Moonesamy <[e-mail]> wrote:
> I am ok if anyone says that it a bad decision.  The thread for the discussion started at http://www.ietf.org/mail-archive/web/spfbis/current/msg00426.html

<no hat>

I undertook the exercise of reading this thread, and it looks like there was some very interesting data collection work done.   I didn't find a point at which a consensus was determined; I presume that happened later, on some other thread.

> I was the document shepherd for RFC 6686.  There wasn't any comments during the Last Call.

FWIW, and I do not intend this as a criticism of what you did, I just went back to the datatracker and looked at the text of the IETF last call.   There is nothing at all in this text that would indicate that the document said anything at all about the continued use of the SPF DNS RRtype.   I've also read the document, and even reading the conclusion of the document, there's very little there that would suggest to me that the spfbis working group was about to deprecate the use of the SPF DNS RRtype.

Of course someone who was already involved in the discussion on the mailing list would know this, but there's no reason to think that anyone reading the dnsext mailing list would have felt it was their duty to review this particular document during the IETF last call, and if they had reviewed it, they might still have remained innocent of any understanding that spfbis intended to deprecate the SPF RRtype in favor of the TXT record.

> If there are any new arguments which have been missed please let me know as I can include them in my write-up.  If the argument is solely "do the right thing" I will decline including it in the write-up as it is, in my individual opinion, non-technical.  I cannot comment on what arguments should be provided as I will then be biasing the outcome.

<still no hat>
It seems to me that the argument in favor of deprecating SPF is that nobody is publishing SPF records, despite widespread support in software.   This results in unnecessary traffic, the elimination of which would have minimal impact.

On the other side, here are the arguments that I understand to have been made:

1. TXT records are not specific to SPF, thus we can't assume that any given TXT record is an SPF record.
Rejoinder: doesn't seem to be an issue in practice—no other TXT records are needed on the names to which SPF TXT records are typically attached.

2. Because TXT records aren't specific to SPF, a query for TXT records may return an unexpectedly large result set, requiring fallback to TCP.
Rejoinder: doesn't seem to be an issue in practice.

3. Using TXT records is a bad idea.
Rejoinder: this isn't really a technical argument; if there is a technical argument in here, it should be stated explicitly, but this argument per se will be ignored.

4. Using TXT records sets a bad precedent.
Rejoinder: the horse is already out of the barn.

I think there's one possible benefit to be considered for using TXT records for SPF: it gets in the way of other uses of TXT records, and acts as a sound technical argument against adoption of TXT records on bare names in future protocols.

Speaking entirely with my AD hat off, and merely as an armchair quarterback, I don't think it's fair to say that the consensus call in spfbis on what was to become RFC6686 and the IETF consensus call on that document, taken together, represent IETF consensus.   I don't think the rejoinders to arguments 1 and 2 are very convincing, although they seem to have carried the day in the spfbis working group, and I understand why.

The reason I reacted the way I did when drc brought this up is that it was a surprise to me that spfbis was eliminating the SPF record from the specification.   It is not surprising that it was a surprise—the process that was followed, which I think was followed correctly and with the best intentions, did not really have much chance of bringing this decision to my attention while it was being discussed in spfbis.

Having reviewed the discussion in spfbis, and argued with this at length with Pete, I am remarkably ambivalent about it.   I don't like the decision the spfbis working group has made.  I don't agree with the decision.  I understand why you made it, and don't fault you for having made it.   It's probably not worth my personal time to dispute it.

I would rather work to hasten the demise of SMTP and all the anti-spam kludges that rode in on it.

<ad hat on>
So, what do I think could have gone better here?   First, it would have been very helpful if the abstract for RFC 6686 had said that the reason the research was being done was to answer the question "should we continue supporting the SPF RRtype, or drop it?"   Authors of drafts that are trying to address issues like this might want to think carefully about how they write abstracts, since it's only the abstract that gets shown in the IETF last call message.   If your abstract doesn't attract the people who ought to be reading the document, it's going to be hard later to argue that the document had a clear IETF consensus, even though it nominally has consensus.

It may be that using the document abstract in the last call announcement is not sufficient—if authors phrased the abstract the way I've suggested, it might be the wrong thing for the document once it's published.   I don't know the answer to this—it might also be the right thing.

I think it's clear that early in this discussion, all present, including the responsible AD, were aware that it was going to be contentious.   I think if a message like the one drc sent to the mailing list yesterday had gone out in February of 2012, you would have gotten the exact same response.   This probably would have created additional hassle on the spfbis mailing list as a bunch of dnsext people dogpiled there, but we wouldn't be having _this_ conversation _now_, so it actually would have been better, despite the short-term hassle.

Andrew did raise this issue to the dnsop working group; he didn't mention raising it on dnsext.   I don't remember seeing it on the dnsop mailing list, and I'm not finding it in the archive; I don't see it in the minutes either.   This doesn't mean it isn't there; it just means that it didn't stand out the way drc's message did.   This ought to be a valuable lesson for working group chairs; if you know something is going to be contentious, rip the bandaid off—don't be quiet about it.   Make sure the people who you know are going to kick up a fuss do it at the right time.   I know Andrew didn't intend to not rip off this bandaid, so I'm not sure how this failed to happen, but it's something to think about.

The responsible AD also knew this was going to be contentious (I think!).   I don't know if he talked this over with Ralph (who was then the responsible AD for dnsext) or not.   If he did, that was the right thing to do, and it's worth considering why it didn't work.   If he didn't, this might be a lesson to remember for the future.   Same thing should have happened with the responsible AD for dnsop; I don't know who that was.

Of course, ADs don't always know that what's being raised in the working group is going to be contentious in other areas.   Working group chairs need to be proactive about this.   ADs can definitely be a resource in spreading the word, though, whether they do it on their own or at the request of working group chairs.   And of course working group chairs may not always know that something will be contentious, but there's nothing we can do about that case other than live with the late surprise.
</hat>

I hasten to emphasize that I don't really know what went wrong here.   It may be that even if all the remedies I've discussed above had happened, we'd still be having a big kerfuffle about this on the dnsext mailing list.   My motivation for suggesting that more could have been done is simply my experience as a participant: I really think I would have participated in the discussion about this if I'd realized it was happening last February.  I get the impression from several other participants in the discussion now that they weren't aware of it either.   I don't have a sense of whether the discussion would have come out differently if we'd participated.

<hat>
As for how to participate now, the right thing to do for people who feel they were left out of the discussion before is to read the draft, read the historical discussion (to which pointers have already been given) and then participate constructively on the spfbis working group mailing list.

"Tromping" on this in IETF last call would not be constructive given that it has not passed a working group last call.  I'm sorry for having suggested that—I understood the document to have already passed WGLC, and stupidly didn't go check to see if my impression was correct.
</hat>

And, by the way, internet dating is quite a lucrative industry, so it's probably a bad example of a hopeless task.   :)