Maybe "Internet Standard" should be called "Confirmed Standard" which I think would be a little clearer. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@xxxxxxxxx On Fri, Aug 2, 2024 at 12:07 PM Rob Wilton (rwilton) <rwilton=40cisco.com@xxxxxxxxxxxxxx> wrote: > Hi John, > > > > For me, I think that the key here is not to get wrapped round the axle of IETF process and to do the right thing for the Internet community and end users. I.e., the real aim here is that we should be trying to ensure that IETF and the standards process continues to be relevant to the wider technical community. > > Your point that the SSH RFC is only PS and TELNET is IS effectively shows how splitting the classification between IS and PS is effectively broken. The same logic flaw exists with HTTP 1/1 (RFC 9112) that was recently reclassified as IS and HTTP/2 (RFC 9113) that is PS. Does this mean that the Internet at large should really be deploying the mature internet standard HTTP 1/1 rather than “proposed standard” HTTP/2? The reality that I see is that most companies believe the work is done when the PS RFC is published and don’t care for the additional work to advance to IS, which also by that time they have probably moved on to developing other protocols or extensions. > > > > RFC 2026 defines Internet Standard as: > > A specification for which significant implementation and successful > > operational experience has been obtained may be elevated to the > > Internet Standard level. An Internet Standard (which may simply be > > referred to as a Standard) is characterized by a high degree of > > technical maturity and by a generally held belief that the specified > > protocol or service provides significant benefit to the Internet > > community. > > > > I think that the end of that paragraph, starting with “generally held belief that the specified protocol or service provides significant benefit to the Internet community.“ is no longer true for TELNET. Specifically, its lack of security outweighs its other benefits. > > > > RFC 2026 defines Historic as: > > > > A specification that has been superseded by a more recent > > specification or is for any other reason considered to be obsolete > > is assigned to the "Historic" level. > > > > The second part of this sentence is clearly true and has been for a long time. I’m now wondering how long ago it was mandated within my employer that all TELNET access to internal servers would be disabled and only ssh access would be provided. As I said before, it is at least 10 years, but probably more like 20. Perhaps the security team at Cisco were just way ahead of the curve, or more likely IETF is way behind the curve (at least in terms of document status/relevance). > > > > Why does a Linux install default to installing ssh by default and telnetd is only available to be installed via a package? Thank goodness the Linux distribution devs ignore the IETF document status and just apply common sense security considerations instead. > > > > I believe that the stability in IETF processes and IETF standards is a good thing, but we also need to balance this with the need to ensure that the IETF evolves with the times and continues to stay relevant to the industry and Internet community. > > > > I really can’t quite believe that the community is having a long discussion on whether TELNET /FTP is historic or not. This is too laborious to update the status of one RFC, we need an easier/quicker mechanism to update that status of a lot of the old RFCs to better reflect current best practice and deployment. I would have thought that TELNET and FTP would have been some of the easiest to reach agreement on, but obviously I am wrong. > > > > But sorry, none of this discussion changes my opinion that TELNET is effectively dead for common deployment/usage and has been that way for a long time. I just wish that there was an quick/easy way to update the document status to reflect that so that what exists in the IETF micro-bubble is consistent with the wider experience of the rest of the industry. > > Regards, > Rob > > > > > > From: John C Klensin <john-ietf@xxxxxxx> > Date: Thursday, 1 August 2024 at 23:03 > To: Rob Wilton (rwilton) <rwilton@xxxxxxxxx>, Lloyd W <lloyd.wood=40yahoo.com@xxxxxxxxxxxxxx>, Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> > Cc: Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx>, ietf@xxxxxxxx Discussion <ietf@xxxxxxxx> > Subject: Re: TELNET to HISTORIC Re: FTP > > Rob, > > See my most recent note (and Keith's and Geert's that preceded it and > John Levine's recent one that followed it). Recent best practice > suggesting that ssh is a better option for most applications on the > main/public Internet is not sufficient justification for moving it to > Historic, no matter how passionately you and some others feel about > that, especially so because there is no standards-track definition > for SSH. In particular, both because of the lack of that status for > SSH and the other issues that have been raised, there is _no_ > standards track replacement for Telnet. It _is_ more than > sufficient justification for: > (1) Getting an I-D posted that thoroughly describes SSH (and any > implementation variations on it), its Security Considerations issues, > etc., into the queue for standardization. > (2) Writing an Applicability Statement that describes the issues with > Telnet, why it may not be appropriate for general use, what the > alternative(s) are, and in what sorts of circumstance it might still > be appropriate. > > I, for one, await those I-Ds. Or you can continue to say "doesn't > change my opinion..." You are certainly entitled to that opinion, > but, given the other opinions that have been expressed on this > thread, my guess is that you would have considerable difficulty > demonstrating IETF consensus for just changing Telnet's Status > classification from "Internet Standard" to "Historic" by re-marking > it. > > I think you'd get further if there were "some text that indicates why > it has been marked as historic", as you suggest below but, given that > it is a Internet Standard and still in active use in some quarters, > that text should almost come in the form of an RFC and some some > comment somewhere. And that takes up back to a version of (2) above > although maybe a lighter-weight one. > > Just my opinion, of course. > john > > > --On Thursday, August 1, 2024 21:22 +0000 "Rob Wilton (rwilton)" > <rwilton@xxxxxxxxx> wrote: > > > Hi Lloyd, > > > > But this doesn't change my opinion that it should be marked as > > historic. I'm not suggesting that you can't use it (e.g., in > > those rare circumstances where you cannot run something more > > secure), or that implementations need to be deleted, or new > > implementations cannot be written. > > > > All I am saying is that my understanding is that best practice, at > > least for the last 10 years or so, has been to use ssh instead of > > telnet, and hence marking telnet as historic helps signal that to > > the wider world (particularly if there is some text that indicates > > why it has been marked as historic). > > > > Does this really matter? Probably not, since I think that world + > > dog already knows this anyway. In terms of updating document > > status, it feels that often IETF is the last one to the party … > > > > Regards, > > Rob > > > > > > From: Lloyd W <lloyd.wood=40yahoo.com@xxxxxxxxxxxxxx> > > Date: Thursday, 1 August 2024 at 21:50 > > To: Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> > > Cc: John C Klensin <john-ietf@xxxxxxx>, Rob Wilton (rwilton) > > <rwilton@xxxxxxxxx>, Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx>, > > ietf@xxxxxxxx Discussion <ietf@xxxxxxxx> Subject: Re: TELNET to > > HISTORIC Re: FTP > > nixed? it's installed, and supported. you enable it with a checkbox. > > > > https://phoenixnap.com/kb/telnet-windows > > > > Lloyd Wood > > lloyd.wood@xxxxxxxxxxx > > > > > > On 11 Jul 2024, at 13:10, Phillip Hallam-Baker > > <phill@xxxxxxxxxxxxxxx> wrote: Windows nixed their TELNET client a > > decade ago >
