Scott Brim wrote:
My rule of thumb is: when you're writing the draft if something is not a
MUST, ask yourself "why not?" and write down your answer. You can be
brief but make it clear that the SHOULD is a MUST with exceptions.
This gets to an essential issue with IETF specification writing, as well as
suggesting some of the distinction between MUST and SHOULD.
(By the way, I hope folks are clear that IETF use of these words as normative
does not depend upon the case that is used?)
1. MUST is required if interoperability will otherwise be broken. The spec does
not offer any leeway to implementors. Including rationale might be nice, but is
not required.
2. SHOULD is used when there is a strong consensus that the specification's
utility is greatly enhanced by having the SHOULD get implemented, but the
specification is acknowledging that careful judgment by an implementor can
produce cases in which it is acceptable not to implement it.
The fact that a SHOULD explicitly calls for judgment by an implementor
invites two things that we probably are not very consistent about delivering in
specifications:
a) Why is it best to implement the SHOULD? What is the nature of the
benefit provided by the feature? Often this is obvious, such as an additional
and more powerful algorithm for a set of component security mechanisms. Still,
it makes sense to state this explicitly.
b) What examples are there that would justify *not* implementing it? For
example, resource constraints, implementation simplicity, very tightly
controlled execution environment? Of course, the danger with listing examples
is that folks might come to believe they are exhaustive...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf