Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

[Pete Resnick <[e-mail]>]

Speaking in my capacity as responsible AD for this WG and document, and 
the one who is going to have to judge the consensus of this Last Call 
and report to the IESG.

On 8/19/13 3:08 PM, Andrew Sullivan wrote:

> Note that I am not the shepherd for this draft, but I am the WG
> co-chair.
>
> On Mon, Aug 19, 2013 at 05:05:21PM +0200, Måns Nilsson wrote:
>
>    
>> * The charter disallows major protocol changes -- removing the SPF RR type
>> is a direct charter violation; since SPF is being used on the Internet.
>>      
> That argument doesn't work, because the WG had to make a major
> protocol change in this area no matter what, since 4408 has an
> interoperability problem.  If you wish to argue that the WG decided on
> the wrong protocol change, that line is open to you; but nobody can
> argue that the change is wrong because of our charter.
>    

To reinforce this point: Nowhere does the charter "disallow major 
protocol changes"; words to that effect do not appear in the charter. It 
does say that features in current use cannot be removed, but it also 
says that errors can be corrected. In this case the WG concluded that 
fixing the interoperability problem fell under the auspices of 
"correction of errors". The chairs agreed, and I saw no reason to disagree.

>> * The overloading of the TXT record is a hack at best, aimed at
>> circumventing DNS management systems vendors that fail to ship
>> support. Breaking the DNS model with specific resource records is not
>> the way to get better application support. (besides, the major argument
>> at the time was "it's so hard and takes ages to get a RR type", which
>> isn't true anymore and also, the RRtype is allocated, what's the fuss? )
>>      

This issue *was* considered and extensively discussed on the spfbis 
list. AFAICT, the conclusion the WG came to was *not* based on the 
argument that "it's so hard and takes ages to get an RR type". (Yes, the 
original decision to use TXT included that argument, but that was not 
the basis for the decision in the current WG.) And I don't know that 
anyone in the WG would disagree that "the use of the TXT record is a 
hack". The conclusion was that it was a hack that we are stuck with due 
to the current deployment profile. I think you will have to find 
something that the WG missed in that discussion to be convincing that a 
substantial change is needed.

There is no doubt the consensus in the WG was rough on the above two 
issues, but it was, by my reading, solid.

>> * The empirical data that was gathered and the conclusions from which
>> that where published as RFC 6686 are IMNSHO flawed and rushed in that they
>> set far too optimistic deadlines for adaptation before declaring failure.

I think you're going to need substantially more explanation (and perhaps 
some data) to make a convincing case that RFC 6686 needs to be 
reconsidered, thereby affecting this last call. The above states a 
conclusion, but provides no data or explanation. I don't know how to 
evaluation this.

pr

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