Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE

[Pete Resnick <[e-mail]>]

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.

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.

> 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. And importantly, I see not a single message from you in 
particular on this topic prior to this, 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.

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. Though there may 
have been shouting at times, there was no "shouting down".

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

> 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.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - [phone]