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 Standard2013-08-19 15:49:59
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. - +1 (858)651-4478 |
|