there are times when having telnet to test a mail server / email address is helpful? Happy to have a better sweetie if you can suggest one C Stephen Farrell writes: > 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. > >> >> Scott >> >>> On 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 >>> >>> >> -- Christian de Larrinaga https://firsthand.net
