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 ---