Re: [secdir] RFC2119 vs "ought" etc, was: SECDIR review of draft-ietf-httpbis-p7-auth-24

[Richard Barnes <[e-mail]>]

On Wed, Oct 30, 2013 at 9:57 AM, Julian Reschke <[e-mail]>wrote:

> On 2013-10-30 14:42, Richard Barnes wrote:
>
>> ...
>>
>> Do you mean that your intent was ought==should and might==may?
>>
>> Why do you feel the need to avoid SHOULD and MAY here?  They don't place
>> any more burden on implementors than "ought" and "might".
>> --Richard
>> ...
>>
>
> I believe in following the guidance in RFC 2119:
>
>  6. Guidance in the use of these Imperatives
>>
>>    Imperatives of the type defined in this memo must be used with care
>>    and sparingly.  In particular, they MUST only be used where it is
>>    actually required for interoperation or to limit behavior which has
>>    potential for causing harm (e.g., limiting retransmisssions)  For
>>    example, they must not be used to try to impose a particular method
>>    on implementors where the method is not required for
>>    interoperability.
>>
>
> I also note that there clearly is no community consensus about what the
> right degree of 2119 usage is. Until there is such thing, I recommend that
> we focus on 2119 keywords being used when they are needed, and not
> bike-shed over the other instances as long as the specification is
> consistent with respect to this.
>

The key word there, though, is "imperatives".  Nothing we're talking about
here is an imperative, just a recommendation (or RECOMMENDATION).  Skimming
through the instances of "ought to" in the document, it seems like they all
meet the definition of "SHOULD" in 2119, i.e., things that implementations
should only diverge from if they have a good reason.  (In fact, there are
some that seem like they should be "MUST", but that's a different topic.)

--Richard



> Best regards, Julian
>
>
>