Re: [apps-discuss] Revised DMARC working group charter proposal

Scott Kitterman <scott@kitterman.com> Thu, 18 April 2013 21:09 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 E834221F8CDD for <apps-discuss@ietfa.amsl.com>; Thu, 18 Apr 2013 14:09:48 -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]
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 z0pnGdh3cBAx for <apps-discuss@ietfa.amsl.com>; Thu, 18 Apr 2013 14:09:47 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CE26F21F8C98 for <apps-discuss@ietf.org>; Thu, 18 Apr 2013 14:09:47 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id F1D5220E40D4; Thu, 18 Apr 2013 17:09:44 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366319385; bh=l1dkkvWlyJmRcQmPwcXMHJ3PzUOB/wXiTwDmrZTiRmM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=k3IMlZ83bvTQhOKDILjV6HpRqVslpCoyIxu1+MILG2lTdpuag2Ylh6HdaB2JcjjXD 0Pmz5Hegq3EM4wwXffgePARzlnDldeMonQgKDWPUsm2ko5N+yE8caYkJtqA33lBHNk PnO/KTVKzdz1YGxSt5Q3xGx7v+D/c17cKIma/rFI=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id D725720E4090; Thu, 18 Apr 2013 17:09:44 -0400 (EDT)
From: Scott Kitterman <scott@kitterman.com>
To: apps-discuss@ietf.org
Date: Thu, 18 Apr 2013 17:09:43 -0400
Message-ID: <2779691.DUaGRL1rZT@scott-latitude-e6320>
User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; )
In-Reply-To: <51705FA9.2080106@dcrocker.net>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com> <5158537.VifRbVZBdl@scott-latitude-e6320> <51705FA9.2080106@dcrocker.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [apps-discuss] Revised DMARC working group charter proposal
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: Thu, 18 Apr 2013 21:09:49 -0000

On Thursday, April 18, 2013 02:03:37 PM Dave Crocker wrote:
> On 4/18/2013 1:50 PM, Scott Kitterman wrote:
> >> If I'm not mistaken, I think that the proposed charter makes provision
> >> 
> >> >for exactly that happening. If enough data points are gathered through
> >> >the work of the group, it can decide to re-charter and crack open the
> >> >spec itself. We'll just want to be sure that it's a data-driven decision
> >> >rather than something more theoretical.
> >> >
> >> >Does that hit close to what you're looking to achieve?
> > 
> > No.  The latest draft excludes such work from consideration without
> > rechartering.  It pretty much the opposite of what I was looking to
> > achieve.
> > 
> > Unless working on the base draft is part of the work of the working group,
> > it won't happen.
> 
> Scott,
> 
> We've done multiple queries to the community, for a listing of work to
> be done.  There's currently no community desire to work on the base
> specification.
> 
> While you've made your own desire clear, there is no evidence of
> community support for the change you want.
> 
> It makes no sense to charter a working group to change a specification,
> when there is no community desire to change it.  Indeed, the IETF does
> not typically charter a group to do work when there is no support for
> doing the work and, in fact, no list of the work to be done.
> 
> If there is a serious problem discovered with the current base
> specification, the community will want it fixed.  At that point, getting
> rechartering is likely to be pretty easy, since it will have specific
> focus, rather than being open-ended.

I think it's buggy in one way I've already described, but since it both 
doesn't affect existing IETF RFCs (and this is suitable for independent 
submission) and replaces the policy aspects of SPF and DKIM/ADSP (so it's not 
architecturally buggy), I'm sure it's fine.

Scott K