Hiya, On 02/12/2020 23:19, Scott O. Bradner wrote:
I fully agree with John I see no justification to move telnet &/or FTP to historic since they are in use (even if some people would rather that not be the case) and neither presents a clear danger to the proper functioning of the Internet
I gotta wonder about that last. Wouldn't it be credible to argue that telnet is in fact a real danger, if one looks at all the CVEs that've reported on ports with admin/admin access? I'm not sure if it'd be the right thing to do, but I do think one can credibly argue that deprecating telnet might be worthwhile. Cheers, S.
ScottOn Dec 2, 2020, at 3:57 PM, John C Klensin <john-ietf@xxxxxxx> wrote: --On Wednesday, December 2, 2020 13:32 -0500 Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote:... But even if every developer needs to use telnet for debugging on a daily basis, that is still no reason for telnet to keep its standards status. I would like to see us being more aggressive in rendering old protocols obsolete so as to encourage new ones. and to discourage continued use of insecure protocols. ...Unless the rules changed when I wasn't looking (Scott should check me on this), the goal of IETF standards is to define conditions for interoperability among those who choose to use them. Whether incorporated into the same document or separate, "you should use this in preference to anything else" or "everyone who wants to part of the Internet should support this" statements are matters for Applicability Statements and recommendation levels, not standards status. We should not lose sight of the importance of that distinction, especially because we have had recent working groups developing protocols for standardization that are of use to only a tiny fraction of the Internet's users. Historically (sic) we have moved standards track protocols, especially Internet Standards, to Historic only when no one is using them and expecting implementations to interoperate (see RFC 4450 for a partial explanation), with, e.g., the ARPANET Host-IMP protocol as a rather good example. We have sometimes moved specifications whose use was already formally deprecated (even if there was not a spec that said "Not Recommended" as 2026 anticipated) to Historic for extra emphasis. Moving a document to Historic without doing anything else is nothing more than a statement by the IETF that the specification is of no further use as a specification. 2026 says "superseded by a more recent specification or is for any other reason considered to be obsolete" but that is the _specification_ not the protocol or its usability. As long as efforts to discontinue FTP support in a particular context or mere questions about adding a response code or features that might improve contemporary applicability call forth as much impassioned debate as we have seen recently, whatever that spec is, it is not Historic. Keep in mind that the IETF's Standards are voluntary and that, just as we cannot make anyone implement or use a Standard as we intend and prefer, we cannot prevent someone from using one of our specifications just because we have attached a term of shame to it. If we don't want someone to use a spec, we need to explain why in a way that is persuasive to them. So, if I understand correctly what you are actually trying to do, by all means write a spec explaining why no right-minded person would used FTP and/or Telnet and updating RFC 1123 and 765 and/or 854 to explicitly identify them as "Not Recommended". Moving it (and Telnet) to Historic without making that effort and while they are still in active use in parts of the Internet and for some purposes would only serve the purpose of further damaging the IETF's credibility. And, if your recommended replacements are not, themselves, IETF Standards, then, IMO, the damage to credibility would be even greater. I will save my opinion for what should be done with such a spec/proposal if it is written and posted for that event. best, john
Attachment:
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
