Yesterday in the Jabber session, Marshall raised the issue that there
really doesn't appear to be a rough consensus in this working group,
and people are not working toward a compromise solution. In fact,
people appear to be hardening their positions. If this working group
can't reach a rough consensus, then it is unlikely that the IESG will
agree with any RFCs we try to publish.
I have to agree with this assessment. There doesn't appear to be a
rough consensus. However, the long standing IETF mantra has, to the
best of my knowledge, been "rough consensus *AND* working code". What
we lack with most proposals is working code.
I think the lack of a rough consensus is in large part due to the lack
of working code. Working code quickly dispels both wishful-thinking
and FUD. Working code is a different way of expressing a proposal so
disagreements and misunderstandings about a proposal can be cleared up
by looking at the code and then either the code or the proposal can be
fixed to make things clearer.
The devil is always in the details. As long as we continue to
consider proposals that don't have working code, we allow people to
nit-pick proposals that are complete, while glossing over the problems
with proposals that exist on paper only.
Maybe I'm wrong, but I strongly suspect that the IESG is going to
require working implementations of any RFC we submit as standard track
RFCs. At some point before we select one or more proposals, we have
to have a near-finalized document with working code, preferably with
at least two different people/organizations creating code from the
spec.
I see three basic possibilities:
1) We stop talking about proposals that don't have working code
2) People putting forward proposals need to start publish code ASAP
3) We change the schedule to allow for more time.
Back in March, I made the following post which I will repost here:
http://www.imc.org/ietf-mxcomp/mail-archive/msg00617.html
It is a long post but, sadly, it has worn well with time. Only a few
things really need to be changed. I posted it before the Caller-ID
proposal came around, so please change the "Gordon, Hadmut, Markus" to
"Harry, Jim, Bob". Also, since this was posted months ago, you need
to change SPF email checking from "5-50 million messages per *month*"
to "5-50 million messages per *day*"
I think it is sad that very little has changed in the intervening
months with respect to working code. Working code is not only very
important, but something that can't just be whipped up quickly. (Code
can be written quickly, but it is rarly working code.)
The final paragraph almost makes me want to cry.
* To: "IETF MXCOMP" <ietf-mxcomp(_at_)xxxxxxx>
* Subject: Re: Ruminations
* From: wayne <wayne(_at_)xxxxxxxxxxxxx>
* Date: Mon, 29 Mar 2004 12:22:42 -0600
In <20040328035322(_dot_)GA45563(_at_)xxxxxxxxx> Markus Stumpf
<maex-lists-email-ietf-mxcomp(_at_)xxxxxxxxx> writes:
On Sat, Mar 27, 2004 at 03:36:21PM -0600, Gordon Fecyk wrote:
It's happening right now. Meng should pat himself on the back for a great
marketing campaign but ultimately, they decided.
Meng produced a lot of working code, and listened to what many other
people said. SPF didn't gain it's current popularity by marketing.
It is the leading designated sender system because of the work of many
many people working on many different parts of the problem.
But it may take some time to se any results at all.
Currently there is a big hype about adding SPF records. So what?
It has no effect at all.
One of the things that was discussed last summer on the SPF lists is
how to solve the chicken-and-egg problem of no one publishing SPF
records if no one checks them, and no one checking them if there
aren't any published.
We realized that people would publish SPF records, just to make a
public statement by the domain owners that they want to protect their
brand names and good reputation. This has benefits even if few people
are actually checking the SPF records.
With this in mind, we was decided that we needed to pay *very* close
attention to making it as easy as possible for people to publish SPF
records, and for those SPF records to require minimal maintenance.
Hence the creation of the 'mx', 'ptr' and 'include' mechanisms, and
the "SPF wizards" web pages which help people create SPF records.
If I didn't, miss something, I'd like to see a big ISP or mail hoster
that actually rejects emails because of SPF records. As soon as that is
going to happen THEN the users will tell and then we'll see if that big
entity is going to keep a counterstance. And that is what I still doubt,
at least until all the current problems are resolved and the solution
implemented in the MTAs.
The amount of email that is being checked with SPF is doubling ever
2-3 weeks and is currently on the order of 5-50 million messages per
month. Yes, that is a very small percentage of all email, but the
rate of growth is almost scary.
The amount of email being checked via SPF has already meant that there
has been a stead stream of email forwarders and such that have
wandered into the the SPF mailing lists because SPF of the effect that
SPF has had on them. Yes, many of them are not happy with the
situation or with the possible solutions such as SRS. However, the
response has actually been better than I was expecting. I'm seeing
quite a few forwarders adopting things like SRS in order to keep email
flowing smoothly.
So, the first goal of SPF was to make it easy to publish SPF records.
The next goal was to make it easy for mail admins to adopt SPF and SRS
by creating easy-to-install plugins to the major MTAs. It was decided
that any time there was a choice between making things easier for
domain owners and mail admins or making the job of writing SPF
implementations easier, the domain owners and mail admins should win.
The result has been that the creation of high quality SPF
implementations has taken some time, and this has made it harder for
mail admins to start checking SPF records, especially for the "big
ISPs". This situation is improving and I would say that SPF
checking will have had enough field testing and have high enough
quality/performance implementations that you will start seeing larger
ISPs checking SPF records by this summer, or maybe earlier.
This working group, however, appears to already be falling badly
behind on its own schedule, with no end of the debate about 'which
identities' in sight. Instead we get to hear the sour-grapes moaning
from Gordon, Hadmut, Markus, et al who, over the last year, have
decided to put a lot more effort into talking than actually
implementing their ideas. If you guys had actually been able to work
*with* people instead of promoting exclusively yourselves, either one
of your proposals would have become the de-facto standard that SPF has
become. Maybe, if the IETF decides to be irrelevant, one of you will
get the honor of a de-jure standard, but I doubt that will happen
either.
Oh, and before you get all huffy about my comments showing that I
can't "work with people", remember that having a thick skin is an
important part of being able to work with people. I've held my tounge
for a long time while various people have poked jabs at SPF. If I can
deal with such jabs as long as there is something productive coming
with them. The proof of the pudding is in the eating and there are
more people actually working together on SPF than all of the other
LMAP proposals, plus this working group combined.
Sadly, what I really expect to happen is over the next year or so,
this working group will try to come up with some sort of modified SPF
proposal with gratuitously incompatible changes. Mean while, SPF will
continue to slowly evolve, adopting any really good suggestions that
are proposed and ignoring the bad ones, just like it has since last
summer. After much debate, (2 years?) this working group will finally
realize that SPF is the de-facto standard and will finally decide to
throw out their work and adopt SPF.
*yawn*
I have code to write and bugs to fix in the SPF system.
-wayne