Well, there is a big _if_: if things will work w/o RADB (and they will, for no sane provider will use RADB as the sole source of exterior information at peering points, not for at least before it became the proven and stable service) -- people will forget to update things, cut the corners, etc. NACRs were so big headache that our implementation people dance around when they hear that there won't be any NACRs. RADB got to be easy to use to become real. The e-mail interface of NACRs is close to uselessness, and too big headache to deal with. Waiting time on processing is simply ridiculous. There should be a host accepting telnet sessions for on-line updates (which have to be installed *immediately*, so whoever added a network can test connectivity and go ahead). There should be well-defined and useful interface to service providers databases. It should be secure. RADB should be able to implement _existing_ routing policies, not the subset which can be defined in RIPE-81 (it currently can't, there are places which use a lot of _very_ hairy stuff). Without that i do not see RADB being successful or useful beyond the point of filtering updates from particularly obnoxious peers. --vadim From: Guy Middleton <guy@ghost.uunet.ca> To: avg@sprint.net, curtis@ans.net, jerry@fc.net Subject: Re: Has PSI been assigned network 1? Cc: nanog@merit.edu, prs@isi.edu Message-Id: <95Apr18.213028edt.53028-1@ghost.uunet.ca> Date: Tue, 18 Apr 1995 21:30:28 -0400
Curtis, you are able to do that only because all others were legally bound to fill your database.
I'm not sure people will be spending their resources on populating database for somebody else's benefit.
(And RADB already has lots of garbadge in it).
Once the RADB is in general use, we can expect that networks other than ANS will use it to generate route-filters. There is an interconnect point already using the CA*net registry, for example. Any active use of the RADB creates an incentive to ensure that it is accurate.