Re: Telnet and FTP to Historic

["Scott O. Bradner" <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 
> 
> --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
> 
>