Re: Last Call: <draft-ietf-marf-spf-reporting-08.txt> (SPF Authentication Failure Reporting using the Abuse Report Format) to Proposed Standard

Scott Kitterman <scott@kitterman.com> Thu, 01 March 2012 14:22 UTC

Return-Path: <scott@kitterman.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 7EA9C21E82D1 for <ietf@ietfa.amsl.com>; Thu, 1 Mar 2012 06:22:25 -0800 (PST)
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]
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 Gp9x1H+TLHtf for <ietf@ietfa.amsl.com>; Thu, 1 Mar 2012 06:22:24 -0800 (PST)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7331621E8276 for <ietf@ietf.org>; Thu, 1 Mar 2012 06:22:24 -0800 (PST)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C04B620E40DA; Thu, 1 Mar 2012 09:22:23 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330611743; bh=akvEt92GrcOvLJdoBBC34UEw2IX1VuBa9pMvu9ds+30=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=KxFuFv5zecW60R4dJSWSDdWkFUkilir9G6kVqaS6rseqhY5AclDkliA4g0aYMgq/T niCgM/WipZ5pIjrF4xyqpJAZqR0X8lN2GH/80xtpxHmmwRtJM5kZILSmgT2IoJpLnC /dXPq/L6uqEw3DmK/YsFDltA3k59K6rDmwWGPzoM=
Received: from scott-latitude-e6320.localnet (170.sub-97-10-249.myvzw.com [97.10.249.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6C14C20E408F; Thu, 1 Mar 2012 09:22:23 -0500 (EST)
From: Scott Kitterman <scott@kitterman.com>
To: ietf@ietf.org
Subject: Re: Last Call: <draft-ietf-marf-spf-reporting-08.txt> (SPF Authentication Failure Reporting using the Abuse Report Format) to Proposed Standard
Date: Thu, 01 Mar 2012 09:22:22 -0500
Message-ID: <8066871.IkNuLJFsLQ@scott-latitude-e6320>
User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; )
In-Reply-To: <6.2.5.6.2.20120229181328.0a95a9f8@resistor.net>
References: <20120301004643.17274.83943.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120229181328.0a95a9f8@resistor.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
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: Thu, 01 Mar 2012 14:22:25 -0000

On Wednesday, February 29, 2012 10:26:41 PM SM wrote:
> At 16:46 29-02-2012, The IESG wrote:
> >The IESG has received a request from the Messaging Abuse Reporting Format
> >WG (marf) to consider the following document:
> >- 'SPF Authentication Failure Reporting using the Abuse Report Format'
> >
> >   <draft-ietf-marf-spf-reporting-08.txt> as a Proposed Standard
> >
> >The IESG plans to make a decision in the next few weeks, and solicits
> >final comments on this action. Please send substantive comments to the
> >ietf@ietf.org mailing lists by 2012-03-14. Exceptionally, comments may be
> 
> [snip]
> 
> >Note that this document has a downward normative reference: This
> >document makes a normative reference to SPF (RFC4408), which is
> >Experimental.
> The MARF charter [1] does not contain any mention of "SPF
> Authentication Failure Reporting using the Abuse Report Format" as a
> deliverable.  There is no mention of SPF in the charter.
> 
> According to the Abstract Section of this document:
> 
>    "This memo presents extensions to the Abuse Reporting Format (ARF),
>     and Sender Policy Framework (SPF) specifications to allow for
>     detailed reporting of message authentication failures in an on-demand
>     fashion."
> 
> This extends a specification on which there hasn't been any
> conclusion yet.  I note that there is a downward normative reference
> to RFC 4408.  During discussions about RFC 4408, on which I don't
> have any opinion up to now, there have been comments about:
> 
>   (i)   The specification not being sufficiently clear.
> 
>   (ii)  A compelling case that there is, indeed, an error in RFC4408.
> 
>   (iii) Interoperability problems in the protocol due to DNS
> "incompatibility".
> 
> I suggest that the IETF waits for a migration or co-existence
> document which discusses about the non-standards track protocol on
> which there is a downward reference.

I'll limit my response to these aspects of your comment, since they are the 
most important to resolve.

I'll leave it to the MARF chairs to explain their view of how this is related 
to the charter.  This draft is, however, related to draft-ietf-marf-
authfailure-report, which is already through last call and approved by the 
IESG.  It includes SPF specifics (although it doesn't require a normative 
reference to RFC 4408, so there's no downref issue with it), so I think that 
in the context of authentication failure reporting this is already established 
to be in scope.  All the current draft does is provide an optional mechanism 
to make the desire for such reports discoverable.

This draft does not depend on any elements of RFC 4408 that are under review 
in SPFbis (in fact, it's not possible in the current scope of the SPFbis 
charter to change any of them), so the risk that the ongoing work in SPFbis 
will affect this body of work is nil.

I don't think it's efficient at all to put this draft on hold and revive it 
later for non-technical reasons.

Scott K