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/
- [secdir] draft-ietf-spfbis-4408bis-14 Phillip Hallam-Baker
- Re: [secdir] draft-ietf-spfbis-4408bis-14 S Moonesamy
- Re: [secdir] draft-ietf-spfbis-4408bis-14 S Moonesamy
- Re: [secdir] [spfbis] draft-ietf-spfbis-4408bis-14 S Moonesamy
- Re: [secdir] [spfbis] draft-ietf-spfbis-4408bis-14 Douglas Otis
- Re: [secdir] [spfbis] draft-ietf-spfbis-4408bis-14 Douglas Otis
- Re: [secdir] [spfbis] draft-ietf-spfbis-4408bis-14 Phillip Hallam-Baker