<html><head></head><body><div style="color:#000; background-color:#fff; font-family:Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yui_3_16_0_ym19_1_1529009458655_324274" dir="ltr">Colleagues<br id="yui_3_16_0_ym19_1_1529009458655_324369"><br id="yui_3_16_0_ym19_1_1529009458655_324370">During the current discussion on out-of-region ROUTE objects, Job announced that IRRd is being re-written and will have some 'potentially' fantastic features including 'possibly' authentication against the RIRs number registries. The alternative/commercial IRRs have also been heavily promoted at many points in this discussion as 'the answer' to the current problems. I personally, and some others, have some issues with this. So I thought it appropriate to open a discussion on this issue as it does impact on, or is influenced by, the operation of the RIPE Database.<br id="yui_3_16_0_ym19_1_1529009458655_324371"><br id="yui_3_16_0_ym19_1_1529009458655_324372">Firstly it is unfortunate that all the RIRs that operate an IRR may not be in a position to accomodate all routing requirements that are currently provided for by the designed security hole in the RIPE Database at the time this security hole will be closed. To push operators to switch to commercial services as the answer simply monetarises routing which, as Randy pointed out, may affect smaller operators more, as perhaps the IPv4 market has done.<br id="yui_3_16_0_ym19_1_1529009458655_324373"><br id="yui_3_16_0_ym19_1_1529009458655_324374">I looked at the github details of this new IRRd. I get the feeling that this is simply trying to re-invent the RIPE Database software in yet another language. This is being done without the decades of experience, knowledge and understanding that has gone into developing the RIPE Database software on which all 4 IRRs are based that are operated by the RIRs.<br id="yui_3_16_0_ym19_1_1529009458655_324375"><br id="yui_3_16_0_ym19_1_1529009458655_324376">Job also pointed out that "One of the possible (and desired) extensions is an authorisation link to the authoritative RIR." This suggests some form of cross registry authorisation with/between the RIRs. During the years of debate about these out of region ROUTE objects this has been discussed and virtually dismissed on several occasions.<br id="yui_3_16_0_ym19_1_1529009458655_324377"><br id="yui_3_16_0_ym19_1_1529009458655_324378">If the RIRs, and certainly the RIPE NCC, are going to devote time, effort and members money to develop some form of authorisation system for a remote IRR to connect to each of the 5 RIR number registries to authorise ROUTE creation, then I personally would prefer to see the development of a single, global IRR operated by the RIRs. This cross registry authorisation is probably the main element of having a single IRR.<br id="yui_3_16_0_ym19_1_1529009458655_324379"><br id="yui_3_16_0_ym19_1_1529009458655_324380">Currently 4 of the 5 RIRs operate an IRR and they are all based on a version of the RIPE Database software. So we already have a common IRR database format. Add in this cross registry authorisation and we have a global IRR. I don't see the point of putting in the effort to develop a multitude of alternative/commercial IRRs when we can go the other way and have a single, authoritative, free IRR service. We have one internet, one DNS, why not one IRR?<br id="yui_3_16_0_ym19_1_1529009458655_324381"><br id="yui_3_16_0_ym19_1_1529009458655_324382">I know the first comment is probably going to be, "we already have this with RPKI". But for whatever reason, not all operators use, or want to use, RPKI. That is a reality, just as much as everyone switching to IPv6...not. Since RPKI is not the complete answer, we still need an IRR where the ROUTE objects are validated and trusted. I think the RIRs are in the best position to each develop a trusted IRR linked to their own number registry, then take the leap to create a single IRR. I personally think this is the better way to go than develop secure authorisation modules for IRRd.<br id="yui_3_16_0_ym19_1_1529009458655_324383"><br id="yui_3_16_0_ym19_1_1529009458655_324384">cheers<br id="yui_3_16_0_ym19_1_1529009458655_324385">denis<br id="yui_3_16_0_ym19_1_1529009458655_324386">co-chair DB-WG<br id="yui_3_16_0_ym19_1_1529009458655_324387"><br></div></div></body></html>