Re: I'm struggling with 2219 language again

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dean, I am struggling constantly with 2119 as an AD, because if I take the letter (and the spirit) of 2119 at face value, a lot of people are doing this wrong. And 2119 is a BCP; it's one of our process documents. So I'd like this to be cleared up as much as you. I think there is active harm in the misuse we are seeing.

To Ned's points:

On 1/4/13 7:05 PM, ned+ietf@xxxxxxxxxxxxxxxxx wrote:
+1 to Brian and others saying upper case should be used sparingly, and
only where it really matters. If even then.
That's the entire point: The terms provide additional information as to
what the authors consider the important points of compliance to be.

We will like end up in violent agreement, but I think the above statement is incorrect. Nowhere in 2119 will you find the words "conform" or conformance" or "comply" or "compliance", and I think there's a reason for that: We long ago found that we did not really care about conformance or compliance in the IETF. What we cared about was interoperability of independently developed implementations, because independently developing implementations that interoperate with other folks is what makes the Internet robust. Importantly, we specifically did not want to dictate how you write your code or tell you specific algorithms to follow; that makes for everyone implementing the same brittle code.

The useful function of 2119 is that it allows us to document the important *behavioral* requirements that I have to be aware of when I am implementing (e.g., even though it's not obvious, my implementation MUST send such-and-so or the other side is going to crash and burn; e.g., even though it's not obvious, the other side MAY send this-and-that, and therefore my implementation needs to be able to handle it). And those "even though it's not obvious" statements are important. It wastes my time as an implementer to try to figure out what interoperability requirement is meant by, "You MUST implement a variable to keep track of such-and-so-state" (and yes, we see these in specs lately), and it makes for everyone potentially implementing the same broken code.

The notion (that some have) that MUST means you have to do something
to be compliant and that a "must" (lower case) is optional is just
nuts.

You bet, Thomas!

In some ways I find the use of SHOULD and SHOULD NOT be to be more useful
than MUST and MUST NOT. MUST and MUST NOT are usually obvious. SHOULD and
SHOULD NOT are things on the boundary, and how boundary cases are handled
is often what separated a good implementation from a mediocre or even poor
one.

Agreed. Indeed, if you have a MUST or MUST NOT, I'd almost always be inclined to have a "because" clause. If you can't given an explanation of why I need this warning, there's a good chance the MUST is inappropriate. (One that I've seen of late is "If the implementation wants to send, it MUST set the <send> field to 'true'. If it wants to receive, it MUST set the <send> field to 'false'." I have no idea what those MUSTs are telling me. Under what circumstances could I possibly want to send but set the <send> field to "false"?)

The idea that upper case language can be used to identify all the
required parts of a specificition from a
compliance/conformance/interoperability perspective is just
wrong. This has never been the case (and would be exceeding painful to
do), though (again) some people seem to think this would be useful and
thus like lots of upper case language.
At most it provides the basis for a compliance checklist. But such checklists
never cover all the points involved in compliance. Heck, most specifications in
toto don't do that. Some amount of common sense is always required.

And again, it's worse than incomplete. It also makes for brittle code. I don't want you checking to see if you coded things the same way that I did, which is what a compliance list gets you. I want you checking that your *behavior* from the net interoperates with me. Insofar as you want to call *that* compliance, well, OK, but I don't think that's what people mean.

Where you want to use MUST is where an implementation might be tempted
to take a short cut -- to the detriment of the Internet -- but could
do so without actually breaking interoperability.

Exactly!

IMO, too many specs seriously overuse/misuse 2119 language, to the
detriment of readability, common sense, and reserving the terms to
bring attention to those cases where it really is important to
highlight an important point that may not be obvious to a casual
reader/implementor.
Sadly true.

And to the detriment of good code..

pr

--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]