Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments
draft-ietf-spfbis-experiment-11

IANA has reviewed draft-ietf-spfbis-experiment-09, which is currently in Last Call, and has the following comments:

IANA has a question about this document.

IANA understands that there are no IANA actions requested in this document.

However, in Section 2 of the draft there is that statement:

"The term "RRTYPE" is used to refer to a Domain Name System ([DNS]) Resource
Record (RR) type. These are always expressed internally in software as numbers,
assigned by IANA under Expert Review provisions. Assigned RRTYPEs also have
names. The two of interest in this work are the TXT RRTYPE (16) and the SPF
RRTYPE (99)."

IANA believes that this is not consistent with the assignment policy as
documented in the Resource Record (RR) TYPEs subregistry of the Domain
Name System (DNS) Parameters located at:

http://www.iana.org/assignments/dns-parameters

Do the authors intend a change to the registration policies for DNS RRTYPEs?

Once again, IANA understands that there are no IANA Actions for this document. However, IANA would like to clarify the language in the draft in Section 2.

We understand that this document doesn't require any IANA actions.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Resolution of The SPF and Sender ID Experiments) to Informational RFC


The IESG has received a request from the SPF Update WG (spfbis) to
consider the following document:
- 'Resolution of The SPF and Sender ID Experiments'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-06-09. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  In 2006 the IETF published a suite of protocol documents comprising
  SPF and Sender ID, two proposed email authentication protocols.  Both
  of these protocols enable one to publish via the Domain Name System a
  policy declaring which mail servers were authorized to send email on
  behalf of the domain name being queried.  There was concern that the
  two would conflict in some significant operational situations,
  interfering with message delivery.

  The IESG required the publication of all of these documents (RFC4405,
  RFC4406, RFC4407, and RFC4408) with Experimental status, and
  requested that the community observe deployment and operation of the
  protocols over a period of two years from the date of publication to
  determine a reasonable path forward.

  After six years, sufficient experience and evidence have been
  collected that the experiments thus created can be considered
  concluded.  This document presents those findings.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-spfbis-experiment/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-spfbis-experiment/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) The type of RFC being requested is Informational. The draft documents
    the resolution of the SPF and Sender ID Experiments. The type is
    indicated in the title page header.

(2) The approval announcement contains the following sections:

Technical Summary

In 2006 the IETF published a suite of protocol documents comprising
SPF and Sender ID, two proposed email authentication protocols with
Experimental status. After six years, sufficient experience and
evidence have been collected that the experiments thus created can
be considered concluded. This document presents those findings.

Working Group Summary

The SPFBIS working group had a difficult task ahead as it was not clear
how to conclude the SPF and Sender ID Experiments and how to address
the IESG Notes in RFC 4405, RFC4406, RFC4407, and RFC4408. There were
discussions about how to proceed. Only one proposal was submitted and
it was adopted by the working group.

The discussions about the RRTYPE 99 DNS Resource Record were controversial.
The issue was resolved. There was consensus that Sender ID re-use of
SPF DNS Resource Records does not have to be called out in the document.

This document represents a best effort by the SPFBIS working group to
conclude the experiments which were documented in the above-mentioned
RFCs.

Document Quality

The document does not specify a protocol. The document was reviewed by the
SPFBIS working group. Barry Leiba, as an individual, and Dave Crocker
performed a thorough review of the document.

Personnel

S. Moonesamy is the Document Shepherd for this document. Pete Resnick
is the Responsible Area Director.

(3) I have personally reviewed draft-ietf-spfbis-experiment-09. Even though
    the milestone for the draft is August 2012, given that it has achieved
    the goals set forth in the SPFBIS working group charter, I believe that
    the draft is reading for forwarding to the IESG for publication.

(4) This document has been reviewed by at least five SPFBIS WG participants.
    The document has also been reviewed by Andrew Sullivan. I do not have
    any concerns about the depth and breath of the reviews performed.

(5) The document will also be reviewed by Alexey Melkinov on behalf of
    the Applications Area Directorate.

(6) I do not have any specific concerns or issues with the document.

(7) The author confirmed that any and all appropriate IPR disclosures
    required for full conformance with the provisions of BCP 78 and
    BCP 79 have already been filed.

(8) There are no IPR disclosures referencing this document.

(9) The WG as a whole understand and agree with the document. It has
    WG consensus.

(10) Nobody has threatened an appeal or otherwise indicated extreme
    discontent during the WGLC.

(11) Id-nits lists an error in Appendix A due to a SHOULD and the
    absence of a reference to RFC 2119. The reference is not
    necessary.

(12) The document does not require any formal review.

(13) All references within this document been identified as either
    normative or informative.

(14) The document normatively references RFCs.

(15) As the intended document status is Informational, the normative
    references to Experimental RFCs are not downward references.

(16) The publication of this document does not change the status of any
    existing RFCs.

(17) No IANA action is requested. This is clearly indicated in the
    IANA Considerations Section.

(18) The document does not make use of any IANA registries.

(19) The document does not contain any formal language.