Re: des-die-die-die -- "implement" vs "provide",

Martin Rex <[email protected]> writes:

> Tom Yu wrote:
>> 
>> Simon (and perhaps others) interpret "provide" so that an implementor
>> can implement functionality while not providing it, by disabling the
>> functionality by default.  I interpret "provide" in this context to
>> mean making available in any way, even if the implementor disables it
>> by default.  I've replaced "implementations and deployments SHOULD NOT
>> provide..." with "implementations and deployments SHOULD NOT implement
>> or deploy..." in my copy to avoid any further confusion with "provide".
>
> I'm personally opposed to make any requirements on implementation
> details, and I believe that "SHOULD NOT implement" or much worse
> "MUST NOT implement" is a clear violation of rfc2119 Section 6
> guidance on the use of Imperatives in RFCs.
>
> http://tools.ietf.org/html/rfc2119
>
>    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 believe implementing and deploying single-DES has the potential for
causing harm, so a MUST NOT imperative would be acceptable as far as my
reading of RFC 2119 is concerned.  I'm hoping the only reason we use the
weaker SHOULD NOT instead of MUST NOT in this document is that there are
still some legacy environments around.

/Simon
_______________________________________________
ietf-krb-wg mailing list
[email protected]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg