[dmarc-ietf] Alissa Cooper's Block on charter-ietf-dmarc-01-00: (with BLOCK and COMMENT)

Alissa Cooper <alissa@cooperw.in> Tue, 20 November 2018 21:03 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: dmarc@ietf.org
Delivered-To: dmarc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED688124D68; Tue, 20 Nov 2018 13:03:24 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper <alissa@cooperw.in>
To: The IESG <iesg@ietf.org>
Cc: dmarc-chairs@ietf.org, dmarc@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.89.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154274780493.29758.10284579659666859291.idtracker@ietfa.amsl.com>
Date: Tue, 20 Nov 2018 13:03:24 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/UverV9vGiT5M3O9WuA5u9Wwf_LM>
Subject: [dmarc-ietf] Alissa Cooper's Block on charter-ietf-dmarc-01-00: (with BLOCK and COMMENT)
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 20 Nov 2018 21:03:25 -0000

Alissa Cooper has entered the following ballot position for
charter-ietf-dmarc-01-00: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:


(1) I realize this re-charter is motivated by a small update, but it seems
confusing to maintain text that is out-of-date when publishing a re-charter.
Someone already pointed out the issue with RFC 7960; I would also argue that
the following change is needed:

The existing DMARC base specification has been submitted as an
   Independent Submission to become an Informational RFC.
The existing DMARC base specification has been published as RFC 7489 in the
Independent Stream.

(2) "Any issues related to the email authentication space ..." seems like a
rather broad charge. I understand the desire to work on
draft-levine-appsarea-eaiauth, but does that really justify this much wider
charter expansion? I feel like the point of the chartering process is to avoid
this kind of catch-all.


"2. Reviewing and improving the base DMARC specification

   The working group will not develop additional mail authentication
   technologies, but may document authentication requirements that are

It's not clear how documenting authentication requirements implies directly
improving the base specification.