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

Dear Colleagues

Following this thread I see many comments about 'expected' or 
'understood' behaviour of the RIPE Database software. I would like to 
clarify these points with a clear statement of what the software does 
and does not do. In this email I won't touch on any of the issues under 
discussion or suggested solutions. It is just a technical summary of 
business rules.

In general there are very few checks on AS numbers in the various RPSL 
attributes where they can be used. This was a deliberate and intentional 
aspect of the design of the first RPSL based RIPE Database software back 
in the late nineties. At that time it was considered too complicated and 
too difficult to manage any cleanup. If strict rules had been enforced 
without the corresponding cleanup process, it would not be possible to 
delete an aut-num object.

What can be done?

-Only RIPE NCC can create and delete an aut-num object from the ASN 
ranges allocated for use in the RIPE region by IANA
-Anyone can create and delete aut-num objects from non RIPE ASN ranges
-Any ASN can be referenced in any appropriate attribute in an aut-num 
object, regardless of region or if the referenced aut-num object exists
-Any referenced ASN can be removed from an aut-num regardless of the 
existence of the referenced aut-num
-An aut-num object can be deleted regardless of any reference in any 
attribute of any other object (aut-num, route, route6, sets) For example 
AS1 can be deleted even when these objects exist with these references:
     aut-num: AS2
     import: from AS1
     export: to AS1

     route: 1.1.1.1/16
     origin: AS1

     route6: 2001:600::/48
     origin: AS1

     as-set: AS-LIST:AS1
     members: AS1
-An aut-num object can be created regardless of any references in any 
other object
-Any set object can be created referencing any ASN in the (hierarchical) 
set name regardless of the existence of the referenced aut-num
-Any ASN can be referenced in a "members:" attribute of any set 
regardless of the existence of the referenced aut-num


What cannot be done?

-Users cannot (accidentally) delete their RIPE ASN aut-num object
-A route or route6 object cannot be created without authorisation from 
the originating aut-num and address space, or from an exact matching or 
less specific route(6)
-A set object cannot be deleted if an aut-num references it in a 
"member-of:" attribute.
-You cannot add a "member-of:" to an aut-num and reference a non 
existing set
-You cannot remove a mntner from the "mnt-by:" of an aut-num if that 
mntner is a "mbrs-by-ref:" of a set that the aut-num is a member of

Regards,
Denis Walker
Business Analyst
RIPE NCC Database Team


On 14/08/2013 10:47, Ingrid Wijte wrote:
> Dear colleagues,
>
> Thank you for your feedback on this issue. Based on the input we have
> received we propose taking the following action:
>
> - The RIPE NCC will send an email to the maintainer and contacts of the
> RIPE Database objects in which the returned AS numbers are referenced,
> asking for the reference to be removed.
> - The RIPE NCC will send three additional reminders, at intervals of
> three weeks from each other, for a total of four emails.
> - If after four emails the reference is still in place, the RIPE NCC
> will update the RIPE Database object itself, removing the reference.
> - If the reference is being recreated within one month from deletion
> (possibly due to automatic updates), the RIPE NCC will contact the
> organisation through means of communication other than email.
>
> The total number of RIPE Database objects that reference returned AS
> numbers is currently about 2000. All references are in the policy
> attributes of aut-num objects. No route(6) objects are involved.
>
> Thank you again and best regards,
>
> Ingrid Wijte
> RIPE NCC
>
>