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

Dave Crocker <dhc@dcrocker.net> Wed, 21 August 2013 17:32 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6757E21F9A17 for <ietf@ietfa.amsl.com>; Wed, 21 Aug 2013 10:32:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.384
X-Spam-Level:
X-Spam-Status: No, score=-6.384 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXmdNhkZVwbq for <ietf@ietfa.amsl.com>; Wed, 21 Aug 2013 10:32:12 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF8A11E83C2 for <ietf@ietf.org>; Wed, 21 Aug 2013 10:32:12 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7LHW4Nu022476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Aug 2013 10:32:08 -0700
Message-ID: <5214F97B.2080400@dcrocker.net>
Date: Wed, 21 Aug 2013 10:31:39 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Patrik Fältström <paf@frobbit.se>
Subject: 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
References: <20130819150521.GB21088@besserwisser.org> <20130819160549.61542.qmail@joyce.lan> <20130819190533.GA30516@besserwisser.org> <4751241.GTNxysAlzm@scott-latitude-e6320> <B443E973-858A-4958-964B-B0F0FBDF5A7A@virtualized.org> <CAMm+LwhcHOeUv0iqZmZ6wX-jOD1r-mRR0x8sbxaKrsU3k4CNBQ@mail.gmail.com> <20130821040003.GL607@mx1.yitter.info> <64700EE4-85B3-4179-904A-885770C6BBF4@virtualized.org> <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se> <521495EB.7060207@cisco.com> <1C40FB10-3705-4E80-8DEB-D14B63D24C97@frobbit.se> <5214A593.8030907@cisco.com> <E3B3B6B0-F17F-44D0-ACD1-53BDBAC6F2CB@frobbit.se>
In-Reply-To: <E3B3B6B0-F17F-44D0-ACD1-53BDBAC6F2CB@frobbit.se>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 21 Aug 2013 10:32:08 -0700 (PDT)
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Aug 2013 17:32:17 -0000

Patrik,


On 8/21/2013 7:17 AM, Patrik Fältström wrote:
> My conclusion is that a statement that nobody queries for it is
> false.

Assuming that your conclusion is based on pragmatics and not
mathematical purity -- that is, that it is concerned with significant
operational effort, rather than a stray implementation here or there,
which counts as "noise" in any legitimate statistical analysis -- what
is the basis for your conclusion?

In other words, please explain how your objection is based on real-world
utility rather than something more abstract and detached from practical
operations.




 From your posting to the dnsext working group:

> On 8/20/2013 11:58 AM, Patrik Fältström wrote: In general I do
> believe, for example when looking at IPv6 and DNSSEC and similar
> technologies, that the lifetime of RFC 4408 is too short to
> deprecate any of the proposed records that are in use, specifically
> as RFC 4408 explicitly do allow use of both.

On its face, this sort of thinking means that, in practical terms,
nothing can ever be deprecated.

It also requires a rather willful ignorance of the essential community
operations differences between SPF and IPv6 and DNSSec.  There is
massive effort to increase use of the latter.  There is massive apathy
about the former.

That is, the metric of essentially no adoption or use is matched by no
vector of change.

So if you really insist on pursuing your objection, please find some
arguments that are anchored in relevant, real-world analytic legitimacy.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net