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

Dave Crocker <> Thu, 18 April 2013 21:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F2D7821F8782 for <>; Thu, 18 Apr 2013 14:03:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a6iVeMiFBbTh for <>; Thu, 18 Apr 2013 14:03:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0840D21F859A for <>; Thu, 18 Apr 2013 14:03:42 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id r3IL3fJk020277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Apr 2013 14:03:41 -0700
Message-ID: <>
Date: Thu, 18 Apr 2013 14:03:37 -0700
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Scott Kitterman <>
References: <> <4299196.YodGhlyJ6a@scott-latitude-e6320> <> <5158537.VifRbVZBdl@scott-latitude-e6320>
In-Reply-To: <5158537.VifRbVZBdl@scott-latitude-e6320>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 ( []); Thu, 18 Apr 2013 14:03:41 -0700 (PDT)
Subject: Re: [apps-discuss] Revised DMARC working group charter proposal
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Apr 2013 21:03:43 -0000

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.


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 

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.


  Dave Crocker
  Brandenburg InternetWorking