Re: SHOULD vs MUST

On Jun 25, 2008, at 7:46 AM, Fred Baker wrote:

> I was about to write something like that to Scott; thanks for making  
> it unnecessary.
> My additional comment is that if there is some case I can think of  
> that leads me to say "should", there might also be another that I  
> didn't think of. Asking me to detail them all up front is IMHO  
> asking too much. On the other hand, I wouldn't be at all bothered by  
> being told that I had to justify a "must" - since in my mind it is  
> something to be used when not doing the action has a predictable  
> negative outcome, asking the author to say what that predictable  
> negative outcome would be is reasonable.
> My bottom line on a "should" is that if an implementer doesn't do  
> what the specification says he "should", he should have a good  
> reason and be prepared to explain it if questioned (for example by a  
> customer or during an interoperability test). "I disagreed with the  
> spec" is *not* a good reason, although it might be a good reason to  
> implement it and provide a configuration knob that turned that  
> functionality off, whatever it was.
I believe that in every instance that RFC 2119 language is used to  
state a requirement that there is either an implicit or explicit  
statement of consequences that are likely to occur if that requirement  
is violated. Further,  I believe that it is better to make those  
statements of consequence explicit, and that the severity of the  
consequences needs to support the severity of the requirements language.
We have a tendency to use RFC 2119 requirements language much too  
liberally. For example, it is frequently used in explication to show  
what happens, e.g. "To reach Bob, Alice MUST send him an INVITE  
request". There is of course a substantial difference between a  
description of what does happen, and a statement of requirement  
against which there are consequences if that requirement is not met. I  
believe that the clarity of our specifications and our ability to  
generate test plans against those specifications would greatly benefit  
from a concerted effort to reduce these spurious usages of RFC 2119  
requirements language.
The difference between an appropriately used  SHOULD and a MUST is one  
of severity of the consequences. MUST level requirements have the  
consequence that, if ignored, interoperability failure or other  
grievous harm is reasonably likely to occur. SHOULD level requirements  
have consequences of a different order; if the requirement is not met,  
some operational or functional benefit will not be achieved. MAY level  
requirements have consequences that are at the level of personal  
preference, esthetics, flavor, or style.
I try, but often fail, to convince authors to explicitly describe the  
consequences surrounding every RFC 2119 requirement, and to be frugal  
in the use of such requirements in their text. It is not to our  
advantage to  require a reader to be an expert in the subject to  
determine what the consequence of ignoring such a requirement may be,  
or we in effect require every reader of a specification to be an  
expert in the underlying art. Further, only clear statement of the  
consequences allow the reviewer of a draft to understand and make a  
judgement about the appropriateness of the strength with which a  
requirement is made.
While it is always true that there may exist rationale for a  
requirement that is not known to an author at the time of writing,  
failure to record any such rationale in a specifications seem to me to  
be a likely indicator that the specification has not been adequately  
thought through by the author, making it not yet ready for publication.
--
Dean
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf