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

Dave Crocker <dhc@dcrocker.net> Sat, 13 April 2013 21:01 UTC

Return-Path: <dhc@dcrocker.net>
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 EF4A021F8D92 for <apps-discuss@ietfa.amsl.com>; Sat, 13 Apr 2013 14:01:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.562
X-Spam-Level:
X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 fxSw+bP7sogC for <apps-discuss@ietfa.amsl.com>; Sat, 13 Apr 2013 14:01:24 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1350F21F8D90 for <apps-discuss@ietf.org>; Sat, 13 Apr 2013 14:01:24 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r3DL1NbM029125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 13 Apr 2013 14:01:23 -0700
Message-ID: <5169C79A.2050402@dcrocker.net>
Date: Sat, 13 Apr 2013 14:01:14 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Paul Hoffman <paul.hoffman@vpnc.org>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com> <980EF5BE-EE46-4D93-BD85-2A991C93BD35@vpnc.org>
In-Reply-To: <980EF5BE-EE46-4D93-BD85-2A991C93BD35@vpnc.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 13 Apr 2013 14:01:23 -0700 (PDT)
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
Reply-To: dcrocker@bbiw.net
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 21:01:25 -0000

On 4/13/2013 7:13 AM, Paul Hoffman wrote:
> 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.


Speaking for myself only, of course, but...


That's an unexpected interpretation of the text.

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).

That is, whatever was original working will still work, albeit without 
whatever new and spiffy capabilities are specified in the incremental 
extensions.

By way of a marked contrast, cf. IPv4 vs. IPv6.

While I can certainly imagine a frame of mind that counts IPv6 as an 
"incremental extension" to IPv4, that frame of mind is certainly not the 
one intended for reading the draft charter.

To summarize:  the charter seeks to constrain work that might /force/ a 
change in the existing installed base, by virtue of creating an 
interoperability problem, rather than to necessarily constrain value-add 
enhancements that are optional.

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net