Re: Pachyderm

---- Original Message -----
From: <ned+ietf@mauve.mrochek.com>
To: "Yaron Sheffer" <yaronf.ietf@gmail.com>
Cc: <ietf@ietf.org>
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@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf