On Sun, 5 Dec 2004, Greg Connor wrote:
I appreciate your taking the time to discuss and gather input.
The same and also I would like to note that many of us are happy to have
on our side people like you and Meng who are very diplomatic in your
positions and statements, such skills are important and often results in
greater cooperation among larger audience. But unfortunetly diplomacy
does not always work is not necessarily the right step when dealing with
Micorsoft and when we want to produce reliable technology.
In this regard I'd also like to remind that we did try to work with Microsoft
before under supervision of IETF (i.e. MARID WG). Microsoft did not address
any of the technical issues with SenderID that had been brought up nor
did it change the license eventhough we gave them several opportunities
(they missed several deadlines and we were willing to let it all go), in
the end IETF decided that because of Microsoft CallerID algorithm (with
its corresponding technical problems) and Microsoft unwillingness to
compromise on the license, that it would not be possible for MARID
to get its job done and produce standard that would have support of
the internet community.
My preference would be to ask the council to vote down the position
statement as written, and work on a much shorter, concise statement.
I do not believe this statement is overly long, it does somewhat mixes
political and technical reasons why SPF Community does not like Sender ID
in its current form, but it would not be appropriate to change it now
that it has so many people who have signed under it, nor would better
separation of political and technical reasons really change the issues
expressed by that document.
I would also remind that SPF Council (as it was called for based on
the results of my poll) should not really be making up policy on its own,
rather it should be acting is similar way to chairs in IETF WG and
ratifying positions that have consensus of the community and in this
case the consensus seems to exist as shown by large number of people
in SPF Community that supported this statement.
I would much rather see two or three very short resolutions adopted,
I do not believe it would be enough in this case.
than to have an "everything but the kitchen sink" version. (Check out
John P's version for an alternative, or at least a starting point)
In particular, there is confusion in the market about the relationship
between SPF and SenderID. This reduces the value of the SPF brand
name as an independant anti-forgery system. Problems associated with
SenderID have and will continue to tarnish the SPF name as long as we
allow this market confusion to continue. When (if?) SenderID fails in
the market, it is likely to cause further damage to SPF.
This is one of the aspects of the position statement that I found
troubling. How many developers is "many"?
"Many developers" were the words used because we did not have official SPF
Community at the time and statement was thus made as coming from "SPF
developers and users" (most of thee SPF library developers did sign this
statement).
How do we objectively measure confusion in the market?
How do we measure the tarnish upon SPF's good name?
I think you got the answer earlier today. People are now coming to SPF list
and beginning to blame us for the problems they see that are associated
with SenderID. And this is just a start and still at the time when
SenderID is not used at all (even by Microsoft.
Does Microsoft have a proven track record of marketing products that
fail spectacularly?
It absolutly does!!!!
Microsoft undeniably should get A+ for its marketing, but it would get
somewhere like C- for its technology - many many times they released
something that does not work and has serious security reasons (in fact
if not for them spam zombies would not be such as serious issue), several
times they have come to standards organization and wanted to change
something and that change caused what was previously good technology
to have technical issues - this has happened both with IETF and with W3.
The lack of real marketing research here is what concerns me. It's
entirely possible that SenderID will fail and that SPF will be viewed
unfavorably because of it, but it's also entirely possible that SenderID
will get lots of beneficial press and end up as a net gain for SPF even if
PRA fails to be adopted.
It is difficult to make such predictions either way, which is exactly what
you said. As such we have to rely on other points regarding relationship
of SPF and SenderID and those are not favorable to SenderID.
I suggest spending some time with Meng and asking him what he thinks of the
statement "there is confusion in the market about the relationship between
SPF and SenderID". After he gets done smiling and making steeples with his
fingers, he may say something enlightening. Who knows.
We have spent time with Meng and asked him and we never got the answer.
It appears to me both Meng and you (and I've always seem to have exactly
same view as Meng does eventhough almost everyone else on this list have
shown a different positions on one issue or the other) are way too
diplomatic to ever say "NO" to Microsoft and are willing to do anything
to be part of their team.
And while I do recognize value of teamwork, in this case I do not believe
that choice of partner would be equally beneficial to both sides. In that
regard I would like to remind people of the strategy Microsoft usually
takes when it begins to work as part of "the team" on some standard:
http://en.wikipedia.org/wiki/Embrace%2C_extend_and_extinguish
I have been assuming that SenderID refers only to the Microsoft PRA
algorithm.
This is an important question, and important distinction that deserves
careful thought. We could decide as a community to take a strong position
with regard to PRA (license and/or technical/pragmatic issues) and yet
still choose to remain "partners" with MS. Being a "partner" doesn't mean
we endorse everything they are doing.
SenderID is already mentioned in press and everywhere else as being
"Microsoft SenderID", I believe Microsoft will continue to market it
as such (they do not even provide link to SPF!) and in that regard it
is unclear how continuing to be "partner" with them is beneficial to
SPF Community especially when we see SenderID as being a problem rather
then solution.
It's also possible to post our problems with PRA without taking any
position at all on SenderID. Something to think about anyway.
We've had been on that road before for last 6 months in MARID and other
places and this has not resulted in any change to SenderID and in fact
the result is worth then when we started as now they want to reuse SPF v1
records without getting prior consent of the SPF record publishers for
using it in different way then what was originally intended.
Clearly we need to take a stand and explain what SPF v1 records are
supposed to be used for and why using it in Microsof way is not the
a good idea.
I notice that Sender Policy Framework is listed on the page (just not
linked) and that Meng Wong is listed as a signer.
Actually that "sender id industry letter" letter is pretty cool, and I
would probably sign it as well, if asked to. :)
I'm not surprised to hear that you (like Meng) would have signed it :)
Understood. Consider the option of taking aim at PRA and not SenderID
perhaps?
This directly relates to if we consider PRA = SenderID. If this is so,
then it does not really matter and SenderID is better known name and
it would be clear to others what we're talking about. Other then that
that statement already mentions PRA number of times.
As I've said, I see this vote as a way of putting this issue to rest,
and that was one of the primary reasons for creating the council.
I completely agree. Please go through archive and you'll clearly see that
friction within this group started because of continuing promotion of
SenderID and PRA by Meng and his disregard for the view expressed here
in regards to PRA algorithm and in regards to SPF becoming part of SenderID.
This has resulted in the situation that group leader was no longer seen
as been able to properly represent view of SPF Community and decide on
the issues important to us and as a result a more balanced leadership
group was selected.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net