Gordon, You write: --- On december 14 Elise gerich wrote to the above recipients: Some of the information in the RADB is "historical." It was carried over from the PRDB for purposes of the transition from the NSFNET Backbone Service to the current US Internet Architecture. The RA team has been working with CA*net and ANS to reduce duplicate route objects which are artifacts of the transition. Several months ago, approximately 3000 routes were deleted from the RADB because CA*net worked with us to identify which routes were now being maintained in the CA*net DataBase. Approximately, 1000 route objects have been deleted as a result of a request from ANS more recently. Approximately 20% of the route objects that existed at the time of the transition have been removed. COOK: So when you say 20% of the routes have been removed, how does one judge what remains that is defunct and still remains to be removed???? Of the 80% does anyone have a clue as to whether 95% of the 80% are "good" or whether the real total of good routes might be on 50% of the 80%?? --- One of the interesting things about the Internet Routing Registry (IRR) is that it is really just a database of databases. One of the component databases is the RADB. Other component databases include the ANS database, the CA*net database, the MCI database, and the RIPE database. Some tools which use these databases apply a preference in terms of trust. ANS configuration generation tools, when using the IRR, trust components in order of ANS, CA*net, MCI, RIPE, and the RADB, treating the RADB as repository of last resort in some sense. This is not meant to devalue it as a useful component so much as to apply perspective to the relative integrity of each piece of the system. I believe that there is a natural incentive for providers to keep their own customer routing information up to date. For historical reasons stated above, I think that the RADB in particular is going to be relegated to "last call" status for some time to come. CA*net and ANS have cleaned duplicate or bogus objects from the RADB database, and have replaced them with objects in our respective databases. I'm not sure of the status of MCI's effort in this regard, but we rely on MCI's own (clean) database when handling MCI customers as noted above, so it just doesn't bother me that much. Similarly, because we treat the RADB as last resort, the % of good routes doesn't bother me in any excrutiating way, though of course I'd prefer for it to match reality more than it may today. Multihomed customers are a bit tricky, but for now that can be solved by open communication among providers, or between provider and customer. Some of the tools which make use of the distributed database model are a bit lean, a bit immature. However, improvements will come in time. There are new tools to deal with more realistic aut-num's, new policy specifications to deal with real life ISP policy implementations, and new database code to deal with distribution in several ways. Some are in test, some are in production, but all are improving. It's fair to say that those registries which are more natural and comfortable for folks to use should reasonably be favored over emotionally incorrect or truthfully inaccurate repositories. Personally, I think that some hierarchical system may scale quite well, though deciding the hierarchy will be fraught with the same difficulties as was BGP-1, for example (who's closer to the top?). For now, provider-specific registries, to the extent that there aren't so many, seem to be doing the job in North America (due to natural incentives), while the RIPE registry seems to be doing the job in Europe (due to traditional comfort -- some research abroad may help to clue me in :-) ). My opinion... Steve