Subject: Finger to Historic

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 2 Dec 2020 13:37:29 -0500

While we are at it, we should kill this off as well:

RFC 1288 - The Finger User Information Protocol (ietf.org)
<https://tools.ietf.org/html/rfc1288>

I don't know how widely supported finger is today but I really hope support
is insignificant. Finger is a security liability that really can't be
fixed. And it assumes a usage model for the machines that simply doesn't
apply.

While it might be a good idea to have a user information protocol, that is
logically a component of a communication model.

I would go for IRC as well only someone just paid $27 billion for a
glorified IRC server so maybe it should stay for now.

---

From: Ofer Inbar <[email-masked]>
Date: Wed, 2 Dec 2020 14:11:11 -0500

> glorified IRC server so maybe it should stay for now.

IRC is still very widely used, and there isn't a replacement for it.
Slack, despite its similarity to IRC, doesn't have an open protocol
for clients, and requires you use the vendor's hosting for servers.
Each of those is, separately, a reason for many uses of IRC.
  -- Cos

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 2 Dec 2020 22:04:44 +0100

> glorified IRC server so maybe it should stay for now.

The Internet is run on two ports, 179 and 6667. The rest is just users
and test traffic.

(And the IETF needs more operator people in the mad scientist and
 vendor drone mix, as usual)
-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE           SA0XLR            +46 705 989668
Yow!  Am I having fun yet?

---

From: Keith Moore <[email-masked]>
Date: Wed, 2 Dec 2020 16:12:22 -0500

> <https://tools.ietf.org/html/rfc1288>

No objection from me.   I miss it, but the network has changed so much, 
in so many ways, since that protocol made any sense at all, that 
anything trying to replace it would need to start from a completely 
different set of assumptions.

No real objection to making Telnet historic either (though there are 
still a few devices that use it).   Most uses of telnet clients today 
are just used to connect a keyboard/display to a TCP connection, and 
omit the option processing etc.

Keith

p.s. 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

I wonder if there's a need to be able to say "this specification is not 
obsolete in the sense that it has been entirely superseded or there's no 
longer any valid  use for it, but today and for the foreseeable future 
this specification seems only appropriate for use in specific niches, 
and not for general purpose use on the public Internet".

---

From: John C Klensin <[email-masked]>
Date: Thu, 03 Dec 2020 01:35:34 -0500

--On Wednesday, December 2, 2020 16:12 -0500 Keith Moore
<[email-masked]> wrote:

> I wonder if there's a need to be able to say "this
> specification is not obsolete in the sense that it has been
> entirely superseded or there's no longer any valid  use for
> it, but today and for the foreseeable future this
> specification seems only appropriate for use in specific
> niches, and not for general purpose use on the public
> Internet".

As soon as you say that, you are into Applicability Statement
territory, which, IMO, is really what this discussion should be
about.  See the telnet/ftp thread for details.

  john

---

From: Dave Cridland <[email-masked]>
Date: Thu, 3 Dec 2020 09:39:48 +0000

> IRC is still very widely used, and there isn't a replacement for it.

The first is true, but NATO, for example, replaced IRC with XMPP several
years ago, so there are (open) replacements.

Dave.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 3 Dec 2020 13:02:05 -0500

> about.  See the telnet/ftp thread for details.

I disagree. Leaving aside the condescension in your other posts, we seem to
have a fundamental disagreement as to the role the IETF should play in an
IETF serving a user base of ~7 billion. What the IETF might have done 40
years ago, what it imagines itself to be doing are really besides the point.

The IETF has never been in the business of telling people what they can
use. Rather it produces a set of documents that describe a set of protocols
that provide significant value to a significant community of users.
Interoperability is one consideration of course. But it has never been the
only consideration. We vet new protocols for security, I see no reason to
grandfather insecure legacy.

What Historic means in IETF terms is that IETF process has finished. There
will be no further updates to the proposal. People are still free to use
the protocol if they choose. But if you have interacted with any product
manager, you know that they do take notice of such distinctions. Declaring
the old obsolete clears the path for a replacement.

An applicability statement doesn't really have the same effect. But more
importantly, how are you ever going to convince anyone IPv4 is dead if you
won't even take finger to the woodshed?

---

From: Keith Moore <[email-masked]>
Date: Thu, 3 Dec 2020 13:43:21 -0500

On 12/3/20 1:02 PM, Phillip Hallam-Baker wrote:

> We vet new protocols for security, I see no reason to grandfather 
> insecure legacy.

The reason, of course, is that people still have a need to use legacy 
protocols precisely because they're already deployed; and one person's 
legacy protocol is another person's essential protocol.

Also, we've extended many "legacy" protocols, some in better ways than 
others.   If we've done so poorly with some particular protocol (FTP 
might be such a case), maybe it's worth revisiting to see whether the 
design choices made then actually turned out to work.

> What Historic means in IETF terms is that IETF process has finished. 
> There will be no further updates to the proposal.

Well, that's not how 2026 defines the term.   But it strikes me as a 
useful distinction.   Maybe we should understand that if a protocol 
continues to enjoy significant use (even if only in niches) that 
protocol should continue to be maintained.   And if we decide to not 
maintain some protocol, labeling it as Historic might well be the right 
way to publicly declare that.

(another idea might be to delegate maintenance of some legacy protocols 
to other parties - someone else is maintaining this now, ask them if 
they still think it's useful.)

> An applicability statement doesn't really have the same effect. But 
> more importantly, how are you ever going to convince anyone IPv4 is 
> dead if you won't even take finger to the woodshed?

I suspect IPv4 will continue to be used for decades after public IPv6 
access is ubiquitous - on enterprise networks, on private networks, and 
to communicate with legacy devices.

But explicitly sunsetting the public IPv4 Internet in N years seems 
worth considering.    (Clearly operator groups need to have some input 
into that.)

Keith

---

From: "Scott O. Bradner" <[email-masked]>
Date: Thu, 3 Dec 2020 14:45:04 -0500

> On Dec 3, 2020, at 1:02 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
>  < snip>

> What Historic means in IETF terms is that IETF process has finished. 

it sure did not mean that when I edited RFC 2026

since RFC 793 has not been actually updated since RFC 3168 in 2001 I guess 
it is time to move it to Historic 

Scott

---

From: "Scott O. Bradner" <[email-masked]>
Date: Thu, 3 Dec 2020 14:48:21 -0500

s/793/791/

> On Dec 3, 2020, at 2:45 PM, Scott O. Bradner <[email-masked]> wrote:
> 
> 
>

---

From: Joseph Touch <[email-masked]>
Date: Thu, 3 Dec 2020 11:58:17 -0800

s/3168/6846/
s/2001/2013/

Joe

> On Dec 3, 2020, at 11:48 AM, Scott O. Bradner <[email-masked]> wrote:
> 
> s/793/791/
> 
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 3 Dec 2020 15:36:25 -0500

> it is time to move it to Historic

Its actually one of the more frequently updated RFCs.

Updated by: 3667 <https://tools.ietf.org/html/rfc3667>, 3668
<https://tools.ietf.org/html/rfc3668>, 3932
<https://tools.ietf.org/html/rfc3932>, 3978
<https://tools.ietf.org/html/rfc3978>, 3979
<https://tools.ietf.org/html/rfc3979>, 5378
<https://tools.ietf.org/html/rfc5378>, BEST CURRENT PRACTICE
5657 <https://tools.ietf.org/html/rfc5657>, 5742
<https://tools.ietf.org/html/rfc5742>, 6410
<https://tools.ietf.org/html/rfc6410>, 7100
<https://tools.ietf.org/html/rfc7100>, 7127
<https://tools.ietf.org/html/rfc7127>, 7475
<https://tools.ietf.org/html/rfc7475>,
8179 <https://tools.ietf.org/html/rfc8179>, 8789
<https://tools.ietf.org/html/rfc8789> Errata Exist

RFC 6410 - Reducing the Standards Track to Two Maturity Levels (ietf.org)
<https://tools.ietf.org/html/rfc6410>
RFC 7127 - Characterization of Proposed Standards (ietf.org)
<https://tools.ietf.org/html/rfc7127>

4.2.4 <https://tools.ietf.org/html/rfc2026#section-4.2.4>  Historic

   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.  (Purists have suggested that the
   word should be "Historical"; however, at this point the use of
   "Historic" is historical.)

You are nitpicking there and getting it wrong.

IETF continues to publish errata after a WG has closed. That represents a
continuation of the IETF process in my view. While some folk successfully
blocked a formal ongoing review of existing standards in the 1980s and
1990s, this has not been how the IETF actually works for at least a decade.

While I admit it is possible that an errata might be accepted for an
Historic document, I really can't imagine a case where a defect were so
egregious as to require an errata but not a new document.

Just as RFCs have never been a 100% accurate guide to behavior on the wire,
IETF process has diverged to an even greater degree.

And how the IETF behaves and the behavior most likely to obtain the desired
ends have also frequently diverged.

---

From: "Scott O. Bradner" <[email-masked]>
Date: Thu, 3 Dec 2020 18:41:31 -0500

hmm RFC 6846 does not say that it updates IP

nor does it say that it updates TCP (which was a typo in my original note) - RFC 4996 (which RFC 6846 replaces) says
it is a TCP profile, not an update

Scott

> On Dec 3, 2020, at 2:58 PM, Joseph Touch <[email-masked]> wrote:
> 
> s/3168/6846/
> s/2001/2013/
> 
> Joe
>

---

From: Joseph Touch <[email-masked]>
Date: Thu, 3 Dec 2020 15:57:46 -0800

s/6846/6864/

Sorry for the typo.
See: https://tools.ietf.org/html/rfc791 <https://tools.ietf.org/html/rfc791>

See 

> On Dec 3, 2020, at 3:41 PM, Scott O. Bradner <[email-masked]> wrote:
>

---

From: Lloyd W <[email-masked]>
Date: Thu, 10 Dec 2020 13:32:48 +1100

"The IETF has never been in the business of telling people what they can use"

there are a large number of RFCs with "Considered harmful" in the title.

Lloyd Wood
[email-masked]

> On 4 Dec 2020, at 05:03, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> The IETF has never been in the business of telling people what they can use

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 10 Dec 2020 13:50:25 +1100

https://rfc.fyi/?search=harmful

I note that all but two are Informational (for whatever that's worth).

> On 10 Dec 2020, at 1:32 pm, Lloyd W <lloyd.wood=[email-masked]> wrote:
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 10 Dec 2020 21:00:44 -0500

Telling people not to do some set of things is not the same as telling them
what they should do. And yes it is complicated.

One of the principles that makes the Internet different is the notion of
permissionless innovation. That is, I don't need permission from IETF or
OSI or anyone to deploy a new service or application. I just ship the code.

Which is why I worded my statement the way I did. Occasionally, the IETF
has come out and said that doing certain things is a bad idea. And that is
sometimes necessary. Particularly when IETF has in the past recommended
doing the thing now found to be problematic.

The problem of course is that a lot of features, services, etc. end up
being gated by assignment of code points. And the risk in assignment of a
code points is that it can be seen by some as an endorsement. That is why
'vannity crypto' is such a problem.

On Wed, Dec 9, 2020 at 9:51 PM Mark Nottingham <[email-masked]> wrote:

> use