Re: [dmarc-ietf] Charter improvements

Dave Crocker <dcrocker@gmail.com> Tue, 02 July 2013 19:13 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 8037711E80F2 for <dmarc@ietfa.amsl.com>; Tue, 2 Jul 2013 12:13:17 -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=[AWL=0.000, 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 HFuZHmkrEurx for <dmarc@ietfa.amsl.com>; Tue, 2 Jul 2013 12:13:16 -0700 (PDT)
Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A1B2F11E80F8 for <dmarc@ietf.org>; Tue, 2 Jul 2013 12:13:10 -0700 (PDT)
Received: by mail-ie0-f173.google.com with SMTP id k13so12894328iea.4 for <dmarc@ietf.org>; Tue, 02 Jul 2013 12:13:08 -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=fqZggyowlT61igEuLkmoWFbWo1p/UkI+K5a0vJA+egY=; b=yj6GMRwEGUWCy2IW8vnsxEhSNXNFaTlb85xYjo8BYzDPC4HplH8wICUyY+2IuaQNSc ldtzuAuVyif+PpNDrCPHvZMk+gm5h5ukdzSv6MDHiiumErCUohymKp9xIQhLr7vEsVKO hyDjZF0tWSls4gUnd3UEh3SSFs/WFsXJgvm5j4/5R2vrVymA9kFYhgplMgYHBnsZBri8 aoeyKuRTF+GgIHblAYFdANP+WRtjNqoXvFZJQOZwT5xgnvm8e2xU9PuZC9uQi3IRY6oI s5H3PgAoqyBPQig/1yWc4pJej9lUHqqC+S3UaKkoz0ga5bs+jJIVaUNfH+0JnYgIEin9 KDpQ==
X-Received: by 10.50.112.5 with SMTP id im5mr22718785igb.23.1372792388726; Tue, 02 Jul 2013 12:13:08 -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 ff19sm19820074igb.0.2013.07.02.12.13.07 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Jul 2013 12:13:07 -0700 (PDT)
Message-ID: <51D32635.5090206@gmail.com>
Date: Tue, 02 Jul 2013 12:12:53 -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: John Levine <johnl@taugh.com>
References: <20130702185113.21926.qmail@joyce.lan>
In-Reply-To: <20130702185113.21926.qmail@joyce.lan>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: 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: Tue, 02 Jul 2013 19:13:17 -0000

On 7/2/2013 11:51 AM, John Levine wrote:
>>>> Replace the second and third paragraphs with:
>>>>
>>>>    The working group will adopt draft-kucherawy-dmarc-base as an input
>>>
>>> What is the work to be done on the base document?
>
> One final thought and then I'll stop: If you think that there is some
> chance of making progress on the first four charter items, it seems
> likely that the results of that progress would go into the base
> document.
>
> I suppose an alternative would be to send the base document through
> separately, then after it's published charter dmarcbis that would
> start with the RFC as an input, a highly compressed version of what
> spfbis is doing, but that seems like a lot of extra work for no
> benefit.


Your presumption is that it's necessary to make changes to the base 
document for these enhancements.  Mine is that it isn't.

So we don't need to wait.  We can proceed with the listed tasks now. If 
we find that we really do need to wait... we can.

Your approach imposes potentially unnecessary delay.  Mine doesn't.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net