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.