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)