I assume one of the RA folks will respond to this if they see fit. However:
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.
You appear to be conflating the RADB and the RSes. The two are separable.
You can use the RADB (or, more generally, the IRR) w/o having to trust the
I think this is a really important point, and one which a lot of people
seem to be confused about.
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
This has long existed for the NACR process.
(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
It should be secure.
Is PGP secure enough for you?
RADB should be able to implement _existing_ routing policies,
not the subset which can be defined in RIPE-81 (it currently
RIPE-181; it's different. Some people have complained that RIPE-181 is
also incapable of expressing their policies; perhaps someone from the RA
team can comment on how they intend to address that.
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.
Which is already a big win, seeing as how there are a good number of
particularly obnoxious peers out there, some of them quite large.
I have to ask if you have actually looked at the RADB and surrounding
pieces at all. I think it addresses a number of the gripes you have