RPSL automation

[Nick Hilliard]

On 12/05/2009 09:41, Shane Kerr wrote:
> At the RIPE meeting last week, there was some brief discussion about the
> IRRToolSet. After the working group, I was chatting with Andrei
> Robachevsky, and we both agreed that the IRRToolSet is big and
> complicated and does a lot more (and less) than what people want.

I think we're talking about two separate things here.  On the one hand, 
there's IRRToolSet, which packages a certain amount of interesting 
functionality buried in a deep mound of mature and rich fertilizer.  On the 
other hand, there's the whole concept of RPSL and what it does and doesn't 
do for us.  I don't really want to get into this debate right now because 
it's difficult and has political implications which touch lots of different 
organisations, including the RIRs, the IETF and a pile of companies around 
the world.

However, here's my take on IRRToolset:

- there seems to be some consensus that peval and RtConfig are generally 
useful and should be maintained.

- rpslcheck compiles and appears to both work and be very easy to maintain, 
clocking in at a mere 6k extra code.  It is of marginal use.

- prtraceroute provides some interesting functionality which isn't provided 
by normal traceroute, but it appears to be substantially responsible for 
using huge chunks of completely unmaintainable and system dependent code in 
libCore. Thing is, who's actually going to use prtraceroute?  Someone 
debugging someone else's routing policy several ASNs away?  Fascinating 
stuff, no doubt, but seriously do we need it?

- prpath: causes less pathological problems with the codebase, but again, 
how necessary is this?  Has anyone noticed that it's been broken for most 
of the last 10 years?

- CIDRAdvisor: useless in today's world.

- aoe / roe: very limited use.  Most people who use peval / RtConfig are 
going to have scripted aut-sys objects, so aoe is of very little use to 
them.  roe's capability to read bgp dumps and do semi-sensible things with 
them is vaguely interesting, but to be honest, screen-scraping the output 
of "show ip bgp" commands is never going to be anything more than brittle. 
  There's also the issue of TK, which was never much of a graphics toolkit 
to start with (and seriously, it's 2009 now - it had its day in the mid 
90s).  These tools might be of some vague use if they were web based, but 
if you were going to webify them, you wouldn't use C++.  Or librpsl.  Or 
any of IRRToolset really.

librpsl: basically useful but contains cruft.  Need to remove crap from 
src/rpsl/gnu/ directory.  May be useful to libtool-ify this and separate it 
out from the distribution a little.

libCore: fascinating stuff in here.  Most of it almost completely useless, 
but quite fascinating all the same.  Cruft force 12; should consider 
renaming to libCrap.

I would therefore humbly suggest deleting prtraceroute, prpath, 
CIDRAdvisor, aoe and roe from the distribution.  This should allow the 
removal of a large cascade of ancient code from librpsl and in particular 
libCore.

All of the Prcs cruft should also be removed.  The .tar.gz in the root 
directory is corrupt, and none of the other files serves any real purpose.

I've flagged some other stuff which should be removed in:

http://irrtoolset.isc.org/ticket/23

Does anyone have any objection removing these things?

Once this is done, and the distribution has been reduced to a more 
manageable size, we can then start looking at the code, removing weird-ass 
stuff like various old and unmaintained library chunks (e.g. the rx lib, 
rusage, the src/Core/sched directory, and some of the many weird hashing 
and list management libraries that the code base has accreted over the 
years, and the strange i-can't-believe-it's-not-libiberty sort of stuff 
that's going on to deal with prehistoric operating system dysfunctionality. 
  This will tighten up the code quite a bit.

Could we rename "RtConfig" to "rtconfig" - or indeed anything with just 
lower case only?  Please?  I despise those StudlyCaps.

And could someone explain whether we really need to use all of sstream, 
iostream, strstream, stringstream, ostringstream, streambuf, fstream, 
ifstream, ostream and ofstream?   Sorry, but there's just something gross 
going on in there.

On a more positive note, what would people like to see in peval and 
RtConfig?  How could these be improved to be generally more useful?

Nick