Re: des-die-die-die -- "implement" vs "provide",
Nico Williams <[email protected]>
| Newsgroups | gmane.ietf.krb-wg |
|---|---|
| Message-ID | <CAK3OfOjKJCY7tsEfvtHjEdj2Wrw1sVDF8YAnJGbPXXMLKh+8HA@mail.gmail.com> |
On Wed, Feb 29, 2012 at 2:22 AM, Simon Josefsson <[email protected]> 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. Agreed, there's nothing in RFC2119 to prevent deprecation and even MUST NOT. However, I do believe that interop with legacy is still important in many cases, enough to warrant the SHOULD NOT instead of MUST NOT. Nico -- _______________________________________________ ietf-krb-wg mailing list [email protected] https://lists.anl.gov/mailman/listinfo/ietf-krb-wg