Re: [apps-discuss] [spfbis] APPSDIR review of draft-ietf-spfbis-4408bis-14.txt

S Moonesamy <sm+ietf@elandsys.com> Thu, 23 May 2013 22:14 UTC

Return-Path: <sm@elandsys.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6242221F983A; Thu, 23 May 2013 15:14:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.424
X-Spam-Level:
X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 KxkYBpRtD8s6; Thu, 23 May 2013 15:13:55 -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 3363C21F983F; Thu, 23 May 2013 14:29:26 -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 r4NLT3sq023426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 May 2013 14:29:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1369344557; bh=As6zUMYor+zZ+QsTkoyPdRn0q9Mxwl/6xDreWazDfxs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=1lpVVjwEEkAuyz9dQqe0/bGGLykFYMdtfLCQO6MinKJ9HifKgjjTSqnYHBbwAYxhI IbLhSnELESL1RKe2Ls2/43Yq7OEWsGpMOUO/zfOpWvu39eiO7PaxX2nqyOv2Gqk5Ft WPlEOegQotWcd0QM9xWVYzmutg502dL/4ZF4n4qc=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1369344557; i=@elandsys.com; bh=As6zUMYor+zZ+QsTkoyPdRn0q9Mxwl/6xDreWazDfxs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ilUG9Cee+Flp6pMGrsWke0E/U909+4+H+95eR5g9UA/weQND+S7h1oZWLV99qFa2x KhXsCcj71AsG70Hg4RvzKQ6494v9KnDAwIy4r1kNhNRuvgclrZYXLUa5UI8GPV7Aj9 5tuaNLfWIz41mZn6//T3NIEUzMY5ZkAKJIDDp7bk=
Message-Id: <6.2.5.6.2.20130523142426.0daf25c8@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 23 May 2013 14:28:31 -0700
To: Cyrus Daboo <cyrus@daboo.name>
From: S Moonesamy <sm+ietf@elandsys.com>
In-Reply-To: <1778285.8glKQALeLt@scott-latitude-e6320>
References: <6.2.5.6.2.20130429065657.0d392368@elandnews.com> <1778285.8glKQALeLt@scott-latitude-e6320>
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, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [spfbis] APPSDIR review of draft-ietf-spfbis-4408bis-14.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 May 2013 22:14:06 -0000

Hi Cyrus,
At 13:22 23-05-2013, Scott Kitterman wrote:
>On Monday, April 29, 2013 07:05:57 AM S Moonesamy wrote:
> > >Document: draft-ietf-spfbis-4408bis-14.txt
> > >Title: Sender Policy Framework (SPF) for
> > >Authorizing Use of Domains in Email, Version 1
> > >Reviewer: Cyrus Daboo
> > >Review Date: 2013-04-29
> > >
> > >Summary: This draft is almost ready for
> > >publication as an RFC, subject to some minor issues that should be
> > >resolved.
> > >
> > >Overview: This document is an update to RFC4408
> > >that seeks to upgrade the specification from
> > >experimental status, clarifying a number of
> > >issues in the original specification, providing
> > >in depth detail of actual deployment experience,
> > >and documenting various extensions now in common
> > >use. The new draft achieves these aims and
> > >provides a good reference for implementors.
> > >
> > >Major Issues: None
> > >
> > >Minor Issues:
> > >         Section 4.6.1 ABNF terms "A / MX / PTR
> > > / IP4 / IP6" are upper case but terminal terms
> > > are lower case in Section 5 (but uppercase in
> > > Appendix A). Looks like these need fixing in Section 5.
>
>I think we should lower case them all and I've done that for the 
>next revision
>in both 4.6.1 and Appendix A.  It makes things more consistent overall.
>
> > >         Section 6.2 Paragraph 6 There is a
> > >
> > > reference to Section 2.6.4 but that section
> > > does not contain anything relevant. Either
> > > remove the reference or point to a relevant section.
>
>Corrected to point to 8.4.  This was a casualty of a reorganizing the
>document.
>
> > >         Section 7.1 Paragraph 2 States "subject
> > >
> > > to LDH rule" - that needs a reference to
> > > RFC3696 Section 2 (reference was in RFC 4408).
>
>Is this not sufficient:
>
>    The "toplabel" construction is subject to the LDH rule plus
>    additional top-level domain (TLD) restrictions.  See Section 2 of
>    [RFC3696] for background.
>
> > >Section 11.3 Why no mention of DNSSEC as a way
> > >to alleviate this issue? Has anyone been using
> > >DNSSEC with SPF? If not, why not?
>
>I think this is covered by the reference to RFC 3833, but if someone has a
>suggestion for more explicit text, please provide it.
>
> > >Nits:
> > >         Section 2.4 (argument list) and Section
> > >
> > > 4.1 appear to duplicate similar information -
> > > consider removing the list of args in Section 2.4 and add a reference to
> > > $4.1.>
>
>Done.
>
> > >         Section 2.5 Paragraph 2 First part of
> > >
> > > sentence hard to read - break it up with commas.
>
>I agree with the comment, but I'm not sure where to put them without changing
>the meaning.
>
> > >         Section 2.6 and Section 8 appear to
> > >
> > > duplicate a lot of similar information. Please
> > > consider trimming down Section 2.6 and have it
> > > refer to Section 8 for full details.
>
>Done.
>
> > >         Section 3.5 Paragraph 1 Has the word
> > >
> > > "discouraged". Shouldn't this use a 2119 term, e.g.: "NOT RECOMMENDED"?
>
>Probably, but it is discouraged in RFC 4408 and we're trying to be careful
>about introducing new 2119 requirements.
>
> > >         Section 6.1 Paragraph 1 Remove second
> > > sentence - pretty much the same as the first one.
>
>Done.
>
> > >         Section 6.2 Paragraph 4 Put exp in double-quotes.
>
>Done.
>
> > >         Section 10 Paragraph 1 SHOULD - in this
> > > context it is not really appropriate to use a 2119 term. Please rephrase.
>
>Changed.
>
> > >         Various places: permerror is sometimes
> > > used without double-quotes around it - I think
> > > all uses should have double-quotes.
>
>Changed.

Do the above comments address your AppsDir review ( 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09353.html )?

Thanks,
S. Moonesamy (as document shepherd)