---- Original Message ----- From: <ned+ietf@xxxxxxxxxxxxxxxxx> To: "Yaron Sheffer" <yaronf.ietf@xxxxxxxxx> Cc: <ietf@xxxxxxxx> Sent: Thursday, September 01, 2011 11:54 PM > > can you please explain *why* publishing conformance statements would be > > such a bad idea? I am not being cynical, I really want to understand the > > reasoning. > > (I don't know Pete's reasons, but I suspect they're not dissimilar from my > own. Which are ...) > > The main problem with conformance languge is that conformance has a nasty way > of becoming an end unto itself, and the *reasons* why conformance is desired > get lost along the way. The result is technical compliance to a bunch of words > on paper that don't provide an actual, useful, result like, say, insisting on > interoperability does. There is a part of our repertoire that demands compliance, which I equate with conformance, and that is an SNMP MIB module. RFC4181 requires every standard MIB module to contain a compliance statement (as defined in RFC2580) which nails down a minimum interoperable set of objects and access thereto, from the sometimes vast range defined in the MIB module. I see no reason why this principle should not be applied to a protocol, to its fields, its range of values and the ability to send or receive it. Tom Petch > > For example, the X.400 email standards are all about conformance. Incredibly > elaborate and picky conformance test suites can be, and have been, written for > this stuff. So how is it that, after passing a truly massive test suite that > checked every last little conformance detail in the specifications (and paying > lots of $$$ for the privilege), our software then failed to interoperate in at > least half a dozen different ways with another piece of software that as it > happened had also just passed the exact same test suite? > > Heck, we couldn't even get the thing to properly negotiate a session to > transfer messages. And once we got that working (in the process we ended up > having to violate a couple of those test suite requirements) we were > immediately lost in a thicket of differing interpretations of not just protocol > fields but even the basic elements that comprise X.400 addresses. > > And this is supposed to be useful? As a moneymaker for software developers, > maybe - you may rest assured the cost of all of this nonsense were passed on to > our customers, many of whom were bound by various regulations and had no choice > but to buy this crap - but as a way to get things to work, most assuredly not. > > And this trap is a lot easier to fall into than you might think. I've fallen > into it myself - I once spent entirely too much time dithering about getting > severe error handling "right" in a particular programming language > implementation, completely losing sight of the fact that once an error this > severe occurs the options are limited and the outcomes are so poor it just > isn't that important that the rules are followed to the letter. It made a lot > more sense on getting rid of the conditions that could cause an error. > > > And, for extra credit, what do you make of > > http://tools.ietf.org/html/rfc5996#section-4 (in my own backyard)? > > Well, the section may be titled "Conformance Requirements" but the section > is all about interoperability, not conformance. So that's fine in my book. > > Ned > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf