Re: [secdir] [spfbis] draft-ietf-spfbis-4408bis-14
S Moonesamy <sm+ietf@elandsys.com> Thu, 23 May 2013 19:54 UTC
Return-Path: <sm@elandsys.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 5670B21F8F6D; Thu, 23 May 2013 12:54:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.407
X-Spam-Level:
X-Spam-Status: No, score=-102.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 tNb1mVWB4vTD; Thu, 23 May 2013 12:54:00 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 120D521F97EE; Thu, 23 May 2013 12:15:50 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.224.155.5]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r4NJFTlB011947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 May 2013 12:15:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1369336543; bh=A4gR+4J5IGaopWkzi5DjRnhEq3Rjks54l68so2KH6u4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=MzS0e1ZjgN2XYKChaLLkx/BCc8gfIo0T62Iq2UZlK5go0d3++TTUKFxiH528wA/bE SvX9axZyn1PX3BJ6VrzamOs7s7S+cnyaZNxHSiBs9VhTi4AAKYH0LU94cvrROSC3TS 8v3n8whQZCJMAApTBQUhpjQhRw+jFwTQUBydiV4c=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1369336543; i=@elandsys.com; bh=A4gR+4J5IGaopWkzi5DjRnhEq3Rjks54l68so2KH6u4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=pWIoThYLaq3G+Lmepcd3BXyGwcw+lmCmpFbnsZqrhHhmwT2NVAxfUV9YzTWWypeo/ pvbh2nl8RTob1muF9O2mDbvTtCB/gIs2AUBvJCaSca7DQALvrfVjckJMTqfH1WCkVr pyHQ4GDaanSmVwQOCIJnCXFXoYRrHJZXz7iRyfvI=
Message-Id: <6.2.5.6.2.20130523120130.0de4f6e0@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 23 May 2013 12:14:32 -0700
To: Douglas Otis <doug.mtview@gmail.com>
From: S Moonesamy <sm+ietf@elandsys.com>
In-Reply-To: <7E10E46C-D524-41F2-9546-09DC7E3426A1@gmail.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>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, iesg@ietf.org, secdir@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, 23 May 2013 19:54:32 -0000
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 ) 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)
- [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