Re: [dmarc-ietf] Charter improvements

Roland Turner <raz@raz.cx> Fri, 19 July 2013 09:25 UTC

Return-Path: <raz@raz.cx>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C92F11E80F8 for <dmarc@ietfa.amsl.com>; Fri, 19 Jul 2013 02:25:28 -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 qwiY2D6JNGdw for <dmarc@ietfa.amsl.com>; Fri, 19 Jul 2013 02:25:20 -0700 (PDT)
Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) by ietfa.amsl.com (Postfix) with ESMTP id 68ACF11E80F6 for <dmarc@ietf.org>; Fri, 19 Jul 2013 02:25:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=raz.cx; s=20120325; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=eD7DTkN2uHZMVFCIRtsizb1h8Hci+JnsBCq3fl0JCT0=; b=IvRh7GlDOPJdo+kpSBhY634LVGqbx9uAFYVGVAjpa+/hcnbq8epCGAiyiqw3Ul17T+eW5uKrfjH6bskytor3s0pzmah+FEU8zbpbR6Pz4Fo6PlLe5DoteUc0RgpjsTjATSHR2sJUiTbWizcQyIqP225ZLXS8kLkJcMXqL3oUVXE=;
X-raz.cx-addressbook: match raz@raz.cx
Received: from [116.12.149.133] (port=54850 helo=[10.100.1.133]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from <raz@raz.cx>) id 1V06wA-0001LQ-GX; Fri, 19 Jul 2013 09:25:18 +0000
Message-ID: <51E905FD.7090602@raz.cx>
Date: Fri, 19 Jul 2013 17:25:17 +0800
From: Roland Turner <raz@raz.cx>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: "J. Trent Adams" <jtrentadams@gmail.com>
References: <20130702052746.15876.qmail@joyce.lan> <51D3464D.2060502@sonnection.nl> <0A91244B-1CAE-491A-865B-E2BA64AFB366@tnpi.net> <51E56928.4020207@gmail.com>
In-Reply-To: <51E56928.4020207@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "dmarc@ietf.org" <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] Charter improvements
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmarc>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jul 2013 09:25:29 -0000

On 07/16/2013 11:39 PM, J. Trent Adams wrote:

>  From what I can tell, the most important question needing to be answered
> is whether or not revising the base DMARC specification is within scope
> of the proposed work group. Following Russ's guidance, it seems that we
> should start from the assumption that it's not in scope for now given
> the fact that it's being sponsored by an AD as an Individual Submission.
>
> Regardless of whether that's the right path, or not, let's explore it as
> an option and see how the rest of the items identified in the proposed
> charter play out. Then we can leverage the outcome of the conversation
> to potentially revisit the fate of the base specification itself.

I would suggest that this is a problematic approach because of the 
effective need that this creates for the charter discussion to correctly 
predict what the WG will come up with. The WG should work out what the 
WG comes up with, and should have as broad a remit as is feasible (give 
or take IETF process constraints) to do so. This is not to say that 
there should not be a recital acknowledging that the substantial 
installed base will necessarily limit changes - probably to nothing - 
but that seeking to constrain the WG's approach now, rather than during 
it, is likely to be harmful.

I'm thinking particularly about what happened recently with respect to 
the SPF macro facility and the fact that the discussion on removing it 
turned not on whether removing the facility was appropriate, but on 
whether the particular words chosen during chartering meant that this 
was, or was not, a permissible change for the WG to make.

- Roland