Re: SHOULD vs MUST

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