Sascha Luck [ml] wrote:

How does this fact falsify the fact that cross-RIR route: objects exist? Those have to be in *some* irrdb and as long as a cross-RIR irrdb doesn't exist, part of the data will be non-authenticated...

it doesn't say anything about cross-RIR route: objects, and you're correct to point out that parsing IRRDB objects is difficult to do well. There are a couple of different approaches which we have found to work reasonably well in practice. One is to use whois.radb.net and carefully specify the source: list. Another would be to run your own private whois server and get NTRM copies of the IRRDBs that you're interested in. Another still (the version used in recent versions of IXP Manager) is to poll the IRRDBs for the list of objects you're interested in, then select them in a local db of some form. This gives very high performance, high flexibility / functionality, but comes at a cost of more coding. Defaulting to using whois.radb.net is a reasonable compromise, but it has its limitations. In other words, removing foreign route objects from any specific irrdb doesn't change any requirements for your irrdb code, because if you're pulling in irrdb prefix lists from arbitrary ASNs, there is already a requirement to poll multiple irrdbs. If your irrdb polling mechanism doesn't handle this, and doesn't support the option to have per-peer IRRDB policies (for both whois servers and source: specifications), it will break. We tried it and ran that particular boat up on the rocks. Nick