On June 12, 2005 William Leibzon wrote:
<snip>
|Do you think that given above ideas about removing
|recommendation for "-all" publishing by domain owners and
|changing other identities statement to "MAY use PASS result
|and MUST NOT use FAIL result", this would have better
|chance of gaining consensus and subsequently getting
|standard status from IESG?
<snip>
First, let's just step back a moment. Rather than argue
about what the IESG did or did not mean when it closed
MARID, or why the decision was made, let's look at the
statement that was issued at that time:
|After an assessment of the current state of the MARID
|working group, its charter, and its milestones, the working
|group chairs and Area Advisor concluded that the MARID
|working group should be terminated.
|
|The group was originally chartered with a very tight time
|frame, with the expectation that a focused group of
|engineers would be able to produce in relatively short
|order a standard in the area of DNS-stored policies related
|to and accessible by MTAs. The group has had no lack of
|energy. From the outset, however, the working group
|participants have had fundamental disagreements on the
|nature of the record to be provided and the mechanism by
|which it would be checked. Technical discussion of the
|merits of these mechanisms has not swayed their proponents,
|and what data is available on existing deployments has not
|made one choice obviously superior. Each represents
|trade-offs, and the working group has not succeeded in
|establishing which trade-offs are the most appropriate for
|this purpose. These assessments have been difficult in part
|because they have been moved out of the realm of pure
|engineering by the need to evaluate IPR and licensing
|related to at least one proposal in the light of a variety
|of licenses associated with the deployed base of MTAs.
|
|Efforts to reach consensus by compromise and by inclusion
|have been attempted on multiple occasions. Despite early
|hopes of success after each such attempt, post-facto
|recycling of technical issues which these efforts should
|have closed has shown that the group remains divided on
|very basic issues. The working group chairs and Area
|Advisor are agreed that the working group has no immediate
|prospect of achieving its primary milestone:
|
|Aug 04 Submit working group document on MTA Authorization
|Record in DNS to PS
|
|Rather than spin in place, the working group chairs and
|Area Advisor believe that the best way forward is
|experimentation with multiple proposals and a subsequent
|review of deployment experience. The working group chairs
|and Area Advisor intend to ask that the editors of existing
|working group drafts put forward their documents as
|non-working group submissions for Experimental RFC status.
|
|Given the importance of the world-wide email and DNS
|systems, it is critical that IETF-sponsored experimental
|proposals likely to see broad deployment contain no
|mechanisms that would have deleterious effects on the
|overall system. The Area Directors intend, therefore, to
|request that the experimental proposals be reviewed by a
|focused technology directorate. This review group has not
|yet been formed but, as with all directorates, its
|membership will be publicly listed at
|http://www.ietf.org/u/ietfchair/directorates.html once it
|has been constituted.
|
|Concluding a group without it having achieved its goals is
|never a pleasant prospect, and it is always tempting to
|believe that just a small amount of additional time and
|energy will cause consensus to emerge. After careful
|consideration, however, the working group chairs and area
|advisor have concluded that such energy would be better
|spent on gathering deployment experience.
The first question then is what Internet Drafts were on the
table?
According to the Internet-Drafts Database Interface, the
I-Ds List for the Working Group, MTA Authorization Records
in DNS (marid) is as follows:
draft-ietf-marid-protocol-00
draft-ietf-marid-protocol-03
draft-ietf-marid-mailfrom-00
draft-ietf-marid-core-03
draft-ietf-marid-pra-00
draft-ietf-marid-rationale-00
draft-ietf-marid-submitter-03
<https://datatracker.ietf.org/public/idindex.cgi?command=show_wg_
id&id=1623>
The editors of these I-D drafts were invited to make
submissions. Draft-ietf-marid-protocol-03 replaced
draft-ietf-marid-protocol-00.
It is being suggested that sender policy framework was not
before marid.
With respect, the purpose of marid in considering
draft-ietf-marid-protocol-03 and
draft-ietf-marid-mailfrom-00 was to allow for consideration
of that part of the sender policy framework utilizing the
domain in the SMTP mail from as the host to check.
As such, based on the record, in my view the position that
sender policy framework was not before marid is without
merit.
In the alternative, it can be suggested, because these two
drafts did not fully incorporate what is now contained in
the sender policy framework drafts, which endeavours to
document all the myriad versions and usages, both as to
publishing records and host checks, it is therefore
appropriate for the IESG to consider
draft-schlitt-spf-classic-02.
That position seems to have been accepted by the IESG to
the extent that on 05/25/05 it declared
draft-lentczner-spf-00 dead.
Presently, the IESG has before it for evaluation purposes
the following:
draft-schlitt-spf-classic-02
- and -
draft-katz-submitter-01
draft-lyon-senderid-core-01
draft-lyon-senderid-pra-01
Now that the drafts have been "polished," the names of the
directorate constituted by the Area Directors to carry out
the focused technical review have been posted.
The SPF council in presenting draft-schlitt-spf-classic-02
is asking the IESG to consider that sender policy framework
as presented be considered for standard track based on the
position that the proposal is now stable and there is wide
spread deployment experience.
To my mind, there are two questions:
* Is the statement in the schlitt draft concerning the
recommended usage of SPFv1 records with any other protocol
appropriate?
The IESG in closing marid stated:
The working group chairs and Area Advisor intend to ask
that the editors of existing working group drafts put
forward their documents as non-working group submissions
for Experimental RFC status.
The existing working group drafts did not contain such a
recommendation, but rather proposed spf2.0 and defined
scopes for SMTP mail from and Purported Responsible
Authority, so avoiding the problem.
In draft-lyon-senderid-core-01 and
draft-lyon-senderid-pra-01 the editors have put forward
drafts which allow for backward compatibility with SPFv1
records.
However, presumably the editors of
draft-schlitt-spf-classic-02 are stating that based on the
evidence they have gleaned from the wide spread deployment
experience of SPFv1 to date, this would cause unacceptable
false positive levels and as such is not appropriate.
If credible and substantial evidence exists to support this
contention, then it should be presented to the IESG to
support the recommendation.
On the other hand, if the concern is theoretical and no
evidence exists of there being any risk of false positives,
especially in light of the claim of widespread deployment
experience, then there is no merit to the recommendation
within the framework of the request for consideration for
standard track or should this be declined, for approval of
the draft as an experimental RFC.
* What steps can the SPF council take to facilitate the
IESG in granting the present request to consider
draft-schlitt-spf-classic for standard track?
In my view, in deciding whether to accede to the SPF
council's present request, the IESG will want to consider
the comments by:
* The technical directorate after conducting their focused
technical review of draft-schlitt-spf-classic-02, subject
to any response by the editors of the draft; and,
* MAAWG based on draft-newton-maawg-spf-considerations-00,
or any revisions of that draft, as they can provide real
world input as to deployment experience.
Should the IESG decide draft-schlitt-spf-classic-02 (or any
revision, along with any lessons learned document) is
worthy of standards track, then from my perspective, given
the decision to close marid, the next step would be to
reconstitute marid and provide
draft-schlitt-spf-classic-02 (?), any lessons learned
document, along with the technical directorate report and
any reports from MAAWG as input documents, so allowing the
working group to quickly proceed with its work in moving
forward with a standard track proposal.
It is possible the IESG could decide to skip this step and
simply proceed forward by allowing the draft (with the
related documents) to proceed forward on the standard
track, subject to an Internet wide call for comment.
Do I think the IESG will accede to the Council's request?
As matters stand today, no.
Would it make a difference, if draft-schlitt-spf-classic
was modified to allow interoperability with
draft-lyon-senderid-core-01 and draft-lyon-senderid-pra-01,
based on the proposed changes that William is suggesting
being made to the respective drafts?
I acknowledge and respect the vehement concerns raised by
Frank.
Rather than speculate as to what might be the response of
the IESG, along with the editors of draft-lyon-senderid-core
and draft-lyon-senderid-pra, my suggestion would be to do
two things:
* Ask for input from the technical directorate;
* Sit down with Andy Newton and ascertain what
recommendations MAAWG has based on their field testing.
If the SPF Council and ultimately the community at large
can live with any suggested changes to meet the concerns of
the technical directorate, along with the recommendations
of MAAWG, then proceed forward. If not, don't bother.
Trusting this helps.
John
P.S. In an earlier post, Wayne asked if I had any contact
with Meng. I don't know this for certain, but given the
apparent conflict between the schlitt and lyon drafts and
as Meng is listed as an editor on both, I would suggest
that he has decided, as his work is done, the better course
is to simply stand clear and let the chips fall where they
may.