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

I'm OK with the current SHOULD NOT in the document.

Simon Josefsson wrote:
> 
> Martin Rex <[email protected]> writes:
> >
> > 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.


You interpretation of "potential for causing harm" is _far_ outside
of the intended meaning of rfc2119 section 6, and not having a protocol
feature enabled by default that provides interop with an old installed
base is perfectly sufficient to prevent harm, an the latter is what
is meant by "they must not be used to ry to impose a particular
method on implementors".

If the spec says "must not enable by default", then it is at the discretion
of the implementor whether to implement it for backwards interop with
an old installed base or whether to not implement it at all, while
a spec saying "MUST NOT implement" imposes a particular method on
an implementor that is unnecessary.

With your reading, the IETF would have to publish an RFC that says
"MUST NOT implement HTTP over TCP without TLS".

And further it would have to specify "MUST NOT use TLS with several
dozens of trust anchors preconfigured by software vendors",
because we have proof just how much serious harm that may cause.


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