Dear Wayne,
	During the IESG's last meeting, the group considered your
message, your draft, and the drafts which were sent in related to Sender-ID.
We have approved all of the drafts as Experimental RFCs with the IESG note
you have previously seen.  Our aim in doing so is to get public specifications
for two systems for which there are implementations and deployments on
the Internet.  As the note says, we are not endorsing one system over the 
other or attempting to push for consensus at this time; we hope that 
some consensus on the value of these mechanisms may emerge over time.
Your message asked several questions about the IESG's thinking on
these documents; what follows is intended to elucidate our thinking
on some of the points you raised. 
	Your message asked several related questions about
the use of v=spf1 in the two draft sets.  You asked whether removing
the language from your draft limiting the use of these records would
speed processing.  This a bit of a moot point, since these are now approved,
but, to be clear, the IESG is not asking for any changes to your draft.
The language you have recommending limitations on the interpretation of 
v=spf1 will stay.  We also are not asking for any changes to the Sender-ID drafts. 
Since it depends on an earlier version of your draft from which there have been substantive changes, some
references to sections of your draft which no longer 
exist will be cleaned up in AUTH48, but its language will otherwise remain the
same.  The conflicts between the two on this and other points are part of
why the IESG is publishing them "AS IS".
	You also asked whether the IESG had a position on the re-use
of v=spf1 records.  Several members of the IESG were concerned about
the records being used in incompatible ways.  Given the history of MARID,
it is clear that both groups using the records can claim that at various points 
in history their interpretation was considered correct; even after the drafts'
expiration there remain widely distributed documents 
(e.g. http://spf.pobox.com/senderid.html) which describe the use of Sender-ID 
with v=spf1 records.  Had the working group come to a successful conclusion 
and established a standard, this would be a moot point; since it did not, we are 
left with the situation that different records put forward at different times may 
have been intended to mean different things.  The waters for v=spf1 are muddy 
now, in other words, and  the working group that muddied them failed before 
they could be cleared.  As  much as it might regret it, the IESG can't  fix 
the history here.
	You also asked us to consider how the rules of Section 5 of  RFC3932 
on sending a "Do Not Publish" to the RFC Editor might be taken to apply here.
There are two cases there.  The first describes a rejected alternative published later
than a working group standard (Photuris being the example).  We do not
believe it applies, since there is no working group standard and so there is no way to
judge when the second alternative could be published.  The second describes
the rejection of an experiment where the re-use of "free" bits was deemed
likely to cause hard-to-debug interoperability problems (reusing the high bits of 
fragment offset for another purpose being the example); in that case, there was 
a standard that established  the general purpose (fragment offset) and the
re-purposing was not salient.   Had either of the proposals before us now 
been standardized, then experimentation would clearly have to harmonize 
with the standard.   Unfortunately, this is not the case here, and we have to 
deal with the reality of multiple, competing proposals going forward in the market.
We don't believe the IETF has the power to stop that, and our ability to
influence it is restricted when we have ceased working on a standard.
Publishing the documents at least gets public, archival copies of both 
specifications into a form that is generally available to the Internet 
engineering community.  Hopefully, further engineering work can
proceed from there.
	We hope this clarifies things,
				regards,
					Ted Hardie
					for the IESG

PS.  For your ease of reference, the IESG Note is below; the document names
will be adjusted to RFC numbers by the RFC Editor when the numbers are
assigned.

"The following documents  (draft-schlitt-spf-classic, draft-katz-submitter, 
draft-lyon-senderid-core, draft-lyon-senderid-pra) are published simultaneously
as Experimental RFCs, although there is no general technical
consensus and efforts to reconcile the two approaches
have failed.  As such these documents have not received full IETF review
and are published "AS-IS" to document the different approaches as
they were considered in the MARID working group.

The IESG takes no position about which approach is to be preferred and
cautions the reader that there are serious open issues for each approach
and concerns about using them in tandem. The IESG
believes that documenting the different approaches does less harm
than not documenting them.

The community is invited to observe the success or failure of the
two approaches during the two years following publication, in
order that a community consensus can be reached in the future."