Subject: re: Pachyderm

From: Yaron Sheffer <[email-masked]>
Date: Fri, 02 Sep 2011 00:17:36 +0300

Hi Pete,

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.

And, for extra credit, what do you make of 
http://tools.ietf.org/html/rfc5996#section-4 (in my own backyard)?

Thanks,
     Yaron

On 09/01/2011 06:38 PM, [email-masked] wrote:
> My interpretation of what you wrote is that in your mind there is absolutely no difference between a SHOULD and a MAY.  They are both optional, and you implement whatever you have time to implement, with SHOULD's prioritized higher than MAY's.
>
> Even if that is not what you mean, it is what many implementors do.
>
> Peter's document makes a change to 2119 that nobody has mentioned yet,
> and I think it is the one that is causing most of the strife in this
> discussion.
>
> Hector is exactly right. SHOULDs are optional. MAYs are optional. What
> he fails to point out is that MUSTs are also optional. They're all
> optional because.....
>
> RFC 2119 does *not* provide *conformance* terms.
>
> Peter's document uses the words "conform" and "conformance". They appear
> nowhere in RFC 2119. RFC 2119 was not coming up with a vocabulary for
> things that MUST be done if one is to conform to a specification. It
> came up with terms for things that MUST be done to interoperate. Or
> SHOULD be done (with a pretty specific meaning of "SHOULD"). Or MAY be done.
>
> If you think that the presence of SHOULD means that you don't have to
> implement a particular thing in a document, you're wrong. SHOULD means
> that "may exist valid reasons in particular circumstances to ignore a
> particular item, but the full implications must be understood and
> carefully weighed before choosing a different course." That is, if you
> don't do what is in the statement marked by "SHOULD", there is a good
> chance you will fail to do something that is "required for
> interoperation" or to engage in "behavior which has potential for
> causing harm" unless you understand the implications.
>
> But if you think that the presence of SHOULD (or MUST) means that you
> *have to* implement a particular thing in a document, you're also wrong.
> There are not protocol police. We don't do conformance checks in the IETF.
>
> You might have a contract with someone who requires you to implement all
> MUSTs (or SHOULDs unless you provide an explanation of why you didn't).
> That's up to them. But the IETF ought not be in the business of
> conformance requirements.
>
> Maybe we do write documents now with conformance requirements. Maybe
> this ship has sailed. Maybe the elephant is on board. I hope not.
>
> Clarifying "SHOULD" is a fine thing. Making it conformance language is
> not. I don't like the 2119bis document in its current form.
>
> pr
>

---

From: [email-masked]
Date: Thu, 01 Sep 2011 14:54:10 -0700 (PDT)

> such a bad idea? I am not being cynical, I really want to understand the

(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.

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.

> 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

---

From: "t.petch" <[email-masked]>
Date: Fri, 2 Sep 2011 11:13:19 +0200

---- Original Message -----
From: <[email-masked]>
To: "Yaron Sheffer" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, September 01, 2011 11:54 PM
> on paper that don't provide an actual, useful, result like, say, insisting on

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
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf