Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

Phillip Hallam-Baker <hallam@gmail.com> Mon, 02 September 2013 15:49 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFAC11E8102 for <ietf@ietfa.amsl.com>; Mon, 2 Sep 2013 08:49:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 4xanMSrzG6Ys for <ietf@ietfa.amsl.com>; Mon, 2 Sep 2013 08:49:16 -0700 (PDT)
Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id B1E3A11E80FD for <ietf@ietf.org>; Mon, 2 Sep 2013 08:49:15 -0700 (PDT)
Received: by mail-la0-f49.google.com with SMTP id ev20so3674685lab.22 for <ietf@ietf.org>; Mon, 02 Sep 2013 08:49:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iF3DUo1pjALi/Ca+x1mvjyT39mOXg+6MnKddXFiMU40=; b=WiYOQ0DsrMAx8lQchRErXGdnIAL0SnkB3ANSQvROa3IBm+Jgfqk9KtUqeYfOIe7y52 lyD/aQ74yaIuAkAr5tpp9aMKULCRnJTT21se/4tkfV5wY6bClIlmnYTZhZctsQjr4os8 qqa3BugeG20QcH9KwTvjvedLA9b+xBKgnDu60OmrjVbPX0pfeInifnqWJeS5YXBIiUQ7 NtvhTbTK2jf5fucDYcl+vwaqSriZLVYCbIOkBoaq/3Tyolkrq3XGP6Wux6qP0zrHKwFd brUA1PIQLrUwB3jqJKx7fgZMzpO3o8udIyDbig84ixu2qKkegJ6X3PDq/gAc9kJkzwkd 7BlQ==
MIME-Version: 1.0
X-Received: by 10.112.155.39 with SMTP id vt7mr2512982lbb.29.1378136954355; Mon, 02 Sep 2013 08:49:14 -0700 (PDT)
Received: by 10.112.148.165 with HTTP; Mon, 2 Sep 2013 08:49:13 -0700 (PDT)
In-Reply-To: <9A45A400-0378-4C36-BB3A-91BADA8A1C81@virtualized.org>
References: <20130902134703.19714.qmail@joyce.lan> <9A45A400-0378-4C36-BB3A-91BADA8A1C81@virtualized.org>
Date: Mon, 02 Sep 2013 11:49:13 -0400
Message-ID: <CAMm+LwgrnnAvxGf319=2VbLeFpLGw+97QuSfiEHWjvVhMkHXrg@mail.gmail.com>
Subject: Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
From: Phillip Hallam-Baker <hallam@gmail.com>
To: David Conrad <drc@virtualized.org>
Content-Type: multipart/alternative; boundary="089e0112c1369dc54404e5688349"
Cc: John Levine <johnl@taugh.com>, IETF Discussion Mailing List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2013 15:49:16 -0000

On Mon, Sep 2, 2013 at 9:56 AM, David Conrad <drc@virtualized.org> wrote:

> John,
>
> > Either that or figure out how to make it easy enough to deploy new
> > RRTYPEs that people are willing to do so.
> >
> > The type number is 16 bits, after all.  We're not in any danger of
> running out.
>
> We have been told on numerous occasions that one of the primary reasons
> for continued use of TXT is because middleboxes, etc., do not allow new RR
> types (something deprecation of the SPF RR would seem to only encourage).
> The number of bits in the type field would not seem to be particularly
> relevant to this.
>
> Regards,
> -drc
>


Which is a problem that I think can only be solved if there is a general
solution of the policy distribution problem and an expectation that at
least new middle boxen will support it.

I have been pushing for some sort of 'Internet 2.0' branding for equipment
that meets a comprehensive set of nextgen needs, i.e. IPv6, port
forwarding, DNSSEC, border policy enforcement for that very reason.


But it has to be a two way street. The reason DNS Choices fell flat is that
it just told people what not to do to solve their problems, it did not
provide a proposal that actually solved their problems.


-- 
Website: http://hallambaker.com/