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

I'm OK with any of the proposed wordings.

I really don't want to drag this out with endless discussions.  Whatever the exact phraseology, I think the intent to get rid of single-DES is clear.  I also expect the implementations will keep sufficient (undesirable) backward compatibility capabilities around somewhere for as long as is needed.

That said, and given the liklihood of non-native-english speakers reading the spec, if there is further disagreement we should not rely on precise interpretation of 2119 language.  We should just write a paragraph on the subject and spell out what we mean.

On Feb 29, 2012, at 12:22 AM, Simon Josefsson wrote:

> 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

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email protected], or [email protected]

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