More questions on how to join the data
Dale S. Johnson
Wed Feb 16 00:40:50 CET 1994
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 ---------
[ rr-impl Archive ]