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

Sonderegger Olaf ABRAXAS INFORMATIK AG wrote:
> Hi all

In general I support the recycling of AS #s,
but for operational and consistency reasons I'd be a bit more careful...

> Based on Randy's proposal:
> 
> 
>>inform owner of dangling reference.  wait a week.  inform again.
>>wait a month.  inform again.  wait a week.  remove dangling reference.
>>wait a month to see if anything has broken enough to get the attention
>>of folk who do not respond to email.  reassign AS number.
> 
> 
> In my point of view, it is enough to inform once. Members have to update
> their information, members have to be contactable by e-mail.
> 
> So:
> 1.      Inform owner about its wrong objects (only once).

ACK, although we may want to do a little bit more than just once,
depending on the "failure mode" of the communication attempt.

In particular, if the notification by email cannot be delivered, I'd
suggest that the "member relations role" should follow up immediately.

Depending on the outcome, we may try the alert again or take other,
more serious steps as foreseen when a member[1] cannot be contacted.

> 2.      If an owner doesn't clean up its objects, RIPE NCC should be able
>         to clean up by itself after a month.

While I do see the beauty of this approach, we may actually add to the
inconsistencies between assignment reality, documentation and operational
reality.

Note that over the last few years we made changes to the behaviour of the DB,
aka Registry, which make it more and more likely that the "authoritative copy"
of an object is kept locally. So, even if the NCC modifies an object, it may
easily be recreated/updated to the old "wrong" state.

> 3.      Re-assign AS numbers after two month.

Relative to the completion of the alerting exercise.

With the caveat that those AS#s should be recycled first which are "clean",
assuming that the stockpile is big enough to satisfy the requests.

> Best regards,
> Olaf Sonderegger

Wilfried

[1] "members" to be interpreted as the tree of members/LIRs own resources,
    as well as sponsored end user assignments