Hi Andrea, group, On Mon, Jul 01, 2013 at 12:33:39PM +0200, Richard Hartmann wrote:
I don't think anything should be changed by RIPE NCC, objects need to be updated by their respective maintainers. In the best case, objects are recreated from scratch locally whenever an update occurs, rendering this moot. In the worst case, automated systems that do Weird Things (tm) will malfunction in interesting ways.
Things need to be balanced here. A 'route:' object referencing a re-assigned ASN can cause problems for the new holder if their upstreams generate ACLs based on ripedb information. It's not feasible to leave these ASNs "blocked" forever. OTOH, gratuitiously deleting these objects can cause breakage for the holder of the referencing object (for the same reasons), possibly hops away and thus very hard to troubleshoot.
* When ASn is being deregistered, automatically email anyone who's responsible for an object that references this ASn * Once ASn is actually deregistered, send out automated email * Once grace period is over, send out automated email * Once ASn is reassigned, send final automated email
+1 but: if no reaction to the final email, delete any 'route:' object referencing a returned ASN. There is a possible race condition here between "old/invalid" and "new/valid" 'route:' objects so the deletion should happen some time before the re-assignment. As for the issue of provisioning systems re-creating a removed 'route:' object, does the creation need to be authenticated by the ASN mntner? If not, could this be required to forestall such automatic re-creations? Finally, I'm not sure about treating policy statements in 'aut-num:' objects the same way. Is the presence of those actually an operational issue? I would certainly be opposed to simply deleting an aut-num object just because it contains an obsolete neighbour ASN. rgds, Sascha Luck