ietf
[Top] [All Lists]

Re: Pachyderm

2011-09-02 05:17:50
---- Original Message -----
From: <ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com>
To: "Yaron Sheffer" <yaronf(_dot_)ietf(_at_)gmail(_dot_)com>
Cc: <ietf(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>