[address-policy-wg] Guidance Requested: Reassigning Referenced ASNs

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