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

"Murray S. Kucherawy" <superuser@gmail.com> Mon, 19 August 2013 21:04 UTC

Return-Path: <superuser@gmail.com>
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 CBE2A21F9C99; Mon, 19 Aug 2013 14:04:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 b3devI204NW3; Mon, 19 Aug 2013 14:04:12 -0700 (PDT)
Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A485421F8481; Mon, 19 Aug 2013 14:04:11 -0700 (PDT)
Received: by mail-we0-f170.google.com with SMTP id w62so1515635wes.15 for <multiple recipients>; Mon, 19 Aug 2013 14:04:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+4ddx6O5F/ju5AQE0dKT5GrqEnwvOPbrMPngd2i3A+I=; b=B9iNjoHBUajP/yfJWYC83iXEPgYPttkHvlZqlhDyu9pLcLIvhlsH40kDhNaTSLI9aT yALlUQMCxG3XTDyrErP2LbHbFOWCpqKzmXAAXXv8zfolLM7Ply1We20QkWXauxrOCHdA sdGVuMqysRtbzftTxFF6aP8jUscgzdZSCGyDsAoZ3NQuFrH/UOZ4NJcuCZVYEI2aoWNT EvBD/h2qe2DTTldyF309+iSQICdkZIieSBqQctzJbNvostBzMMMlH/IlVq8gKSdBqhyG YwbLmTtnwck4U/xTL0nv+EqiSesD6VexIz0UOA8shiBBmDgqqTkO3l8rDghfSxbEdWm4 SUqg==
MIME-Version: 1.0
X-Received: by 10.180.183.51 with SMTP id ej19mr9886856wic.60.1376946250594; Mon, 19 Aug 2013 14:04:10 -0700 (PDT)
Received: by 10.180.125.36 with HTTP; Mon, 19 Aug 2013 14:04:10 -0700 (PDT)
In-Reply-To: <5212873B.1010007@dcrocker.net>
References: <20130819131916.22579.36328.idtracker@ietfa.amsl.com> <20130819150521.GB21088@besserwisser.org> <20130819200802.GI19481@mx1.yitter.info> <521284A4.4050901@qti.qualcomm.com> <5212862F.3080507@qti.qualcomm.com> <5212873B.1010007@dcrocker.net>
Date: Mon, 19 Aug 2013 14:04:10 -0700
Message-ID: <CAL0qLwaPJSEXbEadyxcExDSbHg7RMDZ-YzfLztkHkvNF6WOOAQ@mail.gmail.com>
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
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Dave Crocker <dcrocker@bbiw.net>
Content-Type: multipart/alternative; boundary="001a11c2409e243f5704e4534896"
Cc: "spfbis@ietf.org" <spfbis@ietf.org>, Pete Resnick <presnick@qti.qualcomm.com>, Måns Nilsson <mansaxel@besserwisser.org>, ietf <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Mon, 19 Aug 2013 21:04:12 -0000

On Mon, Aug 19, 2013 at 1:59 PM, Dave Crocker <dhc@dcrocker.net> wrote:

> On 8/19/13 3:48 PM, Pete Resnick wrote:
>
>> * 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.
>>>
>>
>> Of course, I meant, "I don't know how to *evaluate* this."
>>
>
>
> From earlier exchanges about this concern, the assertion that I recall is
> that 7 years is not long enough, to determine whether a feature will be
> adopted.  That is, failure to gain deployment traction after 7 years from
> the time of publication should not be taken as a sufficient waiting period.
>
> I do not recall anyone (else) showing support for that view, but certainly
> not any substantial constituency.
>
>
Moreover:

What is the premise for seven years being "not long enough"?  And what does
constitute "long enough"?  And upon what is that last answer based?

It would be wonderful if the boundaries for this test were written down
somewhere, so that we would've had that information when we did the
research for RFC6686.

-MSK