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