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)
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
