Re: [dmarc-ietf] Charter improvements

Dave Crocker <dcrocker@gmail.com> Fri, 19 July 2013 02:10 UTC

Return-Path: <dcrocker@gmail.com>
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 BECFB21E818A for <dmarc@ietfa.amsl.com>; Thu, 18 Jul 2013 19:10:56 -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 jABv8qu66a7t for <dmarc@ietfa.amsl.com>; Thu, 18 Jul 2013 19:10:55 -0700 (PDT)
Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 79CAF21E815C for <dmarc@ietf.org>; Thu, 18 Jul 2013 19:10:53 -0700 (PDT)
Received: by mail-oa0-f42.google.com with SMTP id j6so5220131oag.1 for <dmarc@ietf.org>; Thu, 18 Jul 2013 19:10:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=V/VM5IQyP83nZk7xembOVQGcYzFfVeYL+A/x1evKpCw=; b=wY8c6wAHtxRYb/yljkURC4jH4uw6ZYqkvXkgiJSOMhTsfVheajQrdeqFZ4YC50KLEI OUXl32AjovUeOJlW5AUXFq/AxFGQTvKtj/2gjB2DDasXuUWWfHYayVEmNDUozYibU7yW WmPLSmtQN1/mgUacyju7kNwi3/z38EeIbZViKttRBiu4rh6wYOMZd+pHemWhqV7TxUps 63lUQUqgNhm9kdlfErujOEtXTkn2Xu2Mc2QHs/DOyVZtp2PC8XXf2gpac++0heR37bsG blrmXZD4dRqVhSTkiSpiBXGTm0oKjFXIqBWuTxv14FwiHP9AjL02ox8mIHt1lhVDUV2Z pm8w==
X-Received: by 10.182.144.163 with SMTP id sn3mr10593771obb.1.1374199851958; Thu, 18 Jul 2013 19:10:51 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id o8sm18733325obx.11.2013.07.18.19.10.49 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Jul 2013 19:10:50 -0700 (PDT)
Message-ID: <51E8A003.2010901@gmail.com>
Date: Thu, 18 Jul 2013 19:10:11 -0700
From: Dave Crocker <dcrocker@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Barry Leiba <barryleiba@computer.org>
References: <20130702052746.15876.qmail@joyce.lan> <51D3464D.2060502@sonnection.nl> <0A91244B-1CAE-491A-865B-E2BA64AFB366@tnpi.net> <51E56928.4020207@gmail.com> <b5b7a2e5-b650-494c-913e-a43d2d73f5d7@email.android.com> <51E5A667.50503@gmail.com> <CAC4RtVBWpHkJ_K447-2YnPrupfBkdHKeNFkP4=pA91+zZPJDUw@mail.gmail.com>
In-Reply-To: <CAC4RtVBWpHkJ_K447-2YnPrupfBkdHKeNFkP4=pA91+zZPJDUw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "dmarc@ietf.org" <dmarc@ietf.org>, Scott Kitterman <sklist@kitterman.com>
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 02:10:56 -0000

On 7/18/2013 11:25 AM, Barry Leiba wrote:
> 1. For the BoF, let's work on using the time productively, starting
> with the assumption that something fairly close to the currently
> published DMARC spec is where we jump off from.

Let me press the distinction between 'editorial' document changes, 
versus changes to the bits over the wire.  With that distinction in 
mind, I believe that the BOF can start with the assumption that there 
will be no changes to bits over the wire.

This is always subject to change, but there's now an extended history of 
it's being true.

So the 'fairly close' is the editorial content of the latest draft.


> 2. For the DMARC spec, let's please have more of the IETF community
> review the document, specifically responding to the questions of (a)
> what technical changes are needed in it, and (b) whether it should be
> published as a Standards Track specification.

We have a review sequence lined up.  We suspended it after the first two 
because the call for editorial changes was strong enough and for enough 
change to make it worth letting further reviewers benefit from what we 
believe will be significantly improved readability.

FWIW, whatever queue of reviewers we've lined does not, should not, and 
of course will not, preclude anyone else from offering their own review. 
  More is better.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net