More questions on how to join the data

Daniel, Tony,

  Yesterday we'd suggested a two approaches for merging the combined
RIPE and Merit Registry Pilot databases:  either by our FTPing files,
or via putting up servers.  We've done some more thinking about how
this needs to work (which so far has involved a lot of guessing at
how your software works).  I've got a couple simple questions about that;
and then there's a rather larger section below sketching out some
implications and tradeoffs.  In a third message, I'll pass on some
questions Andy has about his project to "see how far he can get at
bringing up the RIPE db on a Merit machine tomorrow".

----

  The simple questions are about the "whois" approach.  As I type this,
the list is beginning to look longer than "simple", but I'm doing it
first because we feel we have a better handle on what these options
would involve, since we currently know little of RIPE's internal
software architecture.

    1) prtraceroute seems to get all its data via the RIPE whois
       server.  Is this true?  Is it also true of all the other
       pr*tools?  (or do some of them go elsewhere for their information:
       e.g. to ftp'd versions of ripe.db, or compiled versions, etc.
       Do the non-user tools also work this way?  (E.g. does your
       mail parser do verifications that require a local copy of
       ripe.db, or does it get all of its data through whois, too?)

    2) The prtraceroute command has a "-h <host>" flag in the manpage.
       Does this work?  Could it be used to cause prtraceroute to 
       look to a Merit whois server for all of its information?
       (Andy though he saw something in a ReadMe file that said this
       wouldn't work).  Would it work for all other pr*tools, too?

*IF* this general approach would work, it would have the great advantage
of reducing the number of questions that we would have to be bothering
you with;  we could do our database developments more independently than
if we were sharing full or nearly-full code.  (On the other hand, if we
both do take the approach of communicating closely and sharing a lot
of code, there are definite advantages to that approach, too).

Within this "separate whois" approach, there are a couple of options for
"combining" our data with yours:

     1) Modifying the pr*tools so that they look first at one place
	(e.g. RIPE), then look at the other(s) if they do not find
	the information they are looking for.  This avoids having to
	change the RIPE whois server, but it probably leads to 
	poor heuristics about where to get data and poor network
	usage.

     2) Modifying the RIPE whois server so that it polls other
	whois servers when it does not have the needed data locally.
	This would be transparent to users:  RIPE would seem to have
	all information.

     3) Rwhois philosophy:  RIPE whois server is still the "top"
	"root-level" server everyone uses, but RIPE whois may send
	redirects to modified pr*tools which would then make additional
	queries themselves to other rr tools.

     4) Any of the above, but with RIPE, Merit, (and others?) all
	acting as possible "root" servers, which would refer queries
	they cannot answer to other servers.

----

And then there is the main opposing architecture, which Daniel said he
preferred for the short run:  FTPing all into to RIPE, which would
continue to be the sole info server.

Question 1:  Do you all ready have this problem solved?  (In which case
we can stop thinking about it?)  If there are all ready RIPE-clones
gathering data anywhere, and you all ready have the solution designed
to combine their data with yours, then we should probably just join in
that solution.

If not, here are some questions we came up with this afternoon:

Which file(s) would you want to recieve?  One big "ripe.db"-like file?
One for ASs, one for nets, etc?

What would you want to do about guarded attributes?  One strawman
implementation would be for us to create logins for each AS on a
machine here, which would have the same semantics as the ones that
you create.  Each night (or whatever) we would send those to you,
and you would put them into identically named accounts on your machine
(if this is the way that your software expects the data to be stored).
Or:  there are an awaful lot of more elegant ways to achieve this
result, but they might require more modifications to existing software.

What levels of validation and syntax checking would you expect to be
performed before you received the data?  If we were running your software
as a front-end, then we might have your same validation software
automatically.  Does that validation software require that the entire
ripe.db be on a local machine?  (Same question as above).  (If it just
does syntax checking, probably that can be done without access to
other db information).

--------------------

Any ideas about how to work out these kinds of issues?  Again, if you
all ready know how this should be done, we'll just use your solution.
Perhaps we could look at a conference call early Thursday morning 
US time (late Thursday afternoon your time), if we manage to get much
of a look at your code tomorrow.




-------- Logged at  Wed Feb 16 00:48:51 MET 1994  ---------