Special ftp access for IRR?

 bmanning at ISI.EDU writes:
  * > 
  * > The medium term soloution as discussed in San Jose:
  * > 
  * > Update arrives. 
  * > 
  * > If not the proper server, forward it there.
  * >
  * Oh yeah, I forgot this one too.  There is the small problem in the US where
  * people are being asked to register in multiple .db's since they have 
  * several connections and the various providers can't or won't trust the
  * "other guy".  MCI has the policy that you must register in their .db.
  * It will be interesting to see how this plays when/if MCI enters the Euro
  * market.  Then their clients will need to register in the RIPE.db and the
  * MCI.db, just they way they are asked to in the US.  
  * 
One should be careful when stating other companies policies. MCI went this way
(the way of NSF I might add) becuase the RADB was not ready and still isn't
in the sense that there is little information in there. It is also not accurate
as we accept CA*NETs data directly. The question is not trust but having useful
information that allows you to configure the net, the RADB doesn't have this.

On the general issue of dfk solution, I do not believe forwarding updates
around scales at all and also from a service aspect places a reliance on others
to do the right thing which right now is probably not such a god idea unless
we get strong agreement on authority of data. This get harder as more RRs 
come into play.
The actual data maintenance of the files is fine though providing it can be
automated  and can have the needed notification of change built in.

		--Tony.




-------- Logged at  Tue Feb 28 17:35:17 MET 1995  ---------