In <p06210201bee857110d85@[10.0.0.31]> Ted Hardie <hardie <at> qualcomm.com> writes:

> 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.

Thank you!

>           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.

Again, the note talks about using these two systems "in tandem".  This
is not the problem.  People can use both SPF and SenderID in tandem,
what causes problems is the conflicting use of v=spf1 records which
happens when *anyone* *anywhere* follows the SenerdID specifications.

> 	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.

Thank you for clearing this up.

>                    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".

I am disappointed by this decision and I think the SPF leadership
council will have to discuss how to proceed from here.

> 	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;

Personally, I don't think specs that are in the process of being
developed hold much weight.  The SPF specification was declared
"frozen" in Dec 2003, and the SPF-classic I-D is largely compatible
with that spec.  (Yes, further revisions were made to the SPF spec in
early 2004, but then both the SPF implementations and SPF spec really
froze.)

To be clear, during much of the MARID process, *I* thought that the
re-use of v=spf1 records was fine, but it was only after several cases
where the re-use would cause problems that I changed my mind.  I think
a review of the MARID discussions rarely showed the opinion that we
(the MARID participants) were creating a new record, but rather that
we were re-using established records in a compatible way.

About the same time that the MARID WG became convinced that the re-use
was not compatible and declared that SenderID MUST use a new record
number, I also became convinced.

This is all about technical issues.

> [...]                                                 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.

Hummm, I thought I had removed all references to that web page, but
apparently not.  It is gone now.  Thanks for the bug report.  The SPF
community has only in the last few weeks been able to modify this
website.  Before then, it has remained almost unchanged for 6 months
and contained many obviously incorrect items.

POBox's web page on SenderID and related issues was created around Nov
10, 2004.  It was due to this and several other things that were going
on at the time, that the SPF community, as a whole, took a position.  See:
http://www.openspf.org/OpenSPF_community_position_v102.html 
http://openspf.org/cgi-bin/openspf_pledge.cgi

For a very long time, Meng Wong has supported the use of the PRA part of
SenderID for political reasons, not technical reasons.  Meng has said
many times that he thinks that the PRA is a bad idea and will fail in
the market.  A recent example can be found in the SPF council meeting
that triggered my request for IESG clarifications:

http://www.schlitt.net/spf/spf-council/2005/06/15_irc_log.html#20050615T2112

[note:  As the top of the webpage says, <freeside> is Meng, and I'm
<grumpy>.  Also, the following are excerpts and the order has been
re-arranged.  I'm sure anyone who has participated in
IRC/Jabber/etc. understands that a strict ordering is often misleading.]

http://www.schlitt.net/spf/spf-council/2005/06/15_irc_log.html#20050615T2125

On whether political considerations are more important than technical
problems, Meng said:

21:25   <freeside> ok, yes. so my position has always been, i think we
                   should get an RFC out, and whether it documents
                   spf-classic or marid-whatever is less important,
                   because the market will just say "ok, it's an RFC
                   number" and not look that much farther.

http://www.schlitt.net/spf/spf-council/2005/06/15_irc_log.html#20050615T2139

21:39   <freeside> frankly, at this point i think the overall utility of
                   getting a draft published sooner, that allows reuse,
                   is higher than the utility of not getting a draft
                   published, or getting it published months or years
                   later, that prohibits reuse.

21:40   <freeside> if we keep trying to prohibit reuse, the drafts will
                   just keep getting held off. if we allow reuse, the
                   drafts will go through. that is my feeling.

http://www.schlitt.net/spf/spf-council/2005/06/15_irc_log.html#20050615T2134

On whether Meng felt that the IESG would even allow him to change the
senderid-core I-D to prohibit the re-use of v=spf1 records:

21:34   <freeside> well, it sounds to me like if we want the IESG to
                   publish our draft, we have to accommodate the IESG.

21:36   <freeside> regarding the reuse of v=spf1, i don't think they'll
                   listen to me any more than they'll listen to anyone
                   else on here.

21:38   <freeside> i'll try to have a conversation with ted hardie and
                   see what he thinks.

21:38   <freeside> but frankly, it seems to me that the IESG will be
                   much quicker to approve a draft that allows for
                   reuse.

21:38     <grumpy> freeside: can't you just change the draft?

http://www.schlitt.net/spf/spf-council/2005/06/15_irc_log.html#20050615T2156

21:56     <grumpy> freeside: why can't SID have something like a
                   "spf2.0/pra redirect-spfv1=%{d}" to indicate that the
                   reuse is ok?
21:56     <grumpy> or "spf2.0/pra redirect=%{d}/spfv1"
21:57     <grumpy> doesn't this allow the re-use under a technically
                   correct method?
21:57 <csm-laptop> freeside?
21:57   <freeside> mmm
21:58 <csm-laptop> grumpy asked you a direct ?
21:58   <freeside> sure, that could work, but i don't think that's what
                   MS and the IESG want.

21:58   <freeside> i'm really suggesting that the most important thing
                   right now, tactically, is to get an rfc published.
21:59   <freeside> they want to be able to reuse it, and you don't want
                   reuse, and so there's not much point to continued
                   discussion.
21:59   <freeside> the IESG is going to have to arbitrate.
21:59     <grumpy> ok, does the IESG want to reuse?
21:59   <freeside> i think so.
21:59     <grumpy> Hmmmm.
21:59     <grumpy> Ok.
21:59 <csm-laptop> why?
21:59     <grumpy> well, instead of making freeside guess what the IESG
                   thinks, I think we should just ask the IESG.
21:59   <freeside> i could be wrong, but that seems to be consistent
                   with what ted's been outputting, no?
22:00     <grumpy> it isn't consistent with what sam has said
22:00   <freeside> well, i think grumpy is right.
22:00   <freeside> i saw a great fortune cookie the other day:
                   "ignorance never settled any questions."

So, if, as you have pointed out in your message, the IESG is not
*requiring* the re-use of v=spf1 records by SenderID, then much of
what Meng's position was based on falls away.

Again, however, the arguments for re-using v=spf1 records in
incompatible ways is all about politics, and not about technical
issues.

Is the IESG an engineering organization, or a political one?

>                                             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.

While the IESG can not fix history, the IESG *can* recognize the
technical and engineering issues and not bless the use of existing
records in an incompatible way.

> 	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.
> [...]
>                                 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.

Again, I disagree that SPF had not been standardized.  The standard
had not been published by the IETF, but I hope that the IESG
recognizes more standards than just RFCs.

> 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.

Again, I think the SPF community will need to discuss what steps to
take next.  Personally, I am deeply disappointed that the IESG appears
to be ignoring technical and engineering considerations.

-wayne