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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf