More questions on how to join the data

  > "Dale S. Johnson" <dsj at merit.edu> writes:
  > ----
  >     1) prtraceroute seems to get all its data via the RIPE whois
  >        server.  Is this true?  

Yes.

  > 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.

Yes. We are contemplating to set up a separate server with a pre-computed
topology map for some of this. So far only preliminary thoughts.

  >        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?)

These need a local copy. 

  >     2) The prtraceroute command has a "-h <host>" flag in the manpage.
  >        Does this work?  

Yes, as documented.

  > Could it be used to cause prtraceroute to 
  >        look to a Merit whois server for all of its information?

Yes.
  >        (Andy though he saw something in a ReadMe file that said this
  >        wouldn't work).  Would it work for all other pr*tools, too?

Yes.

We are planning to implement some heuristics for server selection as well.
We are currently setting up more replicated RIPE databases so we will need
this.

  > *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.

I think eventually you want 4. For the time being I would prefer simple
replication of *all* data at all 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.

That's not what I meant. I mean replicating the info at *all* servers.

  > Question 1:  Do you all ready have this problem solved?  (In which case
  > we can stop thinking about it?)  

No.

  > 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.

The database software supports multiple "sources". What this comes down to
is that the whois server can respond to queries using multiple data sets.
Standard is to use only the RIPE data set. You can also query specific 
data sets or all. Thry whois -h whois.ripe.net "-a 192.87.45" and see
some out of date copies of other sources.

  > 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?

Your choice.

  > 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.

I think this is a good strawman.

  > 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?  

Only the part you are updating I would think.


(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.

OK. I will be out but Tony and Marten are here.


Daniel




-------- Logged at  Wed Feb 16 09:51:35 MET 1994  ---------