Proposal for adding external repository reference to import/expor t attributes

Hi, All,

I think it is time we start to implement the external repository reference
specified in RFC2725 section 9.6

=== Quote Begin ====
9.6  Other Objects

   Many of the RPSL ancillary objects have no natural hierarchy the way
   AS numbers, Internet addresses and routes do have a numeric
   hierarchy.  Some examples are "maintainers", "people" and "role"
   objects.  For these objects, lack of any hierarchy leads to two
   problems.

   1. There is no hierarchy that can be exploited to direct queries to
      alternate registries.  At some point the query strategy of
      searching all known registries becomes impractical.

   2. There is no hierarchy on which authorizations of additions can be
      based.

   The first problem can be addressed by considering the name space for
   each of the ancillary objects to be unique only within the local
   database and to use explicit references to an external repository
   where needed.  To specify an external repository reference, the
   object key is preceded by the name of the repository and the
   delimiter "::".  For example a NIC handle may take the form
   "RIPE::CO19".  Currently there is a desire to keep NIC handles unique
   so the naming convention of appending a dash and the repository name
   is used.  Prepending the repository name provides the unique name
   space since an object in the RIPE database referencing "CO19" would
   be interpreted as "RIPE::CO19" by default, but it would still be
   possible to query or reference "IANA::CO19".  There is no possibility
   of accidentally forgetting to adhere to the conventions when making
   an addition and the existing objects are accommodated, including
   cases where name conflicts have already occurred.

=== Quote End   ====

Some background: 
As an ISP we constantly are in the need to find other ISP's routing policy
from other registry. 

Currently we have to do either the following actions:
1. Move the object into our registry.
2. Duplicate the object in our registry.

Solution 1 is appropriate if other ISPs own the object but sometimes they
have no authority over the object or they don't want to move the object at
all (usually a peering ISP).

Solution 2 have several problems:
1. The owner of the original object most likely will object to have
duplicate in our registry.
2. If the owner has no objection, the duplicate object will gradually become
out-of-sync.
3. It is almost impossible to avoid name collision. For example
"AS-CUSTOMER" is a very popular as-set name, if there is an "AS-CUSTOMER" in
our registry already then we have to add ASN to the name to become
"ASN:AS-CUSTOMER". Then not only we have to duplicate the as-set object we
also have to duplicate aut-num, person-role and all the associated objects
as well ( quite a mess really ). 
4. How do I know it is an original or duplicate ?


Now the proposal:

To implement "::" delimiter to support external repository reference.
In a limited scope just to add "::" delimiter to the
non-database-integrity-impacting attributes.

The first to consider is "import/export" attribute.
For example:
import: from AS12345 accept   RIPE::AS12345:AS-CUSTOMER
export: to   AS12345 announce AS3561:AS-CUSTOMER

This won't affect the database beckend too much.
Then the ISP can use their own tools or IRRToolSet to build configuration
using the information from the external registry directly.



Your opinion is well appreciated. Thanks.


Ping Lu
Cable & Wireless USA
Network Tools and Analysis Group
W: +1-703-292-2359
E: plu at cw.net