In message <m0s33hL-000301C@rip.psg.com>, Randy Bush writes: | 2 - The RADB has a lot of old, now obsolete, data maintained by others. Do | we have to ask each old maintainer to clean it out, or will it all be | cleaned up as the changeover settles down? | | 3 - SWIPs and 81ish objects (and NACRs, but they're going away, yes?) share | a non-trivial subset. Are there maintainers' tools for generating both | from a single database? If not, we will surely create errors of | consistency. This almost but not quite touches on what are (for me) the big questions of the RADB, which are, firstly, in the absence of really easy to use tools that keep router configurations and the RADB in sync, of what use is the RADB, other than as a "this is what things should have looked like a while ago" debugging tool or in the cases of ISPs who configure their routers from the RADB, the most likely reason for not being able to reach network X ("gee, they haven't updated the RADB and therefore you can't get there from here")? Secondly, if the RADB and the world's routers are all in sync, of what value is the RADB as something to protect the world from weird announcements? I don't know the answers to these, and they're not entirely rhetorical questions. | FYI, despite the lack of rigor, Sprint's has seemed (from the bottom of the | pond view) to be the most immediate and reliable over the many moons. Thanks, Randy. We're trying, despite massive screw ups from time to time (fat fingers Doran and so forth). | But the overwhelming problem with all avenues has been the NACR delay. I agree. Looking back at routing problems reported to us over the last several months in such a way that I saw them, the overwhelming majority has concerned the PRDB not being in sync with the rest of the world. The next largest number of routing problems had to do with customers' BGP peerings with SprintLink, and the bulk of those problems involved singly-homed customers. Sean.