Last Call Review of draft-ietf-spfbis-experiment-
review-ietf-spfbis-experiment-genart-lc-carpenter-2012-06-08-00

Please see attached review.


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>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-spfbis-experiment-09.txt
Reviewer: Brian Carpenter
Review Date: 2012-06-06
IETF LC End Date: 2012-06-09
IESG Telechat date: 

Summary:  Almost ready
--------

Comment:
--------

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?

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"? 

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.)

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

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].

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.

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.