In <tslbqznbcem(_dot_)fsf(_at_)cz(_dot_)mit(_dot_)edu> Sam Hartman
<hartmans-ietf(_at_)mit(_dot_)edu> writes:
"wayne" == wayne <wayne(_at_)schlitt(_dot_)net> writes:
wayne> In <200512092141(_dot_)NAA00720(_at_)gra(_dot_)isi(_dot_)edu> Bob
Braden
wayne> <braden(_at_)ISI(_dot_)EDU> writes:
>> This thread has contained several suggestions that publication
>> of an RFC in the Experimental category constitutes an "IETF
>> experiment".
wayne> This is, in part, due to the directions of the IESG. [...]
I have to agree. While typically the term experimental RFC does not
imply an IETF experiment, I think this is a bit more organized.
I'm not sure there actually is an IETF experiment. However the IESG
has more or less said that anyone wanting to move one of these
technologies onto the standards track needs to come back in some
period of time and demonstrate an IETF experiment took place and
present some conclusions.
I have, in the past, argued to the IESG that I did not think the SPF
I-D should be marked Experimental because I did not see it being an
experiment. It has been out for 2 years now and it is far too widely
deployed to make significant changes. Instead, I thought it should be
standard track. I have also said that I could see it being
informational.
I have also, in the past, requested from the IESG some sort of outline
of what the "lessons learned" document should contain. So far, I have
not received and answer. The current SPF I-D already has had a lot of
work put into it based off of things that we learned about the actual
deployment of SPF. I'm not sure what more we should be studying.
So, I'm somewhat perplexed about these "IETF experiments" for SPF and
SenderID.
We don't know what we are supposed to be studying. They are being set
up in a conflicting way, thus making any results questionable.
SenderID is reusing the Resent-* headers in an incompatible way.
SenderID is self-contradictory in that even if everyone involved
implements it to its fullest, the PRA part of SenderID can't not
distinguish between an email that gets sent to a mailing list and the
forwarded (adding Sender: first, and then Resent-* second), and an
email that gets resent to a mailing list (adding Resent-* first, and
Sender: second).
I confess that the reason why I have worked hard on the current SPF
spec is so that we would have a solid spec for people to work with. I
have asked for reviews from IETF sources because I think that is
valuable, and it certain was. (Thanks everyone!) I am much less
concerned about whether the SPF spec even ends up as an RFC, and if it
does, what kind of label is put on it.
so, yes the IESG is sort oof putting an optimistic spin on things by
calling it an experiment. We're hoping people will want to come back
some day, fix the problems and make a standard.
Well, I can see coming back some day and trying to create an update to
the SPF protocol. I can't see trying to change SPF version 1.
It's clear to me that neither SPF nor Sender ID could achieve the
necessary rough consensus to be a standard-track protocol.
Well, I guess that all depends on how you count "rough consensus", and
that is something I really don't understand how the IETF defines it.
There are a huge number of people who use DNSBLs and have for many
years. There are many people who don't like them, to put it mildly.
However, DNSBLs are just a way for one part to publish information and
another to listen to it. No one is forced to create a DNSBL, no one
is forced to listen, and no one is forced to act on the DNSBL info in
any particular way.
Personally, I think that DNSBLs are well enough understood to put on
the standard track, as long as you ignore complaints from people who
doesn't like the fact that they exist.
Similarly, I think SPF and DKIM could/should be put on the standard
track. They both cause problems with the way people use email today,
but only for those that want to participate.
-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