Hector,
First I'd like to thank you this earlier post:
http://www.mhonarc.org/archive/html/spf-discuss/2005-09/msg00044.html
that had a lot of very good and constructive thoughts.
I do think however that today you're bit off describing MARID problems,
see comments inline:
By "spf-bias", do you mean that the MARID WG chairs had a pro-SPF
bias, or an anti-SPF bias?
The rest of your post makes it sound like you think they had an
anti-SPF bias, but I actually think they were both pro-SPF and a
pro-PRA. (And they didn't find these two to be in deep conflict.)
I guess that is why MARID went smoothly, quick resolution and closure?
Chairs are supposed to be neutral (ok, don't pick at me - I know the
difference between supposed to and is) and I think in that case it
was not as bad as you describe, plus Marshall appears to have kept
completely out of "politics" and on general wg organizational role.
I should of been more clear. In my opinion, they revealed a prejudice and
influenced by the strongest computer software company in the world and by
other influential members of the IETF community. i.e. Dave Crocker and a few
others who uncategorically showed a negative bias, prejudice, pre-judging of
SPF.
CSV should not have been in MARID.
And why is that? It's SMTP authorization with records in DNS like the
charter says. Did you really want an "SPF" IETF WG that would just
rubber-stamp spf draft (like DKIM is going to be) and not try to look
at this area of technology and do appropriate work in comparing,
choosing and creating the best set of solution(s)?
It was completed out of scope. PRA should not had been introduced.
It was completely out of scope compared to SPF and CALLERID.
Again why not? PRA is actually the artificial identity (based on
Resent-Sender, Resent-From, Sender, From algorithm) that is used in
CallerID, so its not entirely new to MARID (name might have been, I
have to do some research on if MS used PRA name for CallerID or not).
MARID started with SPF and its XML-based clone CALLERID. The work was
mainly picking between the two.
The work of the WG is not supposed to be picking but engineering. This
can involve using existing proposal and working it further, but can
also involve complete engineering of new solution or engineering as
combination of several proposals choosing best options to arrive at
consensus.
I do not believe that in this case MARID was doing it wrong, except that
they tried to limit the scope to only PRA identity, which also happens
to be wrong since IETF is supposed to consider alternatives because of
patent and license issues.
You had a working technology where now the attempt was to "take it apart"
and put it back together again using all kinds of different stuff, and
during this process, you had the SPF community versus the rest of the world
who wanted to thier 'ideas' used.
That is why it was an IETF WG and not SPF Community WG. And it is not
supposed to be one versus the other, its supposed to be attempt to work
together with different constituencies to attempt to create a solution
that is acceptable as consensus approach. But it seems there are large
egos and political maneuvering with anti-spam and related work and so we
see attempts to replace technical work on the solution with attempts of
various groups to dominate with their own approach and using various
non-technical ways to achieve it. SPF is no strange to that too.
These are my assessment as an 100% active participant as a VENDOR
looking at everything. It was not hard to see who lean which way.
Certainly its true that it was easy to see which way somebody "leans"
and I certainly agree that MARID WG did not go well, but I happen to
disagree with Hector quite a bit on how it was supposed to have gone
especially as it was an IETF WG.
So I guess above is my assessment as a very active participant
(not only on the mail list but also participant at both interim
meeting in San Jose and IETF meeting in August) and 100% not an
email or anti-spam product vendor :)
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
-------
Sender Policy Framework: http://spf.pobox.com/
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