Subject: Re: [spfbis] Gen-ART Last Call review of draft-ietf-spfbis-4408bis-14

From: Scott Kitterman <[email-masked]>
Date: Tue, 21 May 2013 00:45:56 -0400

On Monday, April 29, 2013 10:14:28 AM S Moonesamy wrote:
> Hi Meral,
> 
> Thanks for the review.  I am forwarding it to the SPFBIS mailing list
> for discussion.  I'll email you in a few days to address your comments.
> 
> Regards,
> S. Moonesamy (as document shepherd)
> 
> At 08:53 29-04-2013, Meral Shirazipour wrote:
> >I am the assigned Gen-ART reviewer for this draft. For background on
> >Gen-ART, please see the FAQ at
> ><http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>http://wiki.tools.
> >ietf.org/area/gen/trac/wiki/GenArtfaq .
> >
> >Please resolve these comments along with any other Last Call
> >comments you may receive.
> >
> >Document: draft-ietf-spfbis-4408bis-14
> >Reviewer: Meral Shirazipour
> >Review Date: 2013-04-29
> >IETF LC End Date: 2013-04-30
> >IESG Telechat date: NA
> >
> >
> >
> >Summary:
> >This draft is almost ready to be published as Informational RFC but
> >I do have some comments.
> >
> >
> >Nits/editorial comments:
> >-[Page 6] Section "1.1.2.  Imported Definitions"
> >Please consider expanding acronyms and giving the section of the RFC
> >where each term is defined.
> >(Also throughout the document it would greatly help the readability
> >if acronyms are expanded when first used.)

Done to the extent I found issues.  ABNF was expaned in 4.6.1 and I moved the 
expansion up to 1.1.2.  If anyone notices any missing, please point them out.

> >
> >-[Page 8] Section 2.2. Line 1:
> >""MAIL FROM" -> extra \"

Fixed.

> >-[Page 13], Section 3.3. , first line: "sections 3.3.14 and 3.3".
> >If both subsection and subsubsection are to be mentioned, please
> >consider: "sections 3.3 and 3.3.14"

Fixed.

> >-[Page 16], Section 4.3, paragraph 1, last sentence: extra text/typo
> >to be removed: "on 2.3 of [RFC5890]."

Fixed.

> >-[Page 16], Section 4.4, paragraph 3,"[RFC2308] suggests on an"
> >--remove "on"--> "[RFC2308] suggests an"

Text removed due to other comments.

> >-[Page 21], Section 5.1, line 1,
> >"This section defines two types of mechanisms." --for clarity-->
> >"This section defines two types of mechanisms: basic and designated
> >sender."

I now have:
>    This section defines two types of mechanisms: basic language framework
>    mechanisms and designated sender mechanisms.

> >-[Page 21], second paragraph before last, " both "AAAA" and "A"
> >secords "--typo--> "records"

Fixed.

> >-[Page 22], Section 5.2, point 3, please review  "include:
> >mechanism" and "\"fail ".
> >Suggestion: instead of "gives a pass" or "gives a fail" is it better
> >to say "signifies" or "represents" as pass/fail?

I went with "produces".

> >-[Page 22], second paragraph before last,
> >"Only the evaluated result of the referenced SPF record is used,
> >rather than acting as if the referenced SPF
> >record was literally included in the first."
> >The part after the comma in this sentence is hard to understand.
> >Please review if possible.

I agree it's convoluted (it's also unchanged from RFC 4408).  Here's what I 
came up with.  Is this better?

> Only the evaluated result of the referenced SPF record is used, rather than
> literally including the mechanisms of the referenced record in  the first.

> >-[Page 24], Section 5.4,
> >"the evaluation terminated"--missing is-->"the evaluation is terminated"
> >"has no MX records"--no s-->"has no MX record"

Fixed.

> >-[Page 26], first paragraph,
> >"and more reliable alternatives used instead"---->"and more reliable
> >alternatives should be used instead"

Fixed.

> >"still in use and part of"---->"still in use as part of"

Fixed.

> >-[Page 29], paragraph 3,
> >"is generally be"---->"will generally be"

Fixed.

> >-[Page 30], paragraph 1,
> >"such as shown in Section 2.6.4",- is this pointing to the correct section?

No.  The text got moved when the WG reorganized the document, but the 
reference wasn't updated.  I've fixed it now.

> >-[Page 30], last sentence
> >"Note: During recursion into an "include" mechanism, an exp= modifier
> >
> >    from the <target-name> MUST NOT be used.  In contrast, when executing
> >    a "redirect" modifier, an exp= modifier from the original domain MUST
> >    NOT be used.
> >
> >"
> >Is it possible to add 1-2 sentence to explain why?(what is the
> >expected consequence if this is not respected)

Here's what I added:

> This is because "include" is meant to cross administrative boundaries and
> the explanation provided should be the one from the receiving ADMD, while
> "redirect" is meant to operate as a tool to consolidate policy records
> within an ADMD an so the redirected explanation is the one that ought to
> have priority.

> >-[Page 32], line 3,
> >"p = the validated domain name of <ip> (do not use)"
> >Is it possible to add a reference to section 5.5 which explains why?
> >Suggested: "(do not use, see Section 5.5)"

In the details about the macros below, it says "This macro SHOULD NOT be used 
(see Section 5.5 for the discussion)."  I think this is sufficient.

> >-[Page 33], third paragraph before last
> >"was provide more than once"---->"was provided more than once"

Fixed

> >-[Page 34], last "Note":
> >"....for as long as the shortest Time To Live (TTL) of all the DNS
> >records involved."
> >Please review this sentence ending. It is not clear.
> >Suggestion: "as long as the DNS record involved with the shortest
> >TTL has not expired" ?

Done.  Thaks.

> >-[Page 36], sentence 2, "Terse definitions"--typo-->"The definitions"

Fixed.

> >-[Page 36], paragraph 2,"be explicity"--typo-->"be explicitly"

Fixed.

> >-[Page 36], Section 8.1,"checked idenity"--typo-->"checked identity"

Fixed.

> >-[Page 37], Section 8.4, "the 5.7.1 enhanced status code", with
> >reference to RFC3463.
> >For better clarity please consider adding reference to Section 3.8
> >of the RFC3463.

Added.

> >-[Page 38], Section 8.6,
> >For better clarity please consider referring to Section 3.5 of RFC3463

Added.

> >-[Page 38], Section 8.8,
> >For better clarity please consider referring to Section 3.6 of RFC3463

Added.

> >-[Page 39], Section 9 Title, "Recording The Result"---->"the"

Done.

> >-[Page 44], Line 2, "carefully weight"---->"carefully weigh"

Fixed.

> >-[Page 44], Section 10.1.2, ""ip4" and "ip6" over "a" or "a" or "mx"."
> >The last part should suggest "mx' over "a" or the reverse?

It should suggest "a" over "mx" and if I change the last or to over, it does.

> >-[Page 46], Section 10.3 "User actor.[RFC5598]."---->"User actor
> >[RFC5598]."

Fixed.

> >-[Page 47], before last sentence, missing closing
> >parenthesis:"(defined in Section 4.6.4."

Fixed.

> >-[Page 49], Section 11.5.3, "It is necesary"--typo-->"It is necessary"

Fixed.

> >-[Page 62], line 2, "to implmentation"--typo-->"to implementation"

Fixed.

> >-[Page 62], second bullet before last, "Section 10 and Appendices D
> >- H below.", is this part of the sentence refering to anything, below?

It's referring to the new information in section 10 and appendicies D - H.

> >-[Page 65], Section E.3, "Receving ADMDs"--typo-->"Receiving ADMDs"

Fixed.

> >-[Page 66], last line, "mitiate"--typo-->"mitigate"

Fixed.

> >-[Page 68], one line before last, "reliabilility"--typo-->"reliability"

Fixed

> >-[Page 70], paragraphe 2,
> >"techincal"--typo-->"technical"
> >"deplyment"--typo-->"deployment"

Fixed.

> >-[Page 72], line 7, "obslete"--typo-->"obsolete"

Fixed.

> >-[Page 72], 2 line before last, "text and figures from Alessandro
> >Vesely", is it only to section 9.1, or 10.1.1. as well?

It was 10.1.1, but the figure's been removed due to other comments, so I'll 
adjust.

> >-[Page 73], "Added new section 9 discussion on treatment of
> >bounces", is it section 9 or section 10.1.3?

10.1.3.

> >-[Page 73], 1 line before last, "potental"--typo-->"potential"

Fixed.

> >-Appendix J., please review the 'section references' pointing to
> >various changes.

Did this.
> >
> >
> >-Throughout the draft, DNS "look up"---->"lookup"

Fixed.

> >-Throughout the draft, DNS RCODEs are mentioned without any
> >reference to RFC1035 (or RFC6195)

I added a reference to 1035 in 4.3, which is the first place RCODEs are 
mentioned.

> >-Throughout the draft, many cross references break the follow. I
> >suggested revisiting some of them and adding a small text after each
> >reference which introduces that section.
> >Example :[Page 17], Section 4.6.2 "the result is specified in
> >Section 4.7", suggested-->"the result is specified in Section 4.7
> >where Default results are discussed"

This particular one has been changed based on other comments.

> >-"Section 2.6 Results of Evaluation" lists the possible outputs of
> >check_host().
> >Then "Section 8.  Result Handling" continues the description with
> >handling guidance.
> >To avoid breaking the flow, please consider moving the descriptive
> >content of Section 2.6 into Section 8. (unless there is another
> >reason to keep them far apart).

As Murray replied already, they are separated for a reason that has the rough 
consensus of the group (as far as I can tell).  We've made some adjustments 
that should help.

Thanks for the detailed review.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Mon, 20 May 2013 22:55:48 -0700

Hi Meral,

Thanks for the detailed review.  I am forwarding the 
response.  Please let me know if the Gen-ART review has not been addressed.

Regards,

>_______________________________________________
>spfbis mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/spfbis

---

From: Meral Shirazipour <[email-masked]>
Date: Tue, 21 May 2013 19:35:38 +0000

Hi,
  Yes, thank you

Best Regards,
Meral

-----Original Message-----
From: S Moonesamy [mailto:[email-masked]] 
Sent: Monday, May 20, 2013 22:56
To: Meral Shirazipour
Cc: Scott Kitterman; [email-masked]; [email-masked]
Subject: Re: [spfbis] Gen-ART Last Call review of draft-ietf-spfbis-4408bis-14
Importance: High

Hi Meral,

Thanks for the detailed review.  I am forwarding the response.  Please let me know if the Gen-ART review has not been addressed.

Regards,

> > >I am the assigned Gen-ART reviewer for this draft. For background 
> > >on Gen-ART, please see the FAQ at 
> > >Please consider expanding acronyms and giving the section of the 
> > >RFC where each term is defined.
>Done to the extent I found issues.  ABNF was expaned in 4.6.1 and I 
>moved the expansion up to 1.1.2.  If anyone notices any missing, please point them out.
>
> > >
> > >-[Page 16], Section 4.3, paragraph 1, last sentence: extra 
> > >text/typo to be removed: "on 2.3 of [RFC5890]."
>
>Fixed.
>
> > >Suggestion: instead of "gives a pass" or "gives a fail" is it 
> > >better to say "signifies" or "represents" as pass/fail?
>
>I went with "produces".
>
> > >-[Page 22], second paragraph before last, "Only the evaluated 
> > >result of the referenced SPF record is used, rather than acting as 
> > >if the referenced SPF record was literally included in the first."
>I agree it's convoluted (it's also unchanged from RFC 4408).  Here's 
>what I came up with.  Is this better?
>
> > Only the evaluated result of the referenced SPF record is used, 
> > rather than literally including the mechanisms of the referenced record in  the first.
>
> > >-[Page 24], Section 5.4,
> > >"and more reliable alternatives used instead"---->"and more 
> > >reliable alternatives should be used instead"
>
>Fixed.
>
> > This is because "include" is meant to cross administrative 
> > boundaries and the explanation provided should be the one from the 
> > receiving ADMD, while "redirect" is meant to operate as a tool to 
> > consolidate policy records within an ADMD an so the redirected 
> > explanation is the one that ought to have priority.
>
> > >-[Page 32], line 3,
>In the details about the macros below, it says "This macro SHOULD NOT 
>be used (see Section 5.5 for the discussion)."  I think this is sufficient.
>
> > >-[Page 33], third paragraph before last "was provide more than 
> > >once"---->"was provided more than once"
>
>Fixed
>
> > >-[Page 34], last "Note":
>It was 10.1.1, but the figure's been removed due to other comments, so 
>I'll adjust.
>
> > >suggested revisiting some of them and adding a small text after 
> > >each reference which introduces that section.
>As Murray replied already, they are separated for a reason that has the 
>rough consensus of the group (as far as I can tell).  We've made some 
>adjustments that should help.
>