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

Paul Hoffman <paul.hoffman@vpnc.org> Sat, 13 April 2013 22:06 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C96121F8E72 for <apps-discuss@ietfa.amsl.com>; Sat, 13 Apr 2013 15:06:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 ujuyQ8jpVpGd for <apps-discuss@ietfa.amsl.com>; Sat, 13 Apr 2013 15:06:57 -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 65BF921F863C for <apps-discuss@ietf.org>; Sat, 13 Apr 2013 15:06:57 -0700 (PDT)
Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r3DM6pgP056057 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 13 Apr 2013 15:06:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <5169C79A.2050402@dcrocker.net>
Date: Sat, 13 Apr 2013 15:06:51 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <BC12EAE3-0A70-4769-A19F-0CAA5143EE69@vpnc.org>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com> <980EF5BE-EE46-4D93-BD85-2A991C93BD35@vpnc.org> <5169C79A.2050402@dcrocker.net>
To: dcrocker@bbiw.net
X-Mailer: Apple Mail (2.1503)
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [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 22:06:58 -0000

Thanks, this is very helpful, and may make the charter proposal much more palatable.

On Apr 13, 2013, at 2:01 PM, Dave Crocker <dhc@dcrocker.net> wrote:

> Normally, an "incremental extension" is taken to mean that it provides /additional/ capabilities that are not essential to core operation. (cf., smtp extensions or mime).

I would not say that is the "normal" definition of an incremental extension, but it is one that helps here. Given that, and the obvious distaste for revisions that would force changes in the deployed servers, would the following shorter paragraph be an acceptable replacement for the two paragraphs in question ("The initial charter..." and "At the time...")?

=====
The initial charter for this Working Group consists only of incremental extensions to the base specification.  An incremental extension is one that would allow an extended system to interoperate with an unextended system. This charter explicitly does not include revising the base specification. If creating any of the WG deliverables requires non-interoperable changes to the base specification, or if the specification needs to be revised to correct technical errors deemed essential for proper use, the group would need to recharter to revise the base specification in the specific areas needed.
=====

This wording removes the conflation of extensions and revisions in the current charter text, it removes sentences about why the WG should avoid rechartering, and makes it completely clear what the boundaries for the listed WG work items are.

Having said that, I think both the current text and my proposal above have a thorny constitutional problem: if the WG recharters to change a problem in the base specification, the WG would be working on an protocol that is an RFC that is outside the IETF Stream. I suspect that that should only be done if the result is bringing the revised base spec into the IETF Stream as an Standards Track document. But I think that issue can be noted here (not in the charter) and only raised if the recharter actually happens.

--Paul Hoffman