deprecate RIP

[ivy]

Summary

per https://wiki.freebsd.org/DeprecationPlan, deprecate RIP in 15.0R,
with the intention of removing it in 16.0R.

add a note to the manpages of routed(8), rdisc(8), rtquery(8),
route6d(8) and rip6query(8) noting that they will be removed in a future
release.

RIP has been obsolete for over 20 years and no one is running it on
modern networks. if someone really needs RIP, there are alternatives
such as 'bird' or 'quagga' available from ports; there is no need to
ship it in base.

Relnotes: yes

[ivy]

fix an error in the route6d.8 manpage

[kevans]

sbin/routed/rtquery/rtquery.8

28

I would set stronger expectations and just state this will be removed in
.Fx 16.0. We're not forced to stick to 16.0 if we announce it in 15.0 and decide that maybe some part of it needs to stick around for another release.

[zlei]

RIP has been obsolete for over 20 years and no one is running it on modern networks

RIP is quite a simple routing protocol to be implemented, and can be found from lots of routers. It is still available from modern routers, even modern networks prefer other routing protocols.

I'd say RIP can be easily deployed rather than obsolete.

[ziaee]

sbin/routed/rtquery/rtquery.8

28

I do not deprecation notice as the first line in the introductory paragraph. The first line in the introductory paragraph should explain what it is.

I disapprove of removing this, but if you're going to do it, please don't break the introductory sentance of the manual.

[cy]

In D50292#1147383, @zlei wrote:

RIP has been obsolete for over 20 years and no one is running it on modern networks

RIP is quite a simple routing protocol to be implemented, and can be found from lots of routers. It is still available from modern routers, even modern networks prefer other routing protocols.

I'd say RIP can be easily deployed rather than obsolete.

Would a port be acceptable? I could extract it into its own repo as a basis for a distfile for use with USE_GITHUB plumbing.

[ziaee]

In D50292#1147390, @cy wrote:

In D50292#1147383, @zlei wrote:

RIP has been obsolete for over 20 years and no one is running it on modern networks

RIP is quite a simple routing protocol to be implemented, and can be found from lots of routers. It is still available from modern routers, even modern networks prefer other routing protocols.

I'd say RIP can be easily deployed rather than obsolete.

Would a port be acceptable? I could extract it into its own repo as a basis for a distfile for use with USE_GITHUB plumbing.

Sir we did already joke that you would say this.

[des]

sbin/routed/routed.8

54

The deprecation notice is usually placed in a separate section preceding the description, cf. rGf710a4de92c1 or rG68a930d8ee35 (the latter also being an example of a deprecation which was later rescinded, supporting @kevans's point that we can always change our minds).

[ivy]

In D50292#1147383, @zlei wrote:

RIP is quite a simple routing protocol to be implemented, and can be found from lots of routers. It is still available from modern routers, even modern networks prefer other routing protocols.

it's true that many routers support RIP, but this doesn't mean RIP is actually in use beyond a tiny, niche userbase, and that audience would be better served by a modern, well-maintained RIP implementation (such as BIRD) rather than relying on old routed which is not really being maintained at all.

it's not like, after this change, no one will be able to deploy RIP on FreeBSD, it's simply that we won't be carrying a RIP implementation in base. we're long past the days when it was expected that a host operating system would come with RIP as standard.

[adrian]

it's not like, after this change, no one will be able to deploy RIP on FreeBSD, it's simply that we won't be carrying a RIP implementation in base. we're long past the days when it was expected that a host operating system would come with RIP as standard.

A long time ago, in a galaxy far, far away, a lot of stuff like this was tightly bound to the OS due to APIs being very kernel specific, and you didn't want those to get out of sync.

We're far past those days, and having it as a package to install + all its tools and whatever tests people feel like writing against it would imho be pretty beneficial.

[ivy]

move deprecation notice to a separate section; add a specific version (16.0)
for removal.

[ivy]

In D50292#1147390, @cy wrote:

Would a port be acceptable? I could extract it into its own repo as a basis for a distfile for use with USE_GITHUB plumbing.

i was intending to do this myself when the time comes to actually remove it (which i'm not in a hurry to do - that won't be until after stable/15 branches at the earliest), but if you want to do that i don't mind.

[ivy]

sbin/routed/rtquery/rtquery.8

28

you are free to argue against removing routed, either now or at any time prior to its actual removal (at which point i will probably bring this up on arch@ again)—that said, in the two (?) previous threads about this, i'm not sure we ever found anyone who is using routed.

if someone can demonstrate there are enough users of this code to justify the overhead of keeping it around (considering it runs as root, processes network data, and has been long superceded by modern routing daemons available in ports) this would change the discussion...

[cy]

In D50292#1147390, @cy wrote:

In D50292#1147383, @zlei wrote:

RIP has been obsolete for over 20 years and no one is running it on modern networks

RIP is quite a simple routing protocol to be implemented, and can be found from lots of routers. It is still available from modern routers, even modern networks prefer other routing protocols.

I'd say RIP can be easily deployed rather than obsolete.

Would a port be acceptable? I could extract it into its own repo as a basis for a distfile for use with USE_GITHUB plumbing.

Let me know before it's removed. I'll export its commits into its own git repo and create a port for it.