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

Barry Leiba <barryleiba@computer.org> Sun, 22 April 2012 20:58 UTC

Return-Path: <barryleiba.mailing.lists@gmail.com>
X-Original-To: spfbis@ietfa.amsl.com
Delivered-To: spfbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9B821F85AA for <spfbis@ietfa.amsl.com>; Sun, 22 Apr 2012 13:58:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level:
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FeOdpqLucXe for <spfbis@ietfa.amsl.com>; Sun, 22 Apr 2012 13:58:24 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id E9CAC21F85A1 for <spfbis@ietf.org>; Sun, 22 Apr 2012 13:58:23 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so6740659ghb.31 for <spfbis@ietf.org>; Sun, 22 Apr 2012 13:58:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=4QFUS+70PCjGcRRQRhsY+cTgVI9rLykQFXNnSzP3JtI=; b=vLtmvplF0uKUj739Ql0sMyHswFqRku+OuoV38jmkAx3yeNwUIqIDiR1dyOuJFnjuo1 lXh4vquUa9JcK6iMbm946YMZuYjVc47ipe7HSDz1u7F5WOAbYStVKogpW6gYCIgMNkii IhAAB/M0fstL0xN0QL/eiKvk5RE6/g0BK9Q7ad0ysqaIoFfgThCzslcOVKp9fX6syo66 tzsFyjV3ixqc7o3GBFGZyFHp0gYjIq8m7NE5STQAOLzTYQ+zusHofybeCcFJZo1zOCq6 51TTIp2Gzy7jn8HOaY41jNWJk+egfQJN+nQKrHsxKLkxNff7N7uNtt75QBhMZZ3NeyQd h3ug==
MIME-Version: 1.0
Received: by 10.101.175.37 with SMTP id c37mr3889122anp.59.1335128303385; Sun, 22 Apr 2012 13:58:23 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.147.152.14 with HTTP; Sun, 22 Apr 2012 13:58:23 -0700 (PDT)
Date: Sun, 22 Apr 2012 16:58:23 -0400
X-Google-Sender-Auth: O8x6kHVZb1oa8G-DDRZG5CVU32Y
Message-ID: <CAC4RtVAV5PH+VMzppVxAQgGq0f28ARN846e17G_8sbLCThm-KA@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: "spfbis@ietf.org" <spfbis@ietf.org>
Content-Type: multipart/alternative; boundary=001636c5bb7740bad204be4ac8eb
Subject: [spfbis] Review of draft-ietf-spfbis-experiment-05
X-BeenThere: spfbis@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SPFbis discussion list <spfbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spfbis>, <mailto:spfbis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/spfbis>
List-Post: <mailto:spfbis@ietf.org>
List-Help: <mailto:spfbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spfbis>, <mailto:spfbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 22 Apr 2012 20:58:25 -0000

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