Re: Telnet and FTP to Historic

[John C Klensin <[e-mail]>]

--On Wednesday, December 2, 2020 13:32 -0500 Phillip
Hallam-Baker <[e-mail]> 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