> Sent from my iPhone > > On May 11, 2019, at 12:34 PM, Ned Freed <ned.freed@xxxxxxxxxxx> wrote: > > > > It's even better to continue to have customers and stay in business. First of all, this comment, as well as the comment from Doug you were responding to, is in the context of whether or not to code around bugs in other implementations, not failing to correct bugs in your own implementation. Second, not everything is security related, and even things that are security related aren't necessarily about weakening or strengthening security. > Why would you say this? I said it because I've been able to keep customers by adding workarounds and lost customers by not doing so. > Of course we all understand that there will be pressure to do less work, and > consequently produce less secure implementations. The question is, should the > IETF assist or hinder this practice? Huh? I have no idea what this is supposed to mean. We're talking about whether or not to do *additional* work, and the pressure is usually to "make things work, never mind how". > Should we normalize it or, not to put too fine a point on it, write our specs > in such a way that when you do this it’s easy to demonstrate misfeasance when > you are taken to court? The odds of this sort of thing landing any of the participants in court, regardless of what they do or don't do, are quite small. (And when it does happen, well, let's just say that technical merit doesn't count for as much as it should.) But the almost certain lack of legal consequences doesn't mean there aren't risks to consider. Here's a (suitably anonymized) real world example. Some time back one of our customers, after several weeks of extensive testing, decided to upgrade our software across their deployment. Unfortunately, the testing managed to miss a particular interaction with another vendor's software, with seriously bad results. I soon managed to figure out what was happening: We had added an optimization to our code that made use of a particular protocol feature we hadn't used before. Despite being a mandatory part of the protocol specification, the other vendor's product did not implement the feature we now depended on. The other vendor immediately acknowledged that this was their bug, so finger-pointing was not an issue. At this point we had three choices: (1) Do nothing - it's the other vendor's problem so it's up to them to fix it. (2) Remove the optimization entirely. (3) Add a configuration switch to disable use of the option. Now, by your logic the correct choice is (1). But here's the thing: Implementing a missing feature is a lot harder than disabling a recently added optimization. So much so that the customer would have had to back out the upgrade, downgrade upgraded databases, etc. etc., wait for the new version of the other vendor's software to come out, test that, upgrade that, and then restart the original upgrade process. In constrast, we could - and did - issue a patch to disable our use of the feature in a matter of hours, salvaging the upgrade. Of course there was risk in doing this: We could have introduced additional, possibly worse, problems, problems which in our haste to deploy a fix might not have been found until much later. And such a problem would have been entirely our fault. And maybe that risk are suffcient for you to still believe (1) was the correct choice. But think for a moment about perception. Upper management types don't care about specifications, who follows them, and who doesn't. All they are going to hear is that a major upgrade of our software turned into a catastrophe, costing lots of time while waiting for another vendor to step in and solve the issue while we did nothing. Not exactly the record we want when the time comes to renew our support contract. By fixing the problem ourselves we managed to both minimize the consequences and come across as the good guys. Now, this is just an anecdote, and the plural of anecdote is not data. But I could just as easily have described a dozen other similar cases, including a couple where we got on our high horse and promptly crashed it into a wall. Ned
