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 same problem. Kyle Lussier AutoNOC LLC > > 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 > 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". > > > 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 > 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 > > >
