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 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 > >
