"Export dbm" program

Cengiz,

> Dale S. Johnson (dsj at merit.edu) on December 13:
> > What I was thinking about was the public ftp repository:  the place folks
> > go to get data is they want to do some analysis (like the PRDB reports 
> > files).  If this is only updated once per day, then you have an annoying
> > average-of-twelve-hours-out-of-date problem.  But suppose this file in
> > the anonymous ftp directory was actually the file that the registry ran
> > off:  the one that dbupdate updated.  Then whoever got ftp'd this file
> > for making reports would have absolutely up-to-date information.  (With
> > the caveat that his info might be so up-to-date that there's a half-finished
> > record written at the end of the file).
> 
> Dale,
> 
> I do not see the point in doing this. As we discussed, one can not
> achieve synchronisation by simply keeping the ftp copy more
> up-to-date.

  Yes, I exactly agree with you (and Daniel) about synchronizing the
databases within the IRR.  My issue is about something else.

  It is useful to make bulk data available to general users on the
Internet.  Engineers use this for sanity checks against their own
config files, for ad-hoc analysis (e.g. "How many aggregates are
there?"), etc.  The PRDB supports this through a variety of reports,
including "net-comp.now" (the most popular) and "nets.unl.now" (a dump
of all fields relating to networks in a machine-parsable format).  The
RIPE system supports this same function by making the *.db files
available for anonymous ftp.  If you want to (for instance) count the
number of A's B's and C's in the world, you ftp their database and run
you script on your machine.  There is a sentence somewhere in the RIPE
documents that says they don't do other reports because reports are so
easy to generate off their .db dump.  This dump of data is a basic
end-user deliverable of the system, quite independent of anything that
the members of the IRR need to have in place to achieve their own
synchronization.  It is this function that I am suggesting we make
trivially up-to-date where possible by putting the actual db file up
for distribution (rather than a strobed copy of it).  [Actually, the RA
has a technical difficulty with this:  for security reasons, we do not
want to run anonymous ftp or NFS mounts on the production machine, so
the actual production .db file is not on-line to the ftp machine.  But
maybe we can work something else out;  perhaps kerberos NFS].

> Also the format of the ftp'able database and one in production may
> differ (some parties may use informix for example).

Yes, you're right that the internal format does not have to be the same
as the external ftp'able exchange format.  However, it means that if
you *are* running the RIPE software and you do use a symlink to make
the ftp'able copy be the real internal copy, then you can build a more
responsive system than if you use another approach.  [This is another
reason I'm not attracted to using an RDBMS to rebuild RIPE.  The PRDB
program that dumps just the nets now runs for a full hour, and thats only
for 43,000 nets.].

> If you want more up-to-date copy of the database, just play the deltas
> to the copy of the database you have locally.

Yes, this is the best approach for members of the IRR.  But if you are
just Joe User and want to do some data analysis, though, it would be
much nicer to just ftp the thing and get the up-to-date copy, rather
than be required to install the portion of the 181 database engine that
knows how to apply the deltas, and to go through that whole initial-plus-
deltas procedure.

> Cengiz
> 
> -- 
> Cengiz Alaettinoglu       Information Sciences Institute
> cengiz at isi.edu            University of Southern California

--Dale



-------- Logged at  Tue Dec 13 23:15:34 MET 1994  ---------