[spfbis] Review of draft-ietf-spfbis-experiment-05

[Barry Leiba <[e-mail]>]

Here's a review of experiment-05.  Some of these comments are purely
editorial, but some address the tone of the document, the tendency to
deprecate Sender ID, and general issues of pronouncements and opinions.
 Please seriously consider addressing those: I don't think such
pronouncements, opinions, and bias are in place in this document (see my
first comment below).

-- Abstract --

OLD
   After six years, sufficient experience and evidence have been
   collected that the experiment thus created can be considered
   concluded, and a single protocol can be advanced.  This document
   presents those findings.

I would prefer that this document avoid making pronouncements and stating
these kinds of opinions ("a single protocol can be advanced").  The point
of this draft is to document results.  The actual SPFbis doc will do the
advancement of SPF.  It would be better if statements about the fate of
Sender ID be left for other granfalloons.  I suggest ending the sentence
with "concluded".

Note that RFC 4406 uses "Sender ID", with a space and no dash (except in
the IESG Note).  Please use that orthography consistently here.

-- Introduction --

OLD
   The two protocols made use of this policy
   statement and some specific (but different) logic

NEW (clarity, even though "same" is in the next paragraph)
   The two protocols made use of this same policy
   statement and some specific (but different) logic

OLD
   Due to the absence of consensus behind one or the other, and because
   Sender-ID supported use of the same policy statement defined by SPF,
   the IESG at the time was concerned that an implementation of
   Sender-ID might erroneously apply that statement to a message and,
   depending on selected recipient actions, could improperly interfere
   with message delivery.

This seems to have a significant SPF bias.  May I suggest this?:

NEW
   Due to the absence of consensus behind one or the other and because
   SPF and Sender-ID supported use of the same policy statement with
   different semantics, the IESG at the time was concerned that
   implementations of SPF or Sender-ID might erroneously apply a
   statement that had been published with the semantics of the other,
   and, depending on selected recipient actions, could improperly
   interfere with message delivery.

OLD
   It is important to note that this document makes no direct technical
   comparison of the two protocols in terms of correctness, weaknesses,
   or use case coverage.  The email community at large has already done
   that.

I suggest "has already done that through its deployment choices."
 Otherwise, one might wonder where the comparison that's been done is
documented.

-- Analysis --

OLD
   2.  Of the records retrieved, fewer than 3% requested processing of
       messages using the PRA algorithm, which was an essential part of
       Sender-ID.

I suggest "which is an essential part of Sender ID."  There seems no reason
for past tense.

OLD
   3.  Although the two mechanisms often used different email addresses
       as the subject being evaluated, no data collected showed any
       substantial operational benefit (e.g., cheaper processing,
       improved accuracy) to using Sender-ID over SPF.

I suggest "to using either mechanism over the other."

-- Conclusions --

OLD
   It is standard procedure within the IETF to document as standard
   those protocols and practices that have come into sufficient common
   use as to become part of the basic infrastructure.

This seems unnecessary and out of place.  I suggest removing it.

OLD
   In light of the this and the analysis in the previous section, the
   following conclusions are supported:
NEW
   In light of the analysis in the previous section, the
   following conclusions are supported:

OLD
   1.  The experiment comprising the series of RFCs defining the
       SUBMITTER SMTP extension, the Sender-ID mechanism, the Purported
       Responsible address algorithm, and SPF, should be considered
       concluded.

Citations for all have appeared earlier, but I think it would be helpful to
put RFC citations for them here... consider it an excutive summary.  This
is one of the problems with the choice of non-RFC-based citation tags.  I
suggest this, which uses parentheses instead of citations:

NEW
   1.  The experiment comprising the series of RFCs defining the
       SUBMITTER SMTP extension (RFC 4405), the Sender-ID mechanism
      (RFC 4406), the Purported Responsible address algorithm (RFC 4407),
       and SPF (RFC 4408), should be considered concluded.

OLD
   3.  The absence of significant adoption of the [SUBMITTER] extension,
       [SENDER-ID], and [PRA], indicates that there is not a strong
       community prepared to develop those mechanisms beyond
       experimental status.

I would MUCH rather see this reported factually, without further opinion.
 Something like this:

NEW
   3.  The absence of significant adoption of the [SUBMITTER] extension,
       [SENDER-ID], and [PRA], indicates that there is not a strong
       community deploying and using these protocols.

OLD
   4.  Continued widespread use of [SPF] indicates it is worthy of
       consideration for the Standards Track.

I suggest this:
NEW
   4.  [SPF] has widespread implementation and deployment, comparable
       to that of many Standards Track protocols.

-- Security Considerations --

OLD
   This document contains information for the community, akin to an
   implementation report, and does not introduce any new security
   concerns.  Its implications could, in fact, resolve some.

That last sentence seems odd.  Unless you want to be specific about it, I
suggest removing it.

-- Informative References --

We can always argue whether an Informational document, by its nature, can
have "normative" references.  Still, in the sense that we use it here,
references that are central to the understanding of the document at hand
are usually considered to be normative.  DNS is arguable, but I'd say no.
 I think the references to PRA, SENDER-ID, SPF, and SUBMITTER are normative.

-- Appendix A.  Experiences Developing SPF --

This is really about the RR type issue, not about SPF in general.  I
suggest saying that in the section title.  Maybe, "Background on the RR
Type Issue", or some such.

--
Barry