Allow me to clarify Curtis's remarks: | > 1 - When can do stop needing NACRs? Monday, i.e. effectively now? | Still need them. A lot of people are typing as fast as they can to | remove this requirement. Code takes time to write and debug. _ANS_ needs NACRs or RADB updates for the time being. If I were in Andrew Partan and company's shoes rather than in mine, I would simply refuse to submit them. Why? Because ANS has this history of centre-of-the-universe arrogance which I keep hoping the newer, nicer engineers there are going to be able to undo and get rid of, even though there are real risks involved in trusting one's peers just as everybody else does. The appropriate way to make routing clean and safe is pointing out problems to one's well-meaning peers and using bilateral and multilateral social pressure against one's more aloof ones. Considering that DREN and DISA have *both* been able to present a pretty clean set of routes to their new peers with a bit of friendly help and some reminders that this is an Important Thing To Do, I think we have existence proof of this. Just as a pair of data points: I was very very very keen on having an RS (or RS-like device) at FIX-EAST last week in order to help with the transition of those two fednets before they cleaned up their routing. I now no longer see a need to continue with the RS for that purpose. The second data point: we (SprintLink) do peer experimentally with the RSes at MAE-EAST, and asked to be given all NETCOM routes given to us from the RS. When I last checked, we were seeing clean information from our direct NETCOM peering, but, as I pointed out to Jessica Yu, there were some glaring problems with what the RS there was giving us. So, in my opinion, as far as a technology to keep routing information clean among big providers, the RSes aren't worthwhile at this time. As far as a technology to keep routing information clean between big providers and small providers at a peering point, imho that is a matter for bilateral agreements and other peer-to-peer and public pressures. The only thing I see as potentially useful with the RSes, unfortunately, is the possibility of working on a solution to The Big Problem, which is keeping routing symmetrical between any two big providers peering at lots and lots of peering points. I see the primary use of a fully populated RADB as a tool for debugging. The fact that you see it as a tool for configuring your network is simply interesting. Sean.