Mykyta Yevstifeyev wrote:
>> I'd like to see some kind of guideline that the RFC should not be considered
>> obsolete solely because of security or performance concerns in some
>> particular, specific context. For example, the fact that vanilla FTP is not
>> sufficiently secure for use in some applications where high security is
>> paramount is not a rationale for deprecating FTP in all applications.
>
> In the case I mentioned as c the key words are 'is not possible or is not
> advised to be used in the Internet' but not what you mentioned.
The document says “is not advised to be used in the Internet because of its
security issues, impact on its performance or any other reason.” (Do you agree
that the document says that?) My point is that, because security or
performance issues in one context do not necessarily imply security or
performance issues in all contexts, they should not by themselves (or together
with the 7-year criterion) be sufficient to trigger deprecation.
> The phrase 'or any other reason' is put because there is no possibility to
> put the exhaustive list of such purposes. Anyway, what would you like to
> propose here?
I don’t have exact replacement wording. “Any other reason” could permit me to
propose deprecation or “historicization” of a protocol because I don’t like the
guy who created it, or because my company is promoting a rival protocol.
--
Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s
_______________________________________________
Ietf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf
