[address-policy-wg] Cleaning up Unused AS Numbers

Dear colleagues,

Thank you for the feedback and questions.

We do want to emphasise that the goal of the suggested project is not to 
reclaim AS Numbers that are in use, but to clean up out-of-date 
registrations. At the moment, there is not really an incentive to return 
unused AS Numbers, because the registration of ASNs is free of charge. 
We see quite often that (sponsoring) LIRs forget AS Numbers if they are 
requesting changes.

Our current proposal is a one-time project and we will archive the 
responses so that we only send one email. Some people suggested that we 
should perform these checks on a regular basis and this is possible if 
the community wants us to do so. During Assisted Registry Checks (ARCs), 
or if an ASN is changing sponsor, we already ask to some extent if the 
resources are still needed.

The reason for contacting the sponsor and not the admin-c or tech-c is 
that the sponsoring LIR has the responsibility to liaise with the End 
User (and can do this in the language of the resource holder). From 
experience, we know that a lot of End Users are not aware that AS 
Numbers are distributed by the RIPE NCC, they are only aware of the 
contractual relationship that they have with their sponsor. During the 
deregistration process, we try to the contact the resource holder 
directly in different ways. This usually starts by contacting the 
admin-c and tech-c.

Please let us know if there are any further questions before Thursday 6 
April 2017.

Regards,

Laurens Hoogendoorn
Registration Services
RIPE NCC



On 23/03/2017 13:18, Laurens Hoogendoorn wrote:
>
>
> Dear colleagues,
>
> As previously mentioned at RIPE 73, we are planning a project to clean
> up unused AS Numbers. You can find this presentation here:
> https://ripe73.ripe.net/archives/video/1456/
>
> According to ripe-679, "Autonomous System (AS) Number Assignment
> Policies" if an organisation no longer uses as AS Number, it should be
> returned to the free pool so it can be reassigned:
> https://www.ripe.net/publications/docs/ripe-679
>
> There are currently around 6,600 ASNs in our service region (held or
> sponsored by 2,682 LIRs) that are not being advertised in the routing
> system. This represents around 22% of the ~30,000 ASNs assigned by the
> RIPE NCC.
>
> There are a number of legitimate reasons why an ASN might not be
> advertised in the routing system. However, it is also possible that
> the holder doesn't exist anymore or the ASN is no longer needed. Not
> only should unused ASNs be returned, but it's important to clean up
> out of date registrations, which affect the quality of data in the
> RIPE Registry.
>
>
> Our Proposal
>
> We plan to email the LIR or sponsoring LIR for each unannounced ASN
> and ask if the resource is still needed. We will group together ASNs
> that are sponsored or held by the same LIR to minimise the number of
> emails.
>
> We will ask if the ASN is currently being used or if there are plans
> to start using the ASN in the coming three months. Organisations can
> always request a new ASN in the future if they need one.
>
> If we do not receive a reply or if the ASN will not be used within
> three months, we will start the process of returning the ASN to the
> free pool. The deregistration process will take three months, during
> which time the LIR can still indicate that the ASN is needed. If the
> ASN is still needed, the validity of the assignment (such as the
> multihoming requirement) will not be re-evaluated.
>
> We do not expect any significant cost or impact on other services, as
> most of this process will be automated and we will not need to
> re-evaluate the assignments. Contacting all relevant LIRs will take
> less than six months.
>
> Please review this proposal and send any comments or other feedback
> before Thursday 6 April to <address-policy-wg at ripe.net>.
>
> Regards,
>
> Laurens Hoogendoorn
> Registration Services
> RIPE NCC
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20170403/865e6c6f/attachment.html>