High-level thoughts (Tuesday edition)

Folks,

what follows is top-of-the-head stuff to give you information because 
I am pressed for time. Architectural thinking may follow later.

  > "Dale S. Johnson" <dsj at merit.edu> writes:
  >   On the general side, we've got the following objectives for this 
  > routing pilot project:
  > 
  >       - Seamless interoperation with RIPE tools across all ASs
  >       - Get the pilot up extremely quickly
  > 		Then, for the longer run:
  >       - Share code, projects, etc. with RIPE as appropriate
  >       - (long term) maintain ability of RIPE and Merit to add local
  > 		functionality to seve non-mutual requirements.

Correct.

  > Would you guys be interested in doing some joint development down the
  > road, assuming coding needs worked out?

Yes, if it makes sense by all means. I thought that was clear.

  > One of the obvious options for us to get RIPE-compatible functionality
  > running quickly would be for us to take your system and run it here.
  > At first glance, does that seem like a reasonable plan to you?  

Very much so.

  > Has it > been done before?  (e.g. has anyone else gathered all the pieces
  > necessary to run a full local RIPE implementation yet?)  

Yes and no. We have several replicated databases. Noone is using all
the automatic updating components. Also the current software distribution
is "beta" status because there is no documentation on 
installation and operation.

  > Assuming you
  > are willing, we'd like to grab a copy of your stuff and see how far we
  > can get at bringing it up tomorrow.  I know the pr*tools are available
  > for anonymous FTP.  Is the full source there as well?  If not, is there
  > a way we could get at the code?  (A guest account, or some such?)

ncc.ripe.net:~ftp/dbase-beta/dbase-beta.tar.Z
(directory not readable, file is retrievable)

This is still lacking some of the guarded attribute stuff but should give
you an idea about what effort it will take to get it up and running.

  > Also, to get some feeling and operational practice in this, we thought
  > it might be useful for us to join the RIPE db as an NSP.  
  > Some day not
  > too far away we'll want to get AS 690 represented (at least as much as
  > possible), but for now we wondered if we could register as AS 689 (the
  > NSFNET Test Net AS).  This would let us try entering various policy
  > descriptions, nets, etc., , but it should not interfere much with
  > anybody's actual processing since none of your ASs will have any
  > interactions with 689.  Would that be ok?  

Very much so.

  > How can we set this up?

Send the as-object to <ripe-dbm at ripe.net>.
It will show up with source: RIPE for the time.

  > Any cautions about kinds of data not to enter?  (Is there any
  > standard text you send to new ASs who would like to register with you?)

There is an AS numebr application form in the doc store with some
boiler plate info. ripe-81++ holds.

  > We've just come across RIPE-108, which seems like a pretty crucial
  > document for us to read to understand your system.  Are there others
  > you'd point us to?  (besides RIPE-81++?)

We would like to be able to point you to a recent one about the database
per se. But that is in the works and there is no draft worth speaking
of yet. Get the old ones. See ftp.ripe.net:ripe/docs/ripe-docs/ripe-index.txt



Daniel



-------- Logged at  Wed Feb 16 09:47:17 MET 1994  ---------