In <tslbqznbcem.fsf@xxxxxxxxxx> Sam Hartman <hartmans-ietf@xxxxxxx> writes: >>>>>> "wayne" == wayne <wayne@xxxxxxxxxxx> writes: > > wayne> In <200512092141.NAA00720@xxxxxxxxxxx> Bob Braden > wayne> <braden@xxxxxxx> 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 _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf