In <200512081357(_dot_)19429(_dot_)julian(_at_)mehnle(_dot_)net> Julian Mehnle
<julian(_at_)mehnle(_dot_)net> writes:
Wayne Schlitt wrote:
Julian Mehnle <julian(_at_)mehnle(_dot_)net> writes:
We should examine the wording of that IESG note...
| [snip] Participants publishing SPF experiment DNS records should
| consider the advice given in section 3.4 of RFC XXXX (draft-lyon-
| senderid-core) and may wish to publish both v=spf1 and v=spf2.0
| records to avoid the conflict.
Did anyone notice that they said "v=spf2.0"? Oh my. Is that the best they
could come up with after almost four months since the appeal was filed?
no, I missed that. *splorf*
After all, none the IESG notes accounts for the fact that "the SPF
experiment" was there _way_before_ "the Sender ID experiment" was.
Also I don't think the SPF RFC referring to the Sender ID RFC
("section 3.4 of RFC XXXX") is appropriate.
From the IESG's point of view, this is the only appropriate solution.
They are approving both SPF and SenderID, and so a note needs to be
made in the SPF spec about the conflict.
I already said that I can see the value of such a note. But you missed my
point. The note tries very hard to be "vendor neutral", without noticing
that such a kind of neutrality isn't actually appropriate here. I had
explicitly made it a point of my appeal that Sender ID had never tried to
interfere with "v=spf1" records _until_ after MARID was dissolved and the
IESG asked for individual submissions from Microsoft and us:
I understand. However, there were *many* technical changes made to
the SenderID drafts after the MARID drafts. The most significant of
which was the basis of SenderID upon SPF-classic rather than defining
the records from scratch. This caused a huge number of changes, as
witnessed by all the work we had to do to restore mengwong-spf-0[01]
semantics to the SPF-classic draft.
The IETF requested the authors to go off and continue working on their
drafts and submit them for experimental status. The change of the
re-use of SPFv1 records is just one of many technical changes that the
SenderID folks made. From our perspective, it is a very bad technical
change. From the IETF's point of view, it is just another reason why
SPF and SenderID are horribly muddled and neither should be promoted.
And finally, should we consider letting the SPF spec be formalized by
some other, more serious standards body, such as the Open Group? (I
think there was an offer by them to publish the SPF spec.)
I highly doubt that any other standards body is going to be more
vendor neutral.
See above for my view on "vendor neutrality" in this particular case.
Besides, I doubt that Microsoft is going to seek standardization of Sender
ID through some other standardization body. (It just wouldn't be of much
use to them, just as _not_ having a standards track RFC doesn't really
hurt them.) So "vendor neutrality" wouldn't be an issue for us.
I disagree. I think MS will *REALLY* not want to see SPF standardized
and SenderID not standardized. From what I can see, from such things
as the Email Auth Summit last August, MS is trying very hard to be
even handed and appear to be working "together" with the SPF
community. Such an explicit end-run around them could cause them to
stop trying to be even handed and go off on their own. They almost
certainly have more influence over things like the Open Group than we
do and they could "define" SPF-classic via them.
I see little that we could gain by going outside the IETF and a lot to
lose.
In another note, Mark mentions:
In <200512081423(_dot_)jB8ENS9q004549(_at_)asarian-host(_dot_)net> Mark
<admin(_at_)asarian-host(_dot_)net> writes:
I had rather seen a different, more decisive outcome, of course. Unlike
wayne, though, I do not really see how the extra note can harm us (unless
he means that having the note inserted in all four I-Ds only adds to the
confusion).
I think the extra note hurts in two very minor ways: as you mention,
it causes confusion, but it also adds yet another pointer from the SPF
spec to the SenderID specs.
But, I want to be clear, I don't think this note hurts us
significantly. It is really quite minor. I just don't think we had a
net gain from it.
-wayne
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com