Dear Andrei,
you wrote that there will be problems creating duplicates of aut-nums and
routes in other registries if they do not formally belong there due to the
authorization rules introduced with the RPSL transition at RIPE. You
suggested two solutions:
> Possible solutions to this problem are:
>
> 1. Send such registration requests to the Database Administration
> (ripe-dbm) who will perform registration by overriding security (and
> performing necessary checks before). This puts additional load on
> ripe-dbm and creates duplicate objects in the RIPE database and
> "foreign" IRR.
>
> 2. Do not allow such registrations. In this case some ISPs will need to
> change their peering policy and accept routing information from a
> "foreign" IRR.
>
> Your comments and suggestions are highly appreciated.
>
I did not yet see an answer to your question. However, I believe that your
first suggestion should *not* be followed. I definitely would want to avoid
opening "side" paths to enter data into the RIPE database. Using ripe-dbm
should be the exception for special requirements. For everything else, the
robots should be used.
Regarding duplication: this had originally been introduced to help people
along while mirroring was not working. With RIPE having transitioned to RPSL,
we will have compatible formats again, and do not need duplication anymore -
under the prerequisite that you are properly coordinating with RADB and any
other major IRR. I am inclined to say, that avoiding duplication is the
purpose of the effort!
Looking at your second proposal, I believe that you are saying the right
thing, but phrased it a little different. Peering policy is probably a term
which may be confused with routing policy - and nobody needs to change its
routing policy by looking at several IRRs now. Actually, I believe that there
is not much of an issue: Smaller ISPs have always registered in only one IRR;
only bigger providers with international reach have entered their information
into several IRRs and duplicated data, but then also using data from all IRRs
they registered into. It should not be too much of a pain to use this
information to continue with this practice after the RPSL transition.
Those parties who do not agree, speak up loudly now!
Thanks
Joachim
--- JS395-RIPE -- standard disclaimer ---
