Re: [apps-discuss] Updating the status of SPF

Scott Kitterman <scott@kitterman.com> Fri, 12 August 2011 15:38 UTC

Return-Path: <scott@kitterman.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F389B21F85C4 for <apps-discuss@ietfa.amsl.com>; Fri, 12 Aug 2011 08:38:23 -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=[AWL=0.000, BAYES_00=-2.599]
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 ZNkNzycqvS2Y for <apps-discuss@ietfa.amsl.com>; Fri, 12 Aug 2011 08:38:23 -0700 (PDT)
Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 415FC21F859F for <apps-discuss@ietf.org>; Fri, 12 Aug 2011 08:38:23 -0700 (PDT)
Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 1BCB538C12D; Fri, 12 Aug 2011 11:39:00 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1313163540; bh=1PCBWVQHHxpK2BNX2bs3c9xhIHKmiIMQRnHa1jlnu2o=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=QmRSOs9Fx/X/QsHHJrbv2y1F25Znr8L4ZQDS2d+gsPNZ8bVX5MDlXx9idBp31Yj5h dYslNrInLz3g0UCPJ1+96xb60hV5IsPTw2MhANT6t1me1upPPX2n9VVrs8/A+TAljm hyRKU1tsXlvmd/rG7ULdm0EhgPUor5IGAA6K2XbE=
From: Scott Kitterman <scott@kitterman.com>
To: apps-discuss@ietf.org
Date: Fri, 12 Aug 2011 11:38:57 -0400
User-Agent: KMail/1.13.6 (Linux/2.6.38-10-generic-pae; KDE/4.6.2; i686; ; )
References: <201108092337.39408.scott@kitterman.com> <201108121000.49202.scott@kitterman.com> <20110812142109.GD3724@shinkuro.com>
In-Reply-To: <20110812142109.GD3724@shinkuro.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201108121138.57806.scott@kitterman.com>
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [apps-discuss] Updating the status of SPF
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Aug 2011 15:38:24 -0000

On Friday, August 12, 2011 10:21:10 AM Andrew Sullivan wrote:
> On Fri, Aug 12, 2011 at 10:00:48AM -0400, Scott Kitterman wrote:
> > It's in wide scale use.  The goal of the current effort is to document
> > that use.
> 
> I don't know why a WG is necessary for that.  There are three
> possibilities here.
> 
> One is that SPF as specified is in wide scale use, in which case there
> is no real protocol work that is needed.  All that is needed is a
> report (maybe as an RFC) saying, "This thing was widely deployed.  The
> experiment worked."
> 
> If, however, the experiment did not work, or bits and pieces of the
> RFC are not actually implemented or are implemented differently or are
> implemented diffrently by different people, then the new effort can do
> one of two things.  One is to move the experimental protocol to the
> standards track.  But that automatically requires that one make some
> determination about which pieces are going to change, and as Dave
> Crocker said somewhere in this thread that is going to attract all
> manner of disagreements.  The other is simply to document exactly what
> is out there and how things do and do not deviate from the
> experimental protocol.  The latter is surely an exercise in research
> that delivers an informational document but does not move the protocol
> onto the standards track.
> 
> In my view, if the goal is to move the protocol to the standards
> track, then addressing issues in the protocol as already documented
> (and as actually deployed) has to be an open possibility.  If that's
> not the goal, then I have no objection.  I don't see what the value
> would be in moving something to the standards track without being
> willing to undertake standards work on it.

I can understand that view.  On the other hand, in the absence of data 
documenting deficiencies in the experimental protocol I think it would be 
imprudent to abandon the benefits of years of experience with running code.

My view is that the experiment was largely successful and only minor changes 
based on this experience are necessary.  It may be that during the work of the 
group other information will come to light that will cause me to change that 
view.  I'm not saying don't deviate, but give due weight to the experience 
with the current design and running code and don't deviate other than to fix 
significant issues.

Scott K