Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE

[Doug Barton <[e-mail]>]

On 04/25/2013 03:41 PM, Pete Resnick wrote:
> On 4/25/13 3:54 PM, Doug Barton wrote:
>> On 04/25/2013 10:34 AM, Pete Resnick wrote:
>>> On 4/25/13 10:42 AM, Måns Nilsson wrote:
>>>> And IMNSHO spfbis is out of scope prescribing TXT records, just because
>>>> of this contagiousness.
>>>>
>>>> For the record: I think that the spfbis draft is unfit for publication
>>>> as RFC unless TXT records are deprectaed as only carrier of data.
>>>
>>> SPFBIS AD hat on for this:
>>>
>>> We are *long* past this discussion. This discussion should have happened
>>> at SPFBIS *chartering* time, as it is crystal clear from the charter
>>> that existing features currently in use in SPF are not going away.
>>> Indeed, the TXT record was specifically mentioned in the charter.
>>
>> As Ted pointed out, that seems not to be the case.
>
> Ted and I just had a discussion about this offline, and just as Ted did,
> you have misread what I wrote. I responded to Måns's suggestion that
> spfbis can not "prescribe TXT records". And I responded that existing
> features currently in use in SPF (of which the use of TXT is such a
> feature) are out of charter to remove. And they are.

... and for the Nth repetition, I did not propose to remove the TXT 
record at this time.

> The removal of the feature to use RR 99 was an option open to the WG if
> they determined that it was not on the forbidden list of "features
> currently in use". RFC 6686 and the discussion leading up to it document
> why it is, for all intents and purposes, unused.

Yep, been there, done that. It was a bad decision then, and it's still a 
bad decision now. I realize that it's incredibly unpopular to bluntly 
call bad decisions "bad decisions," but not doing so doesn't make them 
any less bad. And, to make matters worse, not doing so has led to a 
non-trivial number of those bad decisions becoming de facto standards. 
This has at least 2 very bad side effects ... first, we have to live 
with the bad de facto standards; but more importantly we are providing 
encouragement to people who wish to make similar bad decisions down the 
road.

The argument in 6686 boils down to, "We made a series of bad decisions, 
which have led to a bad result. We now want to codify that bad result 
instead of cleaning up our mess." I don't agree with that in principle, 
and I don't agree with that in regards to this particular case.

Further, while cleaning up the SPF mess would require nothing more than 
a marginal amount of extra work now, plus the passage of time, there is 
no reason not to actually clean up the mess.

>> Meanwhile, some of us have spoken long and loud about how deprecating
>> the SPF record is the wrong path, which includes before, during, and
>> after spfbis was chartered. Those concerns have consistently been
>> shouted down, as you are doing now.
>
> A few things on this point:
>
> 1. There is no doubt that the removal of the feature to use RR 99
> engendered a protracted and contentious discussion. However, it was not
> specifically discussed before or during chartering as far as I can tell.
> I've looked through the IETF list, the IESG list, the DNSEXT list, and
> the SPFBIS list and I see nothing on this topic discussed prior to
> chartering.

https://www.ietf.org/mail-archive/web/ietf/current/msg72024.html is 
where the thread starts. There is another parallel thread an a related 
topic around that same time.

> And importantly, I see not a single message from you in
> particular on this topic prior to this,

https://www.ietf.org/mail-archive/web/ietf/current/msg72085.html

> and only a few messages in
> September of last year on any SPF topic.  So I'm not clear on what you
> mean by "some of us" having "spoken long and loud" about this topic
> before or during SPFBIS being chartered.

With respect, you clearly haven't been paying attention. That thread on 
ietf@ (and the one you referenced on dnsext) took me about 2 minutes to 
find. Admittedly, the ietf@ thread wasn't specifically about SPF, but it 
was about the same exact topic, at the time that the spfbis charter was 
being developed, so one would think that interested parties would have 
wanted to pay attention.

The topic has been raised numerous times since day 1 of SPF, and the DNS 
folk who have said "the SPF RRtype should be the first (if not only) 
choice" have been consistently ignored.

Meanwhile, who said what when isn't the interesting part of the 
discussion. The questions are simple:

1. What is the right thing to do?
2. Can we do it?

We know the answer to 1, and the answer to 2 is yes. So why are we 
spending all of this time trying to find reasons not to do the right 
thing? If as much energy had gone into fixing the problem as has gone 
into justifying not fixing the problem, the problem would be fixed by 
now. :)

> 2. There is also no doubt that during the long discussion in February of
> last year on the SPFBIS list, many folks expressed the view that the
> feature ought not be removed, including by at least one chair of the WG.
> (In fact, that argument drove some of the research that ended up in RFC
> 6686.) However, in the end, a consensus call was made that, although
> there were some outstanding objections, those concerns were sufficiently
> addressed *by reasoned technical argument* and that the consensus (with
> some roughness) was that the feature was to be removed.

Yes, I know the history. It was a bad decision. The great thing about 
life, especially life in the IETF, is that bad decisions can be revisited.

> Though there may
> have been shouting at times, there was no "shouting down".

Others see the problem differently, but let's not quibble on that point.

> 3. I do not intend, and hope I have not, "shouted down" any argument
> here. However, there is now a long record on this argument and how the
> consensus call was made. Though the chairs and I will review all
> discussion that comes out during Last Call (or now), it really is only
> polite for (if not incumbent on) those who might still have objections
> to do some research to see if their particular argument was not
> addressed in that lengthy discussion. My claim in my earlier message was
> (and remains) that it's going to take identifying some piece of
> information that was missed during that discussion to convince me that
> the consensus call was not correct. As I've said elsewhere, number of
> people saying something is not how consensus is judged; it's whether the
> issue itself was properly addressed.  (See draft-resnick-on-consensus-02
> for my musings on that.) Coming to consensus is hard work, and it
> shouldn't just be hard work for chairs and ADs; participants have to do
> their part too.
>
> In particular:
>
>> The way forward is simple, spfbis should specify that compliant
>> senders MUST publish the SPF record, and compliant receivers MUST
>> query for it first. Then down the road at some point we can deprecate
>> TXT for this purpose.
>
> This is *not* a new argument. It was one that was discussed at length on
> the SPFBIS list at the end of last February. If you think we missed
> something (and I'd really ask you to read through the discussion of
> issue #9 on the list), I'd encourage you to make that case.

I'll give that a go, sure.

> But simply
> saying, "MUST publish/MUST query/later deprecate TXT" is not a
> sufficient technical argument given all that has been discussed to date.

But what if all of the previous discussion was wrong? Simply saying "we 
have discussed this extensively" doesn't refute sound technical 
arguments either. :)

>> In short, the proponents of SPF (which by the way, I like and use)
>> should be focusing on doing the right thing here, instead of the
>> expedient thing.
>
> If, after reading the discussion, you think SPFBIS was being superficial
> in its treatment of this topic and can identify an argument that was
> missed, fine. But your presumption that this was done simply for
> expedience is at the very least premature.

While I didn't follow the spfbis group, I have followed SPF from the 
time before it was even a topic at the IETF. Given what I know of the 
history I stand by my assertion, but would be overjoyed to be proven wrong.

Doug