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

[S Moonesamy <[e-mail]>]

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)