Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14

Andrew Sullivan <ajs@anvilwalrusden.com> Wed, 29 May 2013 20:21 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: spfbis@ietfa.amsl.com
Delivered-To: spfbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC9021F9776 for <spfbis@ietfa.amsl.com>; Wed, 29 May 2013 13:21:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.84
X-Spam-Level:
X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311]
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 S899Rr2TBIwC for <spfbis@ietfa.amsl.com>; Wed, 29 May 2013 13:21:53 -0700 (PDT)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBDC21F9763 for <spfbis@ietf.org>; Wed, 29 May 2013 13:21:51 -0700 (PDT)
Received: from mx1.yitter.info (nat-01-mht.dyndns.com [216.146.45.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id F0FCF8A031 for <spfbis@ietf.org>; Wed, 29 May 2013 20:21:49 +0000 (UTC)
Date: Wed, 29 May 2013 16:21:45 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: spfbis@ietf.org
Message-ID: <20130529202145.GA9506@mx1.yitter.info>
References: <A022755E-F8B8-4C82-9F1C-73B8585193BF@gmail.com> <6.2.5.6.2.20130528130858.0db81cd0@resistor.net> <CAL0qLwan7JO4t2UB1uWYwwf1MmwhY56szenSY7awT_pNP5UjLg@mail.gmail.com> <B6A88D56-9318-40A3-8E0C-A49EE37A3F3F@gmail.com> <20130529143635.GZ23227@verdi> <CD0B53CE-E90E-4296-B724-0749361D7626@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CD0B53CE-E90E-4296-B724-0749361D7626@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14
X-BeenThere: spfbis@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SPFbis discussion list <spfbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spfbis>, <mailto:spfbis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/spfbis>
List-Post: <mailto:spfbis@ietf.org>
List-Help: <mailto:spfbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spfbis>, <mailto:spfbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 May 2013 20:21:59 -0000

I'm not sure whether I'm wearing any hat here.  

On Wed, May 29, 2013 at 12:58:17PM -0700, Douglas Otis wrote:
> 
> The WG had little problem deprecating SPF Resource Records, which
> actually enjoyed greater and growing use.  Clearly, this WG is not
> vested in preserving DNS.
> 
> However, efforts expended in creating a DNS based macro language and
> associated compilers makes it difficult for those vested in SPF
> macros to admit failure.  Such reluctance is understandable.

This analogy is, in my personal opinion, invidious.  

The reason the WG decided to deprecate the SPF RRTYPE is because RFC
4408 has an actual interoperability problem in it.  You may recall
that SM and I originally ruled that deprecation of the SPF RRTYPE was
_out_ of scope, on the grounds that it was "used".  Our interpretation
of "used" was that, if there was any evidence of deployment on the
network, then the feature was not unused, and therefore it was beyond
the scope of the WG's charter to deprecate the feature.  I think the
charter is crystal clear about this matter.  This decision was
appealed to the AD, who agreed with us (though not about the crystal clarity).

The only reason we decided that we had to do something with TYPE 99
was simply that there turned out to be an interoperability problem.
We had to do something backward-incompatible _no matter what_, so we
determined at that point that we should deprecate the least-used
RRTYPE.

In order to deprecate macros the same way, we would need some argument
as to why it would be acceptable to violate our charter in that way.
Otherwise, since there are some people using macros, they are still
used so we have to maintain them.

Best,

A


-- 
Andrew Sullivan
ajs@anvilwalrusden.com