Re: [Gen-art] Gen-ART LC review of draft-ietf-spfbis-experiment-09.txt

[S Moonesamy <[e-mail]>]

Hi Brian,
At 03:36 06-06-2012, Brian E Carpenter wrote:
>Please see attached review.

Thanks for the review.

>I think the Conclusions and Appendix A are almost entirely correct.
>
>Major issues:
>-------------
>
>IMHO section 3.1 needs several clarifications:
>
>"These surveys selected substantial sets of distinct domain names..."
>
>Were these exclusively domain names with MX records?

They're domain names seen on incoming email in some way.  Murray 
doesn't believe that it is important to state that.  If you think it 
is important, let me know.

>Also in section 3.1 there are several tables like:
>
>     "+------------------+-----------+-------+
>      | Domains queried  | 1,000,000 |   -   |
>      | TXT replies      |   397,511 | 39.8% |
>      | SPF replies      |     6,627 | <1.0% |
>      | SPF+TXT replies  |     6,603 | <1.0% |
>      | spf2.0/* replies |     5,291 | <1.0% |
>      +------------------+-----------+-------+"
>
>It is not explained what is meant by "TXT replies" and "SPF+TXT replies".
>
>Does "TXT replies" mean *any* kind of TXT record, or only TXT records that
>start with "v=spf"?

It's a fair question.  The draft will be updated to fix that.

>Does "SPF+TXT replies" mean that both an SPF and a TXT record exists for these
>FQDNs? If so, are they identical? (Presumably they should be.)

Yes to the first question.  The working group didn't evaluate the second.

>At the moment I can't fully understand the significance of the results.
>
>Also, RFC4406 states that "Sending domains MAY publish either or both formats"
>(i.e. spf1 or spf2.0). That being so, I would ideally expect to see nine rows
>in the results table:
>
>SPF RR only, spf1 only
>SPF RR only, spf2.0 only
>SPF RR only, spf1 and spf2.0
>TXT RR only, spf1 only
>TXT RR only, spf2.0 only
>TXT RR only, spf1 and spf2.0
>SPF and TXT RRs, spf1 only
>SPF and TXT RRs, spf2.0 only
>SPF and TXT RRs, spf1 and spf2.0

Pete suggests having two tables for each survey: (a) a comparison of 
RRTYPEs, and (b) a comparison of SPF vs. SIDF independent of 
RRTYPE.  Would that be sufficient?

>It's possible that some of these are always zero but there is no way 
>for a reader
>to tell. This relates to the breakage in the SPF transition plan 
>that the draft
>points out (Appendix A, bullet 4).
>
>Finally, in Appendix A we find:
>
>   "Fortunately in the intervening time, the requirements for new RRTYPE
>    assignments was changed to Expert Review, and the posture has become
>    more relaxed."
>
>This is slightly inaccurate. Actually the policy has been changed to
>RFC6195, which is a modified form of Expert Review. I suggest something
>less opinionated:
>
>    Fortunately in the intervening time, the requirements for new RRTYPE
>    assignments was changed to be less stringent [RFC6195].

This is slightly inaccurate.  Actually the policy has been changed to 
RFC6195, which is a modified form of Expert Review. Murray suggests 
something less opinionated:

   Fortunately in the intervening time, the requirements for new RRTYPE
   assignments was changed to be less stringent [RFC6195].

>Nits
>----
>
>"9.1.  Normative References
>
>    [DNS]      Mockapetris, P., "Domain names - implementation and
>               specification", STD 13, RFC 1035, November 1987.
>
>    [PRA]      Lyon, J., "Purported Responsible Address in E-Mail
>               Messages", RFC 4407, April 2006."
>
>Firstly, it's quite inconvenient having references like this
>instead of [RFC1035] etc.

Here's Andrew's response as WG Chair:  This isn't a change anyone 
needs to make, it's a style complaint.  The editor preferred to use 
the symbolic-reference style, and the reviewer prefers the RFC-named 
style.  He also personally prefer the latter, but the RFC Editor 
doesn't have a rule.

Murray finds the mnemonic method in use easier to read.

>Secondly, it doesn't seem right to have Experimental RFCs listed
>as normative references. In fact, since this draft is not a technical
>specification, I'm not sure it needs to have the Normative/Informative
>split at all.

Dave Crocker and Barry Leiba had an discussion about "normative 
references" at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg01426.html.

Even though the draft is not a technical specification, it is 
important that the reader reads the RFCs listed as normative to 
understand the draft.  The Experimental RFCs are not even a downward 
reference in this case as this draft is not being published on the 
Standards Track.

Regards,
S. Moonesamy (as document shepherd)