|
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 Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf