Subject: Re: Fwd: Re: IP: Microsoft breaks Mime specification

From: "Kyle Lussier" <[email-masked]>
Date: Wed, 23 Jan 2002 12:09:30 -0800

> If a vendor *fixes* something and we get burned that bad, what makes 
> you think that yanking the right to use a logo will change anything?

Well, the whole point of it is to give CIOs and IT Managers the
ability to write into their contracts "IETF Compliance" or no
money.

CIOs would still need to choose to do this of course, but, as I
mentioned before, I know a number of them that are ready to
strangle some of their badly behaving vendors.

In the economy of today, if large implementations don't go well,
as a CIO, you are out the door.  IETF Compliance can go a long
way torwards helping secure the jobs of our CIOs by reducing
interoperability headaches and vendor standards infighting.

Kyle Lussier
AutoNOC LLC

---

From: [email-masked]
Date: Wed, 23 Jan 2002 16:04:20 -0500

> ability to write into their contracts "IETF Compliance" or no

Oh. No. He brought "money" into it.  

This makes it a *lot* harder to do without getting yourself sued.

You're looking at situations including:

1) Vendor X has the logo, Vendor Y hasn't applied/recieved it yet.
Y has the better product, but X gets the bid.  The IETF gets sued
by vendor Y for conspiring to keep Y out of business, and you get
sued as CIO by your shareholders for mismanagement because X turns
into a boondogle.

2) Vendor X has the logo, but a *severe* bug has been found, but the
logo hasn't been pulled yet.  Vendor Y has had their logo pulled for a
smaller infraction.  Vendor Y sues you and the IETF because of unfair
practices..

3) Vendor X has the logo, but nobody has actually *verified* that
their product implements the standard.  Vendor Y has their logo pulled
for something minor.  This leads to:

3a) Vendor Y sues because nobody has tested X.

3b) Vendor X was the one who pointed out the problems in Y, and due to
marketshare/influence/bribery, Y's logo got pulled while testing of X
gets delayed - allowing X to get a contract that Y would have gotten
otherwise.

4) You buy shrink-wrapped Z that has the logo.  You subsequently find
that the logo had been pulled, but of course the product wasn't recalled
off the store shelves and repackaged before you bought it.  You find
yourself fired because you broke company policy to only buy logo'ed
products.

5) Vendor Y sues because their logo gets yanked because THEIR interpretation
of an RFC doesn't match the reading the WG Chair gives of the RFC, and the
WC Chair happens to work for Vendor X.

6) You are cordially invited to suggest how Microsoft will brand their
Outlook XP with the logo, in particular, how to keep track of all the
following:

6a) Outlook XP branded as of 01/01/2002
6b) Outlook XP SP1 not branded as of 01/21/2002 because of bug 4781
6c) Outlook XP SP1+OfficeQFE:4781 branded as of release date of fix for 4781
6d) Outlook XP SP1+OfficeQFE:4781 but lacking OfficeQFE:NNN not branded
as of 02/dd/2002 because of bug NNNN
6e) Outlook XP SP1+OfficeQFE:4781+OfficeQFE:NNN branded as of 03/dd/2002,
but Outlook XP installs that are missing either the 4781 *or* NNNN fix are
*not* branded.
6f) Outlook XP SP2 is branded, *except* if you've installed fix MMMM which
breaks something, unless you've ALSO installed fix NNMM...

And that's with just 3 or 4 bugfixes.  Remember that a major product
could have *hundreds* of bugfixes, all of which impact compliance to
some extent.

Enjoy.

7) Microsoft and AOL/Netscape get into a "Well, *your* browser does THIS!"
war, with *both* sides shipping fixes and poking holes in the other's
software on a daily basis, and somebody gets to track the current state
of *two* browsers as per point (6) above, while both sides have lawyers
breathing down your neck saying "Well, if *my* bug XYZ counted, so does
*their* bug QST".

> strangle some of their badly behaving vendors.

Again - if the CIO telling the vendor "Fix it or we're going elsewhere"
doesn't cause the vendor to toe the line, why will "Put a logo on it
or we're going elsewhere" do it?

> interoperability headaches and vendor standards infighting.

You obviously haven't been in the industry long enough to have gotten
stuck in the middle of an deployment of a "certified" product that won't
interoperate.

I'm sure most of the old-timers on this list have seen at least one case
where a vendor guaranteed in writing that Version N+1 of their software
would interoperate with Version N of *the same software*, but the upgrade
didn't work right anyhow, since the software didn't read the guarantee....

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech