I think, ultimately, this could be done. None of these
are scenarios that couldn't be handled in the application,
and testing would be a non-issue, because you just say
"my product follows IETF standards". The only worries
you have are about not conforming to the IETF.
But, the consensus, as I read it, seems to be that it's
not what IETF is about and is impractical. That's fine,
and I agree with the comments.
It's just a shame there aren't better solutions to
badly behaving vendors. Because the net result is
that we all have to learn more products, we double
our costs, we couble our expenses, and things move at
half-speed. Love it or not, this is a problem we all
will have to deal with, for a long time.
And if not the IETF to solve this problem then who?
It's easy to villify an idea that may or may not
be appropriate, but we're still stuck with the
On Wed, 23 Jan 2002 12:09:30 PST, you said:
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
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
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
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
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
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
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".
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.
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?
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.
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
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....
Computer Systems Senior Engineer