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

Phillip Hallam-Baker <hallam@gmail.com> Thu, 30 May 2013 20:00 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285F721F9273; Thu, 30 May 2013 13:00:44 -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 8fOgwDXBvjwQ; Thu, 30 May 2013 13:00:43 -0700 (PDT)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9026221F9354; Thu, 30 May 2013 13:00:41 -0700 (PDT)
Received: by mail-wi0-f175.google.com with SMTP id hn14so56458wib.14 for <multiple recipients>; Thu, 30 May 2013 13:00:40 -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=aSF2ZcxNSEk8B6AEsM9NOfE/qPv9AH94fljFEeidwSM=; b=eFyS0wE3TXYdzhybVIdyJTK3obyfpIlfzY1H/xW0VDFlMinWb/rXl+GqXoMgj2TSou wurHhlMuOdz1S9JR9wG3S1GzS8upOieJymwNLBfsDfNegG/7CFU/9EUOiSQ1Umw2U8VW dNCPCwqnxaeFzIn+MbmMONj24rrZ0iUQakWkxERUci8ZWdmKy+k81e4k/9ThCW48wcJ1 JH9QkhRfHVWqKy0EbhsSlBpouDOfUrzNbtRkqblvqi2gPQoInMot26BfeiBv6fKDgCpy zIBCHM5e85zG//nzH+im/syuwyyplAC5UXO4vTqE8zCWGRv5Gtyl1VkgC3VBSZ4INNhv C76w==
MIME-Version: 1.0
X-Received: by 10.194.172.66 with SMTP id ba2mr6394781wjc.22.1369944040627; Thu, 30 May 2013 13:00:40 -0700 (PDT)
Received: by 10.194.44.100 with HTTP; Thu, 30 May 2013 13:00:40 -0700 (PDT)
In-Reply-To: <6.2.5.6.2.20130523120130.0de4f6e0@elandnews.com>
References: <CAMm+LwjoH77H9cRQseQF09rDLwjtViZW_tGp71v0-WaZujoYtA@mail.gmail.com> <6.2.5.6.2.20130523095247.0dc5a520@elandnews.com> <7E10E46C-D524-41F2-9546-09DC7E3426A1@gmail.com> <6.2.5.6.2.20130523120130.0de4f6e0@elandnews.com>
Date: Thu, 30 May 2013 16:00:40 -0400
Message-ID: <CAMm+Lwj_jkMDk8X2GsNgRXMmuKJRnDN6+eKd4-Py5Wu6Pmsp9w@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: S Moonesamy <sm+ietf@elandsys.com>
Content-Type: multipart/alternative; boundary=089e01184dd4e766c804ddf4f3c1
Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, "secdir@ietf.org" <secdir@ietf.org>, Douglas Otis <doug.mtview@gmail.com>, "iesg@ietf.org" <iesg@ietf.org>
Subject: Re: [secdir] [spfbis] draft-ietf-spfbis-4408bis-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 May 2013 20:00:44 -0000

My point was a quibble, no more. The intent was clear enough to me and it
is hard to imagine an implementer of code making a blunder if their code is
timing out too often on real records they will raise their limits. A person
writing records might however.

I can see that attempting to clarify this point might add more confusion as
John Levine pointed out. In fact that was the main concern I had with the
document as a whole. I think it is done as well as it is going to be at
this point.


On Thu, May 23, 2013 at 3:14 PM, S Moonesamy <sm+ietf@elandsys.com> wrote:

> Hi Doug,
>
> At 11:58 23-05-2013, Douglas Otis wrote:
>
>> Greater clarity would have been achieved by separating transactions
>> involving the SPF checkhost process (spfch-transactions) which may then
>> generate some number of recursive dns server transactions
>> (rdns-transactions).
>>
>> A transaction made at the spfch level will result in some number of
>> transactions at the rdns level, which could then be described as
>> representing some number of separate DNS queries.
>>
>> Confusion has been caused by conflating checkhost and recursive DNS
>> transactions with that of non-recursive DNS which may involve dozens of
>> unique queries to resolve any particular resource.  This is bad and is a
>> continuing source of confusion.
>>
>
> What I noted among other things in the review was "the only quibble" and
> "it is reasonably clear".
>
>
>  A practical means to simplify SPF's impact on a receiver's DNS is to
>> first ignore SPF records containing macro expressions.  This happens and
>> this may explain the nearly 100% lack of macro use.  They then limit the
>> number of SPF resource records and MX mechanisms and ignore the PTR
>> mechanism.  Appreciate what receivers consider a reasonable demand on their
>> resources that offers cache-able results.
>>
>
> I don't see any relation between the security directorate review (
> http://www.ietf.org/mail-**archive/web/spfbis/current/**msg03679.html<http://www.ietf.org/mail-archive/web/spfbis/current/msg03679.html>) to the above (quoted paragraph).  If the security directorate reviewer is
> of the opinion that it is related to his review I will ask the SPFBIS to
> comment about the matter.
>
>
> Regards,
> S. Moonesamy (as document shepherd)
>



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