[apps-discuss] DMARC and the conflict of extensions vs. deployment

Paul Hoffman <paul.hoffman@vpnc.org> Sat, 13 April 2013 14:13 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id BF2D921F8556 for <apps-discuss@ietfa.amsl.com>; Sat, 13 Apr 2013 07:13:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id FTdyiOO85Npf for <apps-discuss@ietfa.amsl.com>; Sat, 13 Apr 2013 07:13:56 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 07E8D21F8550 for <apps-discuss@ietf.org>; Sat, 13 Apr 2013 07:13:56 -0700 (PDT)
Received: from [] (50-1-98-173.dsl.dynamic.sonic.net []) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r3DEDqdq044186 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <apps-discuss@ietf.org>; Sat, 13 Apr 2013 07:13:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com>
Date: Sat, 13 Apr 2013 07:13:52 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <980EF5BE-EE46-4D93-BD85-2A991C93BD35@vpnc.org>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com>
To: IETF Apps Discuss <apps-discuss@ietf.org>
X-Mailer: Apple Mail (2.1503)
Subject: [apps-discuss] DMARC and the conflict of extensions vs. deployment
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Apr 2013 14:13:57 -0000

The initial charter for this working group does not include revising the base specification, but rather producing incremental extensions to it. However, if resolving any of the issues listed in the areas of focus below does require changes to the base specification, or if the specification needs to be revised to correct technical errors deemed essential for proper use, the group will recharter accordingly.

To me, this says "the WG should produce incremental extensions where needed". However:

At the time of chartering, DMARC has already achieved an estimated coverage of 60% of the Internet's mailboxes. Consequently, any extensions or revisions that create software or operations incompatibilities with this significant installed base need to be considered carefully. The strong preference is for the working group to preserve existing software and procedures. For changes likely to affect the installed base, the working group will actively seek to include developers and operators of DMARC-based mechanisms outside the core set of working group participants in its consensus discussions.

To me, that says that the WG cannot produce an incremental extension because existing software and procedures would have to be updated.  That statement seems to include even the listed milestones. For example, I cannot see how to make DMARC work with mailing lists without changing software and/or procedures. Similarly, even if there is agreement on transitive trust agreements will change procedures significantly.

If the people proposing the charter want a WG that extends the base spec, the latter paragraph needs to be removed. If the people proposing the charter want a WG that does not change the software and operations currently deployed, the first paragraph needs to be remove, and make it clear that the WG's only deliverables are the implementation and deployment guide and practices guides from later in the charter.

Having both paragraphs in the charter leaves the WG participants not knowing what it is they can do, and yet that knowing is exactly why the IETF has charters.

Assuming that the people proposing the charter really want the limitations from the second quote above (which seems likely), I propose that the WG not be formed. Forming a WG with limitations that are imposed from outside the IETF will cause the waste of hundreds or thousands of IETF participant hours. The phrase "needs to be considered carefully" is a call to endless debates about what "carefully" means and who ultimately gets to be the careful considerers who count.

The main proponents of the private DMARC spec are already active IETF participants. They can recruit the rest of us to join the private DMARC work effort without wasting a lot of IETF time on helping a private effort. They can send mail to AppsArea when they want people to join their private discussions on extensions to DMARC. They can (and should!) update people at the face-to-face IETF meetings. They can (and should!) publishing the results of their private efforts as RFCs through the ISE; that's a great use of the ISE track of RFCs. But trying to have an IETF WG-that-isn't-really-a-WG seems wasteful of valuable resources.

Note: if I'm wrong above and the people proposing the charter ditch the restrictions of the second quote, the charter still needs more work, namely adding a sentence or two to each deliverable about what is expected of those extensions.

--Paul Hoffman