In message <[email protected]>, Kaveh Ranjbar <[email protected]> wrote:
>- RIPE NCC has operated RIPE IRR as an open IRR based on community >requirements for years. In my opinion, a very productive first step >towards better data quality and maintenance of RIPE IRR is for the >community to provide RIPE NCC with an operations policy for RIPE IRR. >At the moment there is no policy governing RIPE IRR... >... > * Many operators only look into RIPE IRR and/or RADb and ask >their users to register their routes in one of these databases before >they can serve them, no matter in which region they are located. This >might not be the best practice but it is the reality. Looking at IRR >query load, RIPE Database IRR by far surpasses other RIRs routing >databases... Please forgive me. I am ignorant of much or all of the history relating to these matters, so your comments are both highly educational and highly appreciated, by me, at least. But I'm still trying to wrap my arms around what, it seems, you just said. If I have understood you correctly, you are saying that RIPE NCC has, for some very long time now, been operating its own IRR with -zero- guidance or instructions on how to do that from the community, -and- that this IRR... constructed and maintained with -zero- community input or guidance... has become, within its lifetime, the defacto ``standard'' IRR for the all of planet earth?? >This means, restricting RIPE IRR might have a negative effect >on documentation of routing data... You say that like its a bad thing. With respect to the various routes hijacked by AS201640, I think that the world would have been a better place if the RIPE IRR had not, in effect, endorsed the legitimacy of those. (Note that this veneer of legitimacy was also subsequently imported into the MERIT RADb... from RIPE.) > * In many cases the ASN comes from one region and IP Prefix >comes from another. Requirement from some IRRs (including RIPE's) to >include auth. for both ASN and IP Prefix only makes things more complex... Welcome to the 21st century! Life is complex. I don't believe that it becomes less complex if we simply try to sweep the complexity under the carpet, e.g. by performing only incomplete and clearly inadequate verification of the legitimacy of route objects being added into the data base. >It is possible to interlink RIR auth. systems, it is possible to >interlink RPKI and IRR, it is possible to mark resources with an auth. >quality indicator, etc... As I attempted to point out in my prior two postings, the things you just mentioned, while perhaps admirable for other reasons, all seem to me to be technological overkill when it comes to solving what is, at base a quite simple problem, i.e. obtaining the consent/endorsement of the actual IP block registrant before a route object is entered into the RIPE IRR data base. That consent/endorsement can be obtained, via a simple automated process, essentially identical to the one used for signups to this very mailing list, where the request for approval is e-mailed to the contact e-mail address for the IP address block in question. If this simple solution would not have worked to thwart the malevolent ill intent of AS201640 with respect to the RIPE IRR, or if it would be at all difficult to implement, then I, for one, would appreciate it very much if you would explain why. Regards, rfg
